Subject: Re: [eap] New EAP/802.1X interface variable proposal

From: John Vollbrecht <[email-masked]>
Date: Wed, 07 Jan 2004 14:27:36 -0500

The following is comments about the proposal for fixes to the 802.1X/EAP 
interface.

I have attached a power point to this in order to include some diagrams 
that I can't do in ASCII.  I think the proposal is basically very good.  I 
do think there needs to be discussion of details of what the variables 
between EAP and 802.1X should be, where certain authorization decisions are 
made, and in what packets RADIUS should carry information (is Access Accept 
alone correct?)

I would appreciate comments on the diagrams, particularly on the 
description of rules for authorizing in a net to net environment.  I think 
having a set  of rules for this would be very helpful, and this is an 
attempt to describe such rules.

I will be in Vancouver next week and hopefully this will be discussed.

John

--On Friday, December 19, 2003 2:12 PM -0500 "CONGDON,PAUL 
(HP-Roseville,ex1)" <[email-masked]> wrote:

>
> A proposed resolution to the 802.1X/EAP interface issue
> related to discussions on EAP issues 204/205 and
> 802.1X/D7.1 Ballot comment 15 was developed Dec 5th in a
> phone conference with EAP team members Bernard Aboba, Jari
> Arkko, Nick Petroni and 802.1X team members Jim Burns, Paul
> Congdon and Bob Moskowitz.  This memo attempts to document
> the proposal and solicit discussion that will lead to
> closure of this remaining issue for two nearly completed
> documents; 802.1X/D8 and RFC2284bis.
>
> Background - The problem
>
> The resolution of comment 15 on 802.1X/D7.1 uncovered an
> issue with rfc2284bis and the EAP state machine draft.
> Namely, the higher layer(EAP/AAA) is unable to inform the
> lower layer (1X) that its policy has been fully satisfied
> after only one role's state machine has run.  This also
> means that it is unable to inform the lower layer that its
> policy will only be satisfied if the other role's state
> machine is run.
>
> In addition, it was discovered that a pass-thru
> authenticator has no way of knowing if a peer has accepted
> a successful mutual authentication exchange since it is
> unaware of any protected indications returned by that peer.
> In contrast a standalone authenticator can be made aware of
> this because the EAP session is terminated locally.
> Consequently pass-thru and standalone configurations behave
> differently and this is not allowed or appropriate.
>
> The ability of the higher layer to inform the lower layer
> when its policy is satisfied can be used to eliminate the
> need for a subsequent authentication exchange in the
> opposite direction.  Running two authentications in
> opposite directions of one another is often very difficult
> and not sufficient as pointed out by RFC 2284bis in section
> 2.4.
>
> The fix for communicating the satisfaction of policy
> between the higher layer and lower layer is a new interface
> signal.
>
> The fix to ensure that the pass-thru authenticator does not
> behave differently than the standalone authenticator is a
> new RADIUS attribute.  The new RADIUS attribute is under
> development and will be documented in a forthcoming RFC.
>
> The new interface signal is communicated across the AAA
> boundary to the EAP.  The signal indicates to the layer
> below that the policy of the higher layer is satisfied or
> not.
>
> The RADIUS attribute is used by the authentication server
> to inform a pass-thru authenticator of policy satisfaction
> so it may drive this signal.  A standalone authenticator
> could drive this signal based upon local information.
>
> The new interface signal is also made available at the
> 802.1X interface and could be used to eliminate the need to
> initiate a second authentication in the opposite direction.
> Essentially this signal could be used to either force
> authorize the alternate role, or activate the Supplicant
> Access Control With Authenticator variable if it were not
> already activated.  As RFC 2284bis points out in 2.4 it is
> often neither desirable nor possible to initiate a second
> authentication in the opposite direction, nor is it
> necessary if the 1st authentication resulted in mutual
> authentication with protected indications (essentially what
> the new interface signal asserts).
>
> It is important to note that the EAP layer, EAP methods and
> AAA layer run over transports other than 802.1X and this
> interface signal will be important for those transports as
> well.  This new signal will also need to be a consideration
> for future 802.1af work.
>
> The Proposal
>
> The EAP state machine draft will be updated to discuss this
> new indication.  Annex F of 802.1X documents the interface
> between the higher layers (EAP, EAP Methods, AAA Layer) and
> 802.1X.  Annex F must include a definition of all signals
> that cross this interface.  This new signal should be
> included in this discussion.
>
> Additionally a short description of how this signal might
> be used to disable reverse authentications in the special
> case where both authenticator and supplicant are configured
> and active on a port.  It should reference section 2.4 of
> RFC 2284bis where this type of configuration is discussed
> for peer-to-peer scenarios.  A short discussion of this may
> also be needed in clause 6.7.
>
> Proposed Changes to 802.1X/D8  (subject to the editor's
> judgment on wording and style):
>
> Add clause F.2.8
>
> F.2.8  eapRemoteSuccess
>
> The higher layer will give this signal a value after
> eapSuccess is set.  This signal is ignored by the lower
> layer if eapFail is set.  If this signal is set following
> eapSuccess then the policy of the higher layer is
> completely satisfied and there is no need to carry out
> further authentication (no need to run the 1X authenticator
> machine).  If this signal is reset following setting of
> eapSuccess then the policy of the higher layer requires
> that another authentication (initiated by the 1X
> authenticator) must occur to satisfy the policy.
>
> This variable allows the higher layer to avoid initiating a
> second authentication session where the system would now
> act as authenticator and require the coupling of two
> independent authentications as described in 6.7.
>
> If eapRemoteSuccess is set then Supplicants with this
> indication may choose to set the AuthControlledPortControl
> management variable to ForceAuthorize in order to avoid
> initiating the subsequent authentication.  If
> AuthControlledPortControl is set to ForceAuthorize, it must
> be set back to its original state if the supplicant state
> machine exits the authenticated state.
>
> If eapRemoteSuccess is reset then Supplicants with this
> indication may choose to set the AuthControlledPortControl
> management variable to Auto to ensure the authenticator
> machine initiates the subsequent authentication.
>
> Note - Section 2.4 of RFC 2284bis describes several
> situations where coupling two authentications may be needed
> but is difficult to achieve.
>
> Add clause F.3.10
>
> F.3.10 eapRemoteSuccess
>
> The higher layer will give this signal a value after
> eapSuccess is set.  This signal is ignored by the lower
> layer if eapFail is set.  If this signal is set following
> eapSuccess then the policy of the higher layer is
> completely satisfied and there is no need to carry out
> further authentication (no need to run the 1X supplicant
> machine). If this signal is reset following setting of
> eapSuccess then the policy of the higher layer requires
> that another authentication (initiated by the 1X
> supplicant) must occur to satisfy the policy.
>
> This variable allows the higher layer to avoid or require a
> second authentication session where the system would now
> act as supplicant and require the coupling of two
> independent authentications as described in 6.7.
>
> If eapRemoteSuccess is set then Authenticators with this
> indication may choose to set the SuppControlledPortControl
> management variable to ForceAuthorize or alternatively
> activate the Supplicant Access Control With Authenticator
> management control.  This will avoid initiating the
> subsequent authentication.    If either variable is set, it
> must be set back to its original state if the authenticator
> state machine exits the authenticated state.
>
> If eapRemoteSuccess is reset then Authenticators with this
> indication may choose to set the SuppControlledPortControl
> management variable to Auto or alternatively deactivate the
> Supplicant Access Control With Authenticator management
> control. This will cause the supplicant state machine to
> initiate the subsequent authentication.
>
> Note - Section 2.4 of RFC 2284bis describes several
> situations where coupling two authentications may be needed
> but is difficult to achieve.
>
> Comments welcome,
>
> Paul Congdon & Jim Burns
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jim Burns <[email-masked]>
Date: Thu, 15 Jan 2004 15:15:28 -0800

