| RE: Resolution of 802.1X/EAP-SM issue | <– Date –> <– Thread –> |
|
From: Nick Petroni (npetroni |
|
| Date: Wed, 14 Jan 2004 04:15:40 -0500 (EST) | |
> 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
>
- Re: Resolution of 802.1X/EAP-SM issue, (continued)
- Re: Resolution of 802.1X/EAP-SM issue Yoshihiro Ohba, January 13 2004
- Re: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
-
RE: Resolution of 802.1X/EAP-SM issue Bernard Aboba, January 14 2004
- RE: Resolution of 802.1X/EAP-SM issue Nick Petroni, January 14 2004
- RE: Resolution of 802.1X/EAP-SM issue John Vollbrecht, January 14 2004
-
RE: Resolution of 802.1X/EAP-SM issue John Vollbrecht, January 14 2004
- Re: Resolution of 802.1X/EAP-SM issue Jim Burns, January 14 2004
Results generated by Tiger Technologies using MHonArc.