Subject: [eap] Some Success and Failure issues, take 2

From: [email-masked] (Bernard Aboba)
Date: Tue, 26 Feb 2002 18:35:30 -0800 (PST)

RFC 2869 has some issues in handling of EAP that have turned out to be a
big headache. 

RFC 2865 is clear that on the NAS/AP, the access decision is based on
whether the client receives an Access Accept or Reject, *not* based on
what is inside any EAP-Message attribute. This makes sense, since the
NAS/AP is just supposed to act as a passthrough in EAP. 

However, it makes for some interesting corner conditions, because this
implies that the following packets can be sent by the AAA server:

    a. Access Accept/EAP-Message/EAP-Failure
    b. Access Reject/EAP-Message/EAP-Success
    c. Access Accept/EAP-Message/Notification
    d. Access Reject/EAP-Message/Notification
    e. Access Accept (no EAP Message)
    f. Access Reject (no EAP Message)
    g. Access Accept/EAP-Message/EAP-Failure, Reply-Message
    h. Access Accept/EAP-Message/EAP-Success, Reply-Message
    i. Access Reject/EAP-Message/EAP-Failure, Reply-Message
    j. Access Accept/EAP-Message/EAP-Success, Reply-Message

There are probably more corner conditions than this, but my fingers are
getting tired :(

a. This is a problem because the Accept says "grant access" while the
Failure, if passed on to the EAP peer will make it think that
authentication has failed. If there are alternate indications of
success, one might argue that the peer will eventually figure it
out. But this isn't true of all media (IEEE 802 and 802.11 have no such
alternate indications). 

b. This is a problem because the Reject says "no access" while the
EAP-Success passed to the peer makes it think it is successful. 
If there are alternate indications of Failure on a given media, the peer
may eventually figure things out. On IEEE 802.11 a Disassociate from the
AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE
802 there is no alternate indication of failure.

c-d. These are an issue since the peer receives a displayable
Notification, but no indication of Success/Failure. Alternate indications
seem useful here too, but are not always present. 

e-f. Ditto, except no notification. 

g-j. These are a problem since Reply-Message is typically translated to an
EAP-Notification, so in effect the NAS/AP has *two* EAP messages to send
to the peer. Presumably the Notification has to be sent first, since the
Success/Failure message terminates the conversation. Note that the
Reply-Message doesn't come with an Identifier field, so presumably the
NAS/AP has to make one up. But since the Success/Failure already has an
Identifier field in it, what is the NAS/AP supposed to do, particularly if
the Identifier field is incremented sequentially? The problems are
obviously worse if the Reply-Message is sent in the middle of the
conversation, so that a simple Identifier swap wouldn't work. 

Some thoughts on possible solutions:

1. "Dr., it hurts when I do this". This approach says: these corner
conditions are difficult to handle for media in which there are no
alternate failure/success indications, so AAA servers SHOULD NOT send
them for those media. 

To keep NAS implementations clean, a-d should just be "passed
through" if received, with predictable ill effects. e-f will result in a
timeout for IEEE 802, and g-j will cause confusion on any media. Better to
send the Reply-Message, get an ACK and then send the Success/Failure (or
other EAP message) in the next round. 

2. "Mr. NAS will make it better". This approach says: the NAS should make
sure these corner conditions will not occur by "manufacturing" EAP
Success packets on receipt of an Access Accept, and "manufacturing" EAP
Failure packets on receipt of an Access Reject. This handles cases a-f,
but has some undesirable implications for cryptographically protected EAP,
as will be discussed below. 

In such cases, it seems preferrable to send the EAP Success or Failure
within the encrypted tunnel, and not have to send a cleartext Success or
Failure as well. 

In any case, since EAP Success/Failure packets are not ack'd whether
inside a tunnel or not, it's not clear to me how you'd be able to continue
the EAP conversation after sending an encrypted Success/Failure packet
anyway. 

But if the "Mr. NAS will make it better" approach is taken, then the NAS
will swallow the encrypted Success/Failure packet and replace it with a
cleartext Success/Failure. This undermines the concept of protection,
which is to be able to authenticate and encrypt each packet in the EAP
conversation. 

If the logic described above seems clear, then the recommended course is
to:

a. Write a section for RFC 2869bis warning against the corner conditions
and clarifying NAS behavior. 

b. Clarify the implications of the "Mr. NAS" approach within EAP
methods that would like to encrypt EAP Success/Failure. 

c. Request re-examination of the approach taken in the 802.1X state
machine.

---

From: [email-masked] (Jacques Caron)
Date: Wed, 27 Feb 2002 08:52:10 +0100

>and clarifying NAS behavior.

I think the easiest is simply to say that Accept/Reject messages SHOULD NOT 
contain EAP-Messages (or Reply-Messages either, if there was an EAP 
conversation at any point), and that NASes should send "canned" ones. Note 
that this "canned" version would only be needed for EAPv1 clients, EAPv2 
clients would just ignore them.

>methods that would like to encrypt EAP Success/Failure.

And use either of the alternatives (EAPv2-in-EAPv1 or EAP-Request/Success) 
proposed.

>c. Request re-examination of the approach taken in the 802.1X state

I'm not sure we need to break that one. If we move the "real" 
success/failure notification somewhere else, the "canned" notification is 
just needed for EAPv1 clients, and redundant for EAPv2 clients. Might just 
want to make sure that NASes are able to detect EAPv2 clients and know they 
don't need to send the "canned" message for those, but this is more 
cosmetic that anything.

Jacques.

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