Hi Preeti,
    Yes, let me try to bring some clarity here.
     Please see my responses below:

Preeti vinayakray wrote:

>
>
> Hello Jim:
>  
> In following email you mentioned about few points and I am somewhat 
> confused with terminology here. I would appreciate if you can clarify 
> my if anything I have misunderstood
>
> Well in brief discussion u did mention that here the scenario can 
> be focused as P2P.
>
Yes, this discussion, and the interface variable, were related to 
resolving an issue that occurred in the peer to peer .11 case.  The 
original problem was, if both peers are running both the authenticator 
and supplicant (peer) and a mutual authentication occurs on one of the 
state machines, then should we be able to ignore the result on the other 
.1X state machine.  If the answer was yes, then how would the .1X 
machine know that a mutual authentication method had been used?  The 
answer was there needed to be a new 1X/EAP variable. 
   It was then discovered that just because a mutual authentication 
method ran on one .1X machine it may not necessarily follow that you 
want to ignore the second .1X state machine.  It could be the case that 
each .1X machine should both run mutual authentication EAP methods but 
use different credentials.  This meant that we should only ignore the 
other .1X machine if the 'policy' had been satisfied by a single .1X 
machine.
   This led to issues of what was a 'policy' and how could we know when 
it had been satisfied.
    In the end, there is no problem with running two .1X machines, it is 
