eap Mailing List

View Index by: Date - Thread - Author
Re: Resolution of 802.1X/EAP-SM issue
From: Jim Burns (jebmtghouse.com)
Date: Wed, 14 Jan 2004 20:59:12 -0500 (EST)
Hi folks,
Sorry I am late to this discussion.
It would be helpful to the community at large if two notes were written (I volunteer):
1. A note that contains a table with all the .1X state machine combinations down the left side and across the top with an indication of what will happen when each case encounters the other. There are some cases that will not work, for instance if one device is running the supplicant and authenticator and it attempts to connect to another device that is running just the authenticator.
2. A note how to set the .1X administrative variables depending on which machines are being run.
I am happy to write these two *informative* notes.
Jim B.

John Vollbrecht wrote:

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




Results generated by Tiger Technologies using MHonArc.