Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 13 Jan 2004 14:45:57 -0800

Well, I'm not sure that is exactly how I read it.  We could still update
802.1X during the sponsor ballot.  That update would likely only involve a
discussion within the annex about the new variable that the EAP-SM document
added.  If the EAP-SM document doesn't have this new variable
(eapRemoteSuccess) nailed prior to the sponsor ballot close, then nothing
will be added to 802.1X.   It would still be helpful to have the variable
documented in the EAP-SM document if this deadline isn't met.  The sponsor
ballot for 802.1X will likely run in 1 month to 6 weeks time.  We don't want
to make comments during recirculation ballot since we would have to run
another circulation ballot after that.  We expect comments in sponsor
ballot, so we could slip the changes in there, but only if they are stable
in EAP-SM.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, January 13, 2004 2:48 PM
> To: [email-masked]
> Subject: [eap] Resolution of 802.1X/EAP-SM issue
> 
> 
> IEEE 802.1X-REV met today, and my understanding is that the 
> resolution of the issue was that the changes required to 
> resolve this issue would be made solely within the EAP State 
> Machine document.  Since no new EAP-SM document was available 
> incorporating the changes, no reference was inserted in IEEE 
> 802.1X-REV.
> 
> As a result, this Issue exists only within the EAP WG, and 
> there is no need to cc: IEEE 802.1 on this issue discussion 
> any more. _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Jan 2004 15:54:18 -0800 (PST)

Thanks, Paul.

The IETF Internet-Draft submission is coming up very soon, and hopefully
we will have an EAP-State Machine revision in by then incorporating the proposed fix.

Assuming that this happens, will there be time to get a fix applied to
IEEE 802.1X-REV?

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 14 Jan 2004 15:54:56 -0800

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   

> 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: [email-masked]; 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)" <[email-masked]> 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
> >
> > > From: [email-masked] [mailto:[email-masked]] 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); [email-masked]; 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 
> > > <[email-masked]> 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
> > > >
> > > > >
> > > > > > 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.
> > > > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > >
> > >
> > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > >
> 
>