just slightly less efficient.  In addition, if keys are created, there 
will be two created (one for each .1X machine) and there must be a 
mechanism for choosing which key will be used (which .11 peer to peer 
does define). 
    The current proposal is that there is no need for the 1X/EAP 
variable and rather that your policy will be defined by a clear 
definition of how many .1X machines you configure to run along with the 
EAP methods you configure to support.  In other words, if you run two 
state machines, then you meant to run two state machines with a set of 
EAP methods and those state machines should run and neither should be 
dynamically ignored.  Likewise, if you configure only one state machine 
to run with a limited set of EAP methods then this defines your policy.  
Thus, there is no need to terminate one of the .1X state machines 
dynamically and there is no need for the new .1X/EAP interface 
variable.  Rather, there is a need for standards that use 1X/EAP to 
explicity define the number of .1X machines and required EAP methods 
before starting.

> >coupled one-way EAP methods then this is not true. An example may 
> perhaps be enlightening.
>
> >A. Imagine a peer that has a policy that indicates that indicates 
> that >it will only open its controlled port when the following occurs: 
> >1. The entity on the other end of the connection verifies that it is 
> a >trusted server (by delivering a server certificate) and accepts the 
> >peer's client certificate as valid. >2. The entity on the other end 
> of the connection delivers a client >certificate to the peer after the 
> peer verifies that it is a trusted >server (by delivering a server 
> certificate).
>
> [Preeti] In above Peer I presume that it is playing role of 
> authenticator.  Uncontrolled/Controlled port within authencator is 
> more relevant to authorization gained through authentication process. 
> And Client/Station.
>
Sorry, I used the overloaded word 'peer'.  By peer, I meant one of the 
end stations on one end of a network connection.  Let us call the peers 
as 'local station' and 'remote station'.  So, yes, the local station is 
running both .1X machines:  authenticator and supplicant.  The remote 
station is only running the authenticator 1X machine.

> >B. Imagine an authenticator that has a policy that indicates that it 
> >will open its controlled port when the following occurs: >1. The peer 
> delivers a valid client certifcate after the authenticator >sends its 
> server certificate.
>
> [Preeti] Here Peer is client. So if that is so then A and B resembles 
> same. Or I'm misunderstanding?
>
You may be misunderstanding...but that is because of my sloppy 
terminology.  The 'remote station' is running only the .1X authenticator 
machine.

> >Now, on a protocol level the following will occur: A. The peer 
> associates with the authenticator.
>
> >B. The peer and authenticator agree on EAP-TLS as the EAP method. >C. 
> EAP-TLS completes successfully after the authenticator delivers a 
> >server certificate, and the peer delivers its client certificate. >D. 
> The authenticator/AAA policy is now satisfied and the authenticator 
> >controlled port is unblocked and the key is delivered. >E. The peer's 
> policy is not satisfied yet though and the peer's >controlled port 
> remains blocked. >So, in this case the delivery of the AAA key does 
> not necessarily mean >the peer's policy has been satisfied.
>
> [Preeti] Yes, I agree with above that peer policy is not satified.
>
Yes, in the better terminology, the local station (which is running both 
.1X machines) has had its supplicant machine satisfied, but not its 
authenticator machine and its controlled port remains blocked.

