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

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

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.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, January 13, 2004 4:50 PM
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: [email-masked]
> Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue
> 
> 
> Was it the *variable* that was not necessary -- or a new AAA 
> attribute that was not necessary?  As I call, we decided that 
> key possession was sufficient as Yoshi recommended.  But I 
> thought we had agreed to include the *variable*, no?
> 
> On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote:
> 
> >
> > If the updated EAP-SM document is available in a maximum of 
> 6 weeks, 
> > and the EAP group has agreed that the new interface 
> variable is to be 
> > supported, we can modify 802.1X during sponsor ballot 
> round.  The last 
> > message I heard from Yoshi, however, was that the variable is not 
> > truly necessary and most likely won't make it into the document.
> >
> > Paul
> >
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[email-masked]]
> > > Sent: Tuesday, January 13, 2004 3:54 PM
> > > To: CONGDON,PAUL (HP-Roseville,ex1)
> > > Cc: [email-masked]
> > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue
> > >
> > >
> > > 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?
> > >
> > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote:
> > >
> > > >
> > > > 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
> > >
> >
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Jan 2004 00:46:22 -0800 (PST)

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?

---

From: Nick Petroni <[email-masked]>
Date: Wed, 14 Jan 2004 04:26:25 -0500 (EST)

> 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

---

From: John Vollbrecht <[email-masked]>
Date: Wed, 14 Jan 2004 11:56:26 -0500

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.
> >
> 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
> > > 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.