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

[Yoshihiro Ohba (yohba]

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/