> >So, issue two (2) above is summarized as, 'what happens when 'policy'
>
> >spans multiple EAP conversations'? >One potential solution is some 
> sort of handshake (beyond the EAP NAK) at >the start that allows both 
> parties to indicate their policies >requirements. If the authenticator 
> had known that the Peer required a >second EAP conversation then at 
> step D in the protocol description above >it could have realized that 
> the Peer was not yet satisfied and would not >have delivered the key 
> until after the second EAP conversation had
>
> >completed successfully.
>
> [Preeti] Or is it possible to convey policy criteria of Peers to each 
> other while negotiating the capabilities? 
>
Do you mean during a 'discovery' phase?  This may be possible and I 
believe it should be explored as a longer term solution to allow dynamic 
configuration.  I believe that today we are moving toward static 
definitions.  Standards that utilize .1X and EAP (i.e. 802.11 and 802.3) 
to define the number of .1X state machines and EAP methods to ensure 
that the policy is set at this level, rather than dynamically being 
created on the 'fly' in the field.   In fact, the example I have given 
would never occur as long as the definition states that peer-to-peer 
networks will run both .1X machines and will run mutual authentication 
EAP methods.  It is not as dynamic, but it guarantees a level of policy 
and allows security folks to better analyze a standard that uses 1X/EAP 
(I think).

