eap Mailing List: Re: [Issue 248] Comments on EAP state machine v4

[Jari Arkko (jari.arkko]

Florent, Nick,

First: thanks for going through the remaining issues!

And then to the "L" issue:

> > Aaaaaaaaaaaaaarghn the L word in a protocol that apparently is becoming
> > pervasive for the future (invading IKEv2, IEEE 802.1X, IEEE 802.11, IEEE
> > 802.16e, and why not IEEE 802.20)!

Welcome to the real world :-(

> > I am aware of what you say but I respectfully and strongly disagree.: if
> > EAP is going to be a protocol of the future why cripple it with problems
> > of the past.
(snip)
> > Again I wish that MD5-Challenge would disappear ;-)

Fortunately or unfortunately, EAP is already deployed. We have
created this working group in the IETF to "fully document and
improve the interoperability of the existing EAP protocol" (quoting
our charter). I think we should adopt better alternatives
and designs whenever we can -- and I think we have often done
that when working with the details -- but not when it would affect
backwards compatibility. EAPv2 is also off-limits for our
working group, though of course individuals in the group
can pursue, say, next-gen network access protocol designs
in their research work.

So, lets keep resolve the other stuff the best we can,
but not outlaw existing EAP methods. And as I have
said before, it would be good to have text to point
out specific vulnerabilities and issues in existing
EAP methods and the "L" part of the state machine.

I think RFC 3748 is our primary document regarding
the security properties of EAP (or lack thereof),
so I don't think we should hold the publication of the
state machine to develop such text. But if you already
have such text or you can clearly see what the implications
are, please send text so that Nick can put it in.

--Jari (the co-chair hat on)