Subject: [eap] RFC 2284bis issues

From: [email-masked] (Simon Blake-Wilson)
Date: Thu, 21 Feb 2002 11:53:26 -0500

I'd like to add a concern about EAP-Success that has confused me for a while. I
think it's been aluded to here, but not stated explicitly yet.

Specifically, since EAP-Success is not ACK'ed, how can it be relied upon to
indicate things like "auth successful, go ahead and send packets"? It seems to
me that the NAS has to tell the client that auth is successful via some other
method ... at the moment the status quo seems to be to use a timer and start
sending packets if you don't see EAP-Success before the timer expires, or watch
for packets to arrive and decide auth must have been successful if you see
packets. As EAP gets used for more stuff, I think this needs to get pinned down.
If I remember correctly, 802.1x makes a mistake like this and relies on
EAP-Success being delivered successfully in several of the state machines.

Best regards. Simon

Jacques Caron <[email-masked]> on 02/20/2002 06:23:14 PM

To:   Bernard Aboba <[email-masked]>
cc:   John Vollbrecht <[email-masked]>, [email-masked] (bcc: Simon
      Blake-Wilson/Certicom)
Subject:  Re: [eap] RFC 2284bis issues

At 17:39 20/02/2002, Bernard Aboba wrote:
> > This seems a very good idea.
>
>Look for some initial ideas on how to do this in:
>http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt
>http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt
>
> > Here I think there is some conceptual conversation that needs to take
> place.
> > There are different ways to think about EAP.  One is to see it as a
> decision
> > making protocol for Access control.  Another is as a protocol between
> two end
> > points that use it to make decisions AND possibly other things, and not
> just for
> > access control applications.
>
>Want to stake out a position?

I vote in favor of "can do other things". The great thing about EAP is that:
- it occurs before an actual session starts (whatever that session is)
- it is transmitted transparently, end-to-end, between the client and an
AAA server, across the NAS/AP/whatever [note: it might be a good idea to
finally come up with a generic term that means any of those -- might be a
GAS, like Generic Access Server ;-)]

This could be used for negotiation of quite a number of things (related to
AAA's second A). John seems to think QoS parameters. I think presentation
of cost to the user. There might be more.

However, moving EAP from a single-method-then-success to a
multiple-method-then-success model might have some implications for
backwards compatibility.

> > or the client should not accept a "success" from the server if it is doing
> > mutual authentication.  I must decide for itself if the other side has
> > successfully authenticated
>
>If the client does not accept a "success" how does it know when the server
>has granted access to the network? It seems like the "ok to get on the
>network" state is reached as a result of two things where there is mutual
>auth:
>    1. Server authenticates itself to client (method specific)
>    2. Client authenticates itself to server (indicated by EAP Success)
>
>Note that in RFC 2284bis there is an open issue as to whether a client can
>send an EAP Success to a server.

I think one big issue with Sucess and Failure comes from the fact they're
not ACK'd, and hence cannot be NACK'd. In some cases, a client might want
to refuse a connection to go further (which in some contexts would mean
"start pumping cash out of my account") unless something else happened to
the satisfaction of the client.

>Yes -- the trick is that if it is an EAP state machine, it has to include
>support for L2 triggers. In some media such triggers exist, and in other
>media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we
>have Disassociate as alternative failure indications. In generic IEEE 802
>we do not have an equivalent

I would get that most of the 802 media that support 802.1x (and hence are
port-based) have a "link down" (or whatever the fancy name for that is in
IEEE lingo) event?

>. Similarly, in terms of success in PPP we
>have NCP, but I don't think there is an equivalent in 802.11 or generic
>802.

Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-(

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap