Subject: [eap] Re: EAPv2

From: [email-masked] (Bernard Aboba)
Date: Mon, 27 Jan 2003 06:54:59 -0800 (PST)

> Some ideas what properties this "EAPv2" could have:
>
> - Designed to be used in environments where the underlying
>   medium is not secure.

Since EAP is largely a datagram transport, it's not clear to me why it
needs any more inherent security than say, UDP, with the possible
exception of Success and Failure messages. After all, nooone is
claiming that we need UDPv2 in order to make IKE secure. So far,
the changes that have been brought forward that would improve security
are mostly transport issues (bigger Identifier & Type space) and
state machine clarifications. So we should not over-estimate what
can be achieved by changing the datagram headers.

> - Designed and specified so that it is easy to "embed" EAPv2 in
>   other protocols (EAPv1 was designed to be extensible, but it
>   was not intended as a "building block" for other protocols).

GSS-API is the IETF solution to this problem. Is there a compelling
case for creating something new?

> - Maybe better support for mutual authentication and method
>   negotiation related to it.

Mutual authentication can be done today in EAPv1. How would
EAPv2 make that easier? Also in terms of negotiation, unlike in
GSS-API, there is no key assumed to exist at the time that
EAP negotiation occurs. So the exchange MUST be unprotected --
and EAPv2 would not change that. Of course, the negotiation
result can be verified later - but this is also supported in
EAPv1.

> - EAPv2 records could be transported as an EAPv1 method, so it could
>   be used in PPP/802.1X environments without changing NAS boxes.

Sounds like a tunneling protocol -- which could be developed
as an EAPv1 method.

> - Clear specification of behavior (state machines, etc.), so that
>   EAPv2 would be simpler and easier to implement than EAPv1.

Given how widely EAP has been implemented, it is hard to argue that
protocol complexity is holding back deployment.

> Clearly, the main target of this work would not be PPP, or even
> 802.1X/11i, but new protocols which would like to reuse an existing
> "building block" (PANA, PIC, others?).

PIC was looking to reuse an existing protocol, so that's probably not a
good candidate for this. PANA might be, but only if a case can
be made that the issues can't be fixed in the lower layer transport.

> Perhaps some of the more difficult issues in 2284bis
> could be postponed to this "EAPv2"?

Given that we only have three issues open, I don't see much value in
putting them off, especially since we're already discussing
potential solutions to them.