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

From: Jim Burns <[email-masked]>
Date: Mon, 05 Jan 2004 18:19:33 -0500

Hello Pasi,
   You are correct, for media using 802.1X, the new variable, 
eapRemoteSuccess, will not reduce network traffic.  Rather its intended 
goal is to grant the higher layer (EAP/AAA) the ability to dynamically 
indicate to the lower layer the level of 'policy' satisfaction that has 
been achieved based on the higher layers knowledge of policy and the EAP 
methods that were available.
    Currently, if both 1X machines (supplicant/authenticator) are 
implemented within a device then both the 1X machines will in fact run 
simultaneously.  There is no suggested/documented/fool-proof method of 
carrying out tie-breaking between the two .1X machines.    This lack of 
a tie-breaking facility in .1X is discussed in section 2.4 of 2284bis 
(it is indicated as an issue of 802.11, but I believe it affects 802.3 
as well since both use security based on .1X).  And, as you have 
indicated, this means that the eapRemoteSuccess will not reduce the 
network traffic.
     The eapRemoteSuccess variable instead addresses a different issue:  
It allows the higher layer (EAP/AAA) to dynamically indicate full policy 
satisfaction.  It is a recognition that there are two roles ('gain 
access to network', 'allow access to my resources') involved in making a 
secure network connection and both roles must indicate policy 
satisfaction in order for the controlled port to be opened. 
     Policies for each role may be arbitrarily complex.  There are a 
number of EAP methods available with different capabilities and 
characteristics.  Depending on the policy of a device and the EAP method 
used a single EAP method may satisfy both roles policies.  On the other 
hand, the EAP methods available between two devices may require an EAP 
method for each role to satisfy its policy.   Which EAP method will be 
used is determined dynamically at the time of running the protocol.  
Because of these factors (role policies and EAP methods available) there 
needs to be a way for the higher layer to communicate to the lower 
layer, dynamically, whether none, one or both roles have been satisfied 
by the EAP methods that were run. 
     Prior to the definition of eapRemoteSuccess, the higher layer could 
only indicate that the current role was satisfied (one or none).  With 
the addition of eapRemoteSuccess the higher layer can indicate, 
dynamically, that both roles have been satisfied.
     In practical terms this allows policies to be defined that may be 
satisfied by a single EAP method or two EAP methods and can be 
dynamically determined at each authentication based on available EAP 
methods.  It should be made clear that two coupled EAP methods do not 
possess the security of a single mutual authentication EAP method, but 
there may be policies that allow it, perhaps with reduced authorization.
     Currently, 802 media (really 802.11 and 802.3) will not see a 
savings in network traffic.  This will require a startup handshake to 
determine roles and run them sequentially rather than in parallel.  This 
is under consideration for  802.1af (Key agreement protocol for Link 
Security).
Hope this helps,
Jim B.

[email-masked] wrote:

>Hi,
>
>I have a short question about how eapRemoteSuccess works
>when the port first comes operational.
>
>Let's assume that two parties are using a mutually authenticating 
>EAP method, and both parties are happy with running the method
>in just one direction (and don't care which direction it is).
>
>When the port comes operational, what happens? Currently it seems
>that both parties start both supplicant and authenticator state 
>machines, so two EAP authentications are started. Presumably, one 
>of these authentications finishes first and sets eapRemoteSuccess,
>and at that point, the second one can be aborted. If both directions 
>take approximately the same time to complete, we haven't really 
>avoided the run in the other direction at all...
>
>Is this the intention, or is there some way the parties can decide 
>to try one direction first? The description of eapRemoteSuccess
>seems to make the assumption that one direction is tried after 
>the other one, not concurrently, but I couldn't figure out
>how this is supposed to happen...
>
>Best regards,
>Pasi 
>
>  
>
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of ext
>>CONGDON,PAUL (HP-Roseville,ex1)
>>Sent: Friday, December 19, 2003 9:13 PM
>>To: [email-masked]; [email-masked]
>>Cc: Jim Burns; Tony Jeffree
>>Subject: [802.1] New EAP/802.1X interface variable proposal
>>
>>
>>
>>
>>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/
>
>  
>

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

---

From: <[email-masked]>
Date: Mon, 5 Jan 2004 23:12:22 +0200

Hi,

Best regards,
Pasi