Subject: [eap] Re: EAPv2

From: [email-masked] ([email-masked])
Date: Wed, 29 Jan 2003 11:32:31 +0200

On January 27, 2003 Bernard Aboba wrote:

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

Well, this depends on whether you think EAP is a datagram transport
mechanism, or a general-purpose authentication framework. As a datagram=20
transport, EAP works fine, but a framework like ISAKMP does a lot more=20
than just sending bits from one place to another.

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

You're of course absolutely right, IETF already has a solution for
this, and probably there isn't a compelling case to replace it.

However, when you compare RFC 2284 and the latest 2284bis draft, you
can't blame somebody (including myself) for thinking that EAP is
trying to replace GSS-API as an authentication building block
(although this probably was not the intention of 2284bis), and=20
have used or tried to use it as such (PIC, EAP/SIP, ...).

RFC 2284 doesn't even mention the possibility of using EAP for
something else than PPP; 2284bis adds a lot of stuff which would
be useful to have in a general-purpose authentication building
block (just compare the abstracts to get an idea what I'm
trying to say; even the length has increased from 15 pages to 40!).

I guess my point in suggesting EAPv2 was that if people are going to
use EAP as an authentication "building block" for other protocols,=20
it would be nice to have some things EAP currently does not.
If we adopt the position that EAP should not be used as such a
building block (and people should use GSS-API instead), then=20
would it be a good idea to include a "usage guidelines" section=20
in 2284bis, clearly stating this?

Best regards,
Pasi