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

[John Vollbrecht (jrv]

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)" <paul.congdon [at] hp.com> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap