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

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

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: Tue, 13 Jan 2004 16:49:44 -0800 (PST)

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?

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 13 Jan 2004 19:49:50 -0500

> sufficient as Yoshi recommended.  But I thought we had agreed to include

I don't think we need a variable if the key is sufficient.  Otherwise - it 
seems to me - the remote server will need to create an attribute in 
addition to the key, but based on the presence of a key,  when sending an a
Access Accept - right?

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Jan 2004 17:09:49 -0800

I think John is right.  The EAP state machine already has
eapKeyAvailable variable to indicate key possession status, which
means that a new eapRemoteSuccess variable is not needed if we have agreed 
that key possession is sufficient information.

Yoshihiro Ohba

---

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

OK, now I understand.  This makes sense.  But we should document this
reasoning somewhere in the state machine document.