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

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

So, we certainly did not agree on any changes anywhere.  That is what this
thread is all about.  I don't agree that 802.1X should include any new
configuration variables as you are talking about, nor any additional
discussion about how existing ones are used.  It is a day late and a dollar
short for changes now to that document unless we want to delay the sponsor
ballot.  It seems like EAP-SM still has room to make editorial comments, so
if we are going to do ANY changes, they should go in EAP-SM.  The suggestion
is simply adding editorial comment, not State Machine or interface
changes...  

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 3:35 PM
> To: CONGDON,PAUL (HP-Roseville,ex1); Nick Petroni; Bernard 
> Aboba; James Burns
> Cc: eap [at] frascone.com; Robert Moskowitz; Yoshihiro Ohba
> Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue
> 
> 
> I don't think we agree that anything needs to be included in 
> the EAP SM. 
> If 802.1X decides to use the secret to indicate that the 
> authentication 
> succeeded at both ends, it can do that.  I do not think this 
> is needed by 
> 802.1X, and I proposed not using it.  So I don't think any 
> changes are 
> needed to EAP SM.
> 
> 802.1X needs to document something shows how each end of a 
> connection can 
> be configured, but that can be in an annex.  It probably 
> needs a small 
> change in the description of how the variables are set.  Jim 
> Burns may have 
> some idea of how this would be done.
> 
> --- John
> 
> --On Wednesday, January 14, 2004 3:20 PM -0800 "CONGDON,PAUL 
> (HP-Roseville,ex1)" <paul.congdon [at] hp.com> wrote:
> 
> >
> > 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
> > >
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>