> >I suppose another solution is that the peer will only accept an EAP 
> >method that allows chaining of mutliple EAP methods within it -- in 
> >other words EAP-PEAP. Then the EAP NAK process will provide the 
> policy >handshake...although this will not work because the 
> authenticator is in >charge of which EAP methods will be run and it 
> will be satisfied after a >single EAP-TLS and not run the second EAP-TLS.
>
> [Preeti] This may be possible. Perhaps in this chaining process one 
> has to be careful in selecting the chained methods that are immune to 
> security any threats.
>
> Thanks,
>
> Preeti
>
> >From: Jim Burns >To: Yoshihiro Ohba >CC: "CONGDON,PAUL 
> (HP-Roseville,ex1)" ,        [email-masked], 
> [email-masked],        Tony Jeffree >Subject: Re: [802.1] New 
> EAP/802.1X interface variable proposal >Date: Fri, 02 Jan 2004 
> 10:56:46 -0500 > > >Hi Yoshi, >This is a good point. >I have a few 
> questions/concerns that I would like to toss out. I am more >versed in 
> 1X than in the latest EAP draft so take this into account as >you read 
> through these - I could just be missing something in the latest >EAP 
> draft. > >I agree that overloading the AAA delivery to indicate 
> satisfaction of >both authenticator and peer policies should work in 
> most cases, but >there are two (2) cases/issues that concern me: >1. 
> This presumes the EAP method being utilized can produce a key. Does 
> >2284bis now require only EAP methods that produce keys? Is EAP-MD5 
> >deprecated? >2. The definition of 'policy' may go beyond the current 
> EAP method. This >occurs in the case of two coupled 'one-way' EAP 
> conversations. Example >below. If the policy does go beyond a single 
> EAP conversation, then the >delivery of the key by the AAA server only 
> indicates that satisfaction >has been achieved by the AAA server, the 
> peer may still want to run a >second EAP conversation. There is no 
> good solution if the policy extends >beyond a single EAP conversation 
> I believe, and this is because we have >a more basic problem that 
> there is no way for a Peer and an >Authenticator to agree on such a 
> higher level policy. Currently EAP >assumes that the acceptance (non 
> NAK) of a current EAP method means that >this is the policy that will 
> satisfy both sides. But, if there are to be >coupled one-way EAP 
> methods then this is not true. An example may >perhaps be 
> enlightening. > >A. Imagine a peer that has a policy that indicates 
> that indicates that >it will only open its controlled port when the 
> following occurs: >1. The entity on the other end of the connection 
> verifies that it is a >trusted server (by delivering a server 
> certificate) and accepts the >peer's client certificate as valid. >2. 
> The entity on the other end of the connection delivers a client 
> >certificate to the peer after the peer verifies that it is a trusted 
> >server (by delivering a server certificate). > >B. Imagine an 
> authenticator that has a policy that indicates that it >will open its 
> controlled port when the following occurs: >1. The peer delivers a 
> valid client certifcate after the authenticator >sends its server 
> certificate. > >Now, on a protocol level the following will occur: >A. 
> The peer associates with the authenticator. >B. The peer and 
> authenticator agree on EAP-TLS as the EAP method. >C. EAP-TLS 
> completes successfully after the authenticator delivers a >server 
> certificate, and the peer delivers its client certificate. >D. The 
> authenticator/AAA policy is now satisfied and the authenticator 
> >controlled port is unblocked and the key is delivered. >E. The peer's 
> policy is not satisfied yet though and the peer's >controlled port 
> remains blocked. >So, in this case the delivery of the AAA key does 
> not necessarily mean >the peer's policy has been satisfied. > >So, 
> issue two (2) above is summarized as, 'what happens when 'policy' 
> >spans multiple EAP conversations'? >One potential solution is some 
> sort of handshake (beyond the EAP NAK) at >the start that allows both 
> parties to indicate their policies >requirements. If the authenticator 
> had known that the Peer required a >second EAP conversation then at 
> step D in the protocol description above >it could have realized that 
> the Peer was not yet satisfied and would not >have delivered the key 
> until after the second EAP conversation had >completed successfully. 
> >I suppose another solution is that the peer will only accept an EAP 
> >method that allows chaining of mutliple EAP methods within it -- in 
> >other words EAP-PEAP. Then the EAP NAK process will provide the 
> policy >handshake...although this will not work because the 
> authenticator is in >charge of which EAP methods will be run and it 
> will be satisfied after a >single EAP-TLS and not run the second 
> EAP-TLS. > >In summary: >- You suggested that we overload the AAA key 
> delivery to indicate policy >satisfaction (rather than adding a new 
> AAA/passthrough authenticator >signal). >- I agree that this should 
> work in most cases, but there are two cases >that concern me: 1) 
> non-key generating EAP methods and 2) case that one >party's policy 
> spans multiple EAP conversations. > >I hope this is helpful, >Thanks, 
> >Jim B. > > > > >The delivery of the key could double as an indication 
> of peer success >for the current EAP method. It would be an indication 
> strictly from the >Authentication Server's point of view, but 
> currently there is no way to >communicate a higher level policy than 
> the current EAP method. >Let me back up to try to clarify my point. > 
> >Yoshihiro Ohba wrote: > > >I am a co-author of EAP State Machine 
> draft and it is not clear to me > >why a new RADIUS attribute is 
> needed to solve the problem (or I may be > >missing something). > > > 
> >I am wondering if the availablity of a AAA-Key at the pass-through > 
> >authenticator can be equivalent to the eapRemoteSuccess signal.  Is > 
> >there any case where the authentication server transports the AAA-Key 
> > >to the pass-through authenticator via a AAA protocol while the 
> higher > >layer policy has not been fully satisfied? > > > >I am 
> asking because it is difficult for me to imagine the case where > >the 
> AAA-Key is derived and transferred to the pass-through > 
> >authenticator while the EAP peer does not accept a successful mutual 
> > >authentication exchange in an EAP method that creates a shared key. 
> > > > >If the availablity of a AAA-Key at the pass-through 
> authenticator can > >be equivalent to the eapRemoteSuccess signal, I 
> think that > >aaaEapKeyAvailable variable in the EAP Full 
> Authenticator state > >machine can function as eapRemoteSuccess and a 
> new RADIUS attribute is > >not needed. > > > >Regards, > > > 
> >Yoshihiro Ohba > > > > > >On Fri, Dec 19, 2003 at 02:12:54PM -0500, 
> CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > >>A proposed 
> resolution to the 802.1X/EAP interface issue > >>related to 
> discussions on EAP issues 204/205 and > >>802.1X/D7.1 Ballot comment 
> 15 was developed Dec 5th in a > >>phone conference with EAP team 
> members Bernard Aboba, Jari > >>Arkko, Nick Petroni and 802.1X team 
> members Jim Burns, Paul > >>Congdon and Bob Moskowitz.  This memo 
> attempts to document > >>the proposal and solicit discussion that will 
> lead to > >>closure of this remaining issue for two nearly completed > 
> >>documents; 802.1X/D8 and RFC2284bis. > >> > >>Background - The 
> problem > >> > >>The resolution of comment 15 on 802.1X/D7.1 uncovered 
> an > >>issue with rfc2284bis and the EAP state machine draft. > 
> >>Namely, the higher layer(EAP/AAA) is unable to inform the > >>lower 
> layer (1X) that its policy has been fully satisfied > >>after only one 
> role's state machine has run.  This also > >>means that it is unable 
> to inform the lower layer that its > >>policy will only be satisfied 
> if the other role's state > >>machine is run. > >> > >>In addition, it 
> was discovered that a pass-thru > >>authenticator has no way of 
> knowing if a peer has accepted > >>a successful mutual authentication 
> exchange since it is > >>unaware of any protected indications returned 
> by that peer. > >>In contrast a standalone authenticator can be made 
> aware of > >>this because the EAP session is terminated locally. > 
> >>Consequently pass-thru and standalone configurations behave > 
> >>differently and this is not allowed or appropriate. > >> > >>The 
> ability of the higher layer to inform the lower layer > >>when its 
> policy is satisfied can be used to eliminate the > >>need for a 
> subsequent authentication exchange in the > >>opposite 
> direction.  Running two authentications in > >>opposite directions of 
> one another is often very difficult > >>and not sufficient as pointed 
> out by RFC 2284bis in section > >>2.4. > >> > >>The fix for 
> communicating the satisfaction of policy > >>between the higher layer 
> and lower layer is a new interface > >>signal. > >> > >>The fix to 
> ensure that the pass-thru authenticator does not > >>behave 
> differently than the standalone authenticator is a > >>new RADIUS 
> attribute.  The new RADIUS attribute is under > >>development and will 
> be documented in a forthcoming RFC. > >> > >>The new interface signal 
> is communicated across the AAA > >>boundary to the EAP.  The signal 
> indicates to the layer > >>below that the policy of the higher layer 
> is satisfied or > >>not. > >> > >>The RADIUS attribute is used by the 
> authentication server > >>to inform a pass-thru authenticator of 
> policy satisfaction > >>so it may drive this signal.  A standalone 
> authenticator > >>could drive this signal based upon local 
> information. > >> > >>The new interface signal is also made available 
> at the > >>802.1X interface and could be used to eliminate the need to 
> > >>initiate a second authentication in the opposite direction. > 
> >>Essentially this signal could be used to either force > >>authorize 
> the alternate role, or activate the Supplicant > >>Access Control With 
> Authenticator variable if it were not > >>already activated.  As RFC 
> 2284bis points out in 2.4 it is > >>often neither desirable nor 
> possible to initiate a second > >>authentication in the opposite 
> direction, nor is it > >>necessary if the 1st authentication resulted 
> in mutual > >>authentication with protected indications (essentially 
> what > >>the new interface signal asserts). > >> > >>It is important 
> to note that the EAP layer, EAP methods and > >>AAA layer run over 
> transports other than 802.1X and this > >>interface signal will be 
> important for those transports as > >>well.  This new signal will also 
> need to be a consideration > >>for future 802.1af work. > >> > >>The 
> Proposal > >> > >>The EAP state machine draft will be updated to 
> discuss this > >>new indication.  Annex F of 802.1X documents the 
> interface > >>between the higher layers (EAP, EAP Methods, AAA Layer) 
> and > >>802.1X.  Annex F must include a definition of all signals > 
> >>that cross this interface.  This new signal should be > >>included 
> in this discussion. > >> > >>Additionally a short description of how 
> this signal might > >>be used to disable reverse authentications in 
> the special > >>case where both authenticator and supplicant are 
> configured > >>and active on a port.  It should reference section 2.4 
> of > >>RFC 2284bis where this type of configuration is discussed > 
> >>for peer-to-peer scenarios.  A short discussion of this may > >>also 
> be needed in clause 6.7. > >> > >>Proposed Changes to 
> 802.1X/D8  (subject to the editor's > >>judgment on wording and 
> style): > >> > >>Add clause F.2.8 > >> > >>F.2.8  eapRemoteSuccess > 
> >> > >>The higher layer will give this signal a value after > 
> >>eapSuccess is set.  This signal is ignored by the lower > >>layer if 
> eapFail is set.  If this signal is set following > >>eapSuccess then 
> the policy of the higher layer is > >>completely satisfied and there 
> is no need to carry out > >>further authentication (no need to run the 
> 1X authenticator > >>machine).  If this signal is reset following 
> setting of > >>eapSuccess then the policy of the higher layer requires 
> > >>that another authentication (initiated by the 1X > 
> >>authenticator) must occur to satisfy the policy. > >> > >>This 
> variable allows the higher layer to avoid initiating a > >>second 
> authentication session where the system would now > >>act as 
> authenticator and require the coupling of two > >>independent 
> authentications as described in 6.7. > >> > >>If eapRemoteSuccess is 
> set then Supplicants with this > >>indication may choose to set the 
> AuthControlledPortControl > >>management variable to ForceAuthorize in 
> order to avoid > >>initiating the subsequent authentication.  If > 
> >>AuthControlledPortControl is set to ForceAuthorize, it must > >>be 
> set back to its original state if the supplicant state > >>machine 
> exits the authenticated state. > >> > >>If eapRemoteSuccess is reset 
> then Supplicants with this > >>indication may choose to set the 
> AuthControlledPortControl > >>management variable to Auto to ensure 
> the authenticator > >>machine initiates the subsequent authentication. 
> > >> > >>Note - Section 2.4 of RFC 2284bis describes several > 
> >>situations where coupling two authentications may be needed > >>but 
> is difficult to achieve. > >> > >>Add clause F.3.10 > >> > >>F.3.10 
> eapRemoteSuccess > >> > >>The higher layer will give this signal a 
> value after > >>eapSuccess is set.  This signal is ignored by the 
> lower > >>layer if eapFail is set.  If this signal is set following > 
> >>eapSuccess then the policy of the higher layer is > >>completely 
> satisfied and there is no need to carry out > >>further authentication 
> (no need to run the 1X supplicant > >>machine). If this signal is 
> reset following setting of > >>eapSuccess then the policy of the 
> higher layer requires > >>that another authentication (initiated by 
> the 1X > >>supplicant) must occur to satisfy the policy. > >> > >>This 
> variable allows the higher layer to avoid or require a > >>second 
> authentication session where the system would now > >>act as 
> supplicant and require the coupling of two > >>independent 
> authentications as described in 6.7. > >> > >>If eapRemoteSuccess is 
> set then Authenticators with this > >>indication may choose to set the 
> SuppControlledPortControl > >>management variable to ForceAuthorize or 
> alternatively > >>activate the Supplicant Access Control With 
> Authenticator > >>management control.  This will avoid initiating the 
> > >>subsequent authentication.    If either variable is set, it > 
> >>must be set back to its original state if the authenticator > 
> >>state machine exits the authenticated state. > >> > >>If 
> eapRemoteSuccess is reset then Authenticators with this > >>indication 
> may choose to set the SuppControlledPortControl > >>management 
> variable to Auto or alternatively deactivate the > >>Supplicant Access 
> Control With Authenticator management > >>control. This will cause the 
> supplicant state machine to > >>initiate the subsequent 
> authentication. > >> > >>Note - Section 2.4 of RFC 2284bis describes 
> several > >>situations where coupling two authentications may be 
> needed > >>but is difficult to achieve. > >> > >>Comments welcome, > 
> >> > >>Paul Congdon & Jim Burns > >> > >>=>IEEE 802.1 Email List user 
> information: > >>http://www.ieee802.org/1/email-pages/ > >> > >> > > > 
> > > > > > > >=>IEEE 802.1 Email List user information: 
> >http://www.ieee802.org/1/email-pages/
>
> ------------------------------------------------------------------------
> Send mobile Christmas cards, download a festive ringtone and win a 
> Motorola E365 Click here <http://g.msn.com/8HMAENAU/2728??PS=>