eap Mailing List: RE: Resolution of 802.1X/EAP-SM issue

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

I think, at the end of the day, concerning what documents needs what
changing...  We could get away with no changes in either document, but since
EAP-SM is still in more of a development stage, it would be helpful to
include some discussion around the keyAvailable signal that indicates this
signal is sufficient for a pass-thru authenticator to know the remote peer
has accepted the mutual authentication (or something to that nature)...

I believe we are all agreeing the eapRemoteSuccess is not needed, and thus,
802.1X is not waiting for any specific updates to the EAP-SM document.  The
above recommendation would simply help capture the conclusions we have come
to...

Paul

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of John Vollbrecht
> Sent: Wednesday, January 14, 2004 8:56 AM
> To: Nick Petroni; Bernard Aboba; James Burns
> Cc: CONGDON,PAUL (HP-Roseville,ex1); eap [at] frascone.com; Robert 
> Moskowitz; Yoshihiro Ohba
> Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue
> 
> 
> I agree this is confusing, and I have also found it hard to 
> follow.  I am 
> now at the 802 Interim meeting and have had conversations 
> with Jim Burns 
> about this, and we have a revised proposal.  I wrote up a 
> proposal which 
> was sent to a number of people, and Jim is planning to write 
> the details.
> 
> The gist of the proposal is that
> 
> 1. we don't change EAP at all, no new interface variable is 
> needed.  This 
> means no dependency on producing new EAP documents.
> 
> 2. we keep the possibility of running both two state machines at each 
> machine, each could be supplicant and authenticator.  
> Associated with each 
> state machine is a variable, and for the physical port to be 
> enabled, both 
> variables must be set on.  The variables currently exist, so only the 
> mechanism for setting them changes.  The proposal is to use 
> the standard 
> Success and Failure from EAP to set these variables, with no need to 
> understand whether the authentication is "mutual".
> 
> 
> Some cases are described below, and some implications of the change 
> described after that.  Cases:
> 
> a. A machine may be configured to have only one state machine 
> (it is either 
> a supplicant or an authenticator).  This is the case covered by prior 
> 802.1X.  A supplicant only machine can talk to a authenticator only 
> machine.  By configuration the null variable in each machine 
> is set to be 
> always ON.
> 
> b. A machine configured to be both a authenticator and 
> supplicant may talk 
> to another that is also configured as an authenticator and 
> supplicant.  In 
> this case when device comes up the supplicant  will attempt 
> to start a 
> dialog with an authenticator.  If each device has two state 
> machines, two 
> authentications will occur and both must succeed for the 
> actual port to be 
> enabled.  This allows certain devices [e.g. bridges with nets 
> behind them] 
> to be connected and to get Unicast and Broadcast keys from 
> both authentions.
> 
>     A problem here is that that a lower device must decide 
> which Unicast 
> key
>     to use and must know about the two multicast keys.  
> Solution to this is
>     considered out of scope for 802.11 but must be understood 
> by protocols
>     that use the keys.
> 
> c. One device may configured as both supplicant and 
> authenticator and the 
> other as supplicant only.  In this case the [authenticator] 
> variable in the 
> supplicant only device is configured on.  The suplicant in 
> the dual state 
> machine will attempt to "start" but will get no answer and 
> will timeout and 
> set the variable to ON [this works this way to support the 
> case where there 
> is no authentication required by the device - I am not sure 
> it is right, 
> but this is the way it works].  Thus a device with a 
> supplicant only state 
> machine will work with a device with a authenticator state 
> machine or with 
> a machine with authenticator and supplicant state machine.
> 
> d. one machine may be configured with authenticator and 
> supplicant machine 
> and the other with only an autheniticator.  This case will 
> not work because 
> the authenticator in the device with authenticator and 
> supplicant will wait 
> forever for a supplicant to start.  The 802.1X document 
> should be amended 
> to make this case clear.
> 
> e. It is also true, as now, that two authenticator only or 
> two supplicant 
> only devices will not connect.
> 
> The above cases seem to be satisfactory but require some 
> documentation to 
> make clear the cases that will not work.
> 
> Some decision implications:
> 
> This proposal maintains the interface between 802.1X and EAP.  The 
> implications seem to be in making the distinction in what is 
> done on each 
> side of the interface.  Authentication is done on the EAP side, and 
> configuration of what eap method to use is done as part of 
> total device 
> configuration.  802.1X determines that the authentication is 
> done, but 
> assumes the configuration forced the correct configuration to be done.
> 
> This proposal assumes that the EAP method chosen by each 
> device in each 
> direction is configured.  The EAP method determines what kind of 
> authentication will be done, whether it is one way or mutual, 
> whether it 
> includes authorization at either or both ends, what keys it 
> creates and 
> derives.  If this is configured correctly, then if mutual 
> authentication is 
> required, the configuration must ensure that only a method 
> that supports 
> this will be selected in the EAP negotiation.
> 
> The implication here is that the selection of the EAP method 
> is part of the 
> whole implementation of an 802.1X device.  Defining the EAP 
> methods that 
> are allowed with an application is part of the protocol.  In 
> particular, 
> 802.1X may have some requirements, and 802.11 may have additional 
> requirements.  The 802.1x requirements presumably should be 
> in the 802.1X 
> documentation, and the 802.11 added requirements should be in 802.11.
> 
> ----
> this is a bit involved/ complex, but I would be interested in 
> comments.
> 
> John
> 
> 
> --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni 
> <npetroni [at] cs.umd.edu> wrote:
> 
> > > As I recall, the resolution of the comment in IEEE 
> 802.1X-D7.1 was 
> > > that an interface variable was needed so that EAP could indicate 
> > > down to the lower layers whether a protected result 
> indication was 
> > > received.
> > >
> > > Nick -- if you're out there listening.... can you help us 
> clear this 
> > > up?
> >
> > Actually, I'm not sure I can. I am very confused about who 
> is waiting 
> > for what to be put where. Picking up late on the many 
> threads related 
> > to this topic has proven unsuccessful for me- I guess I should have 
> > been better at keeping up over vacation. It seems we are asking for 
> > SOMETHING to be put into the EAP SM, but that the group has not yet 
> > reached a consensus on what that somethingis. The way I 
> understand the 
> > timeline is as
> > (roughly) as follows:
> >
> > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected 
> for grounds 
> > that there was insufficient signaling from EAP SM.
> >
> > 2. A discussion was held offline to try to find a solution to this 
> > problem, the result was a conclusion that some mechanism to show 
> > knowledge of the other party's satisfaction was needed --> 
> > eapRemoteSuccess or something similar would be used.
> >
> > 3. Upon presentation to the EAP WG, discussion started as 
> to why this 
> > is needed/what it means. To the best of my understanding, 
> there is yet 
> > to be a consensus on the solution. I *think* the discussion of 
> > key-derivation and its implication of knowledge of the 
> other party's 
> > acceptance has led to the conclusion that enough information is 
> > provided by the current interface (thereby rebutting #1 above - 1x 
> > does, in fact, have the info it needs).
> >
> > 4. Now the question seems to be if the keyAvailable variable is the 
> > only indication we want to provide and, if so, how to 
> document it so 
> > this is clear. If not, do we want to set another signal in EAP that 
> > always has the same result as keyAvailable, but is semantically 
> > different in that it answers the exact question 1x is asking. I 
> > suppose we are also awaiting an argument playing devil's 
> advocate as 
> > to why keyAvailable is not sufficient (if such an argument can be 
> > made).
> >
> > The set of dependencies I see is
> >    - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to 
> produce an SM draft
> >    with a new variable
> >
> >    - Pasi et al. are waiting on the consensus of the group before
> >      producing a draft.
> >
> > I am trying my best to come up to speed- any help clarifying is 
> > greatly appreciated.
> >
> > Thanks,
> > nick
> >
> > >
> > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote:
> > >
> > > >
> > > > It was both as I recall.  The AAA attribute was clearly not 
> > > > necessary because of the requirements for key derivation and 
> > > > mutual auth. Since this wasn't required, the presence 
> of the key 
> > > > could also be used by the pass-thru authenticator and 
> thus the new 
> > > > interface variable also wasn't needed. Someone correct 
> me if I'm 
> > > > out in the weeds.
> > > _______________________________________________
> > > eap mailing list
> > > eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
> > >
> >
> >
> >
> >
> >
> > _______________________________________________
> > eap mailing list
> > eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>