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

[CONGDON,PAUL (HP-Roseville,ex1) (paul.congdon]

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