Subject: [eap] Some Success and Failure issues

From: [email-masked] (Bernard Aboba)
Date: Tue, 26 Feb 2002 18:27:31 -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 succeeded. 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. 

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. But this isn't true of all media. 

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 come to mind 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. To keep NAS implementations clean, a-d should just be "passed
through" if received. e-f will result in a timeout for IEEE 802, and g-j
will cause confusion on any media so 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. 

The "Mr. NAS will make it better" approach comes back to bite when the EAP
conversation is cryptographically protected, as it is in EAP TTLS, PEAP,
etc.

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.

---

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

>     j. Access Accept/EAP-Message/EAP-Success, Reply-Message

There are also the Access-Challenge/EAP-Message/EAP-Failure and 
Access-Challenge/EAP-Message/EAP-Success which are possibly quite interesting.

>out. But this isn't true of all media.

And some peers might have already disconnected upon receiving the failure 
message.

>and then send the Success/Failure (or other EAP message) in the next

One problem is that NASes need to understand a bit of EAP to know that 
certain messages need to be acked and others not, based on the EAP type, 
and not on the RADIUS type. So the NAS is not transparent to EAP anymore.

>as will be discussed below.

As far as I understand it, this approach is the one used by 802.1X, which 
says the NAS (er, switch/AP) is to send "canned" success or failure 
messages upon reception of AAA Access-Accept or -Reject messages.

>conversation is cryptographically protected, as it is in EAP TTLS, PEAP,

Given the absence of any data allowed in failure or success messages (in 
theory, probably not in practice), I don't quite see how that packet can be 
cryptographically protected anyway (unless it is encapsulated into 
something else).

>the EAP conversation after sending an encrypted Success/Failure packet

If we go for either the "Success is a new method" or "EAPv2 is encapsulated 
in a new method" approaches, we can decide that those success/failure 
messages (EAPv2 version) are ACK'd, protected, and whatever we want. Then 
the extra "regular" success message is just there for backward 
compatibility (of the NAS).

>which is to be able to authenticate and encrypt each packet in the EAP

Which brings us back to the alternatives I described in my mail from the 
other day, and which I have to put in draft format asap :-/

Jacques.

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

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Feb 2002 03:09:06 -0800 (PST)

> Access-Challenge/EAP-Message/EAP-Success which are possibly quite interesting.

Yes, I forgot those :( 

Since EAP-Success/Failure are terminal messages, the peer will not reply,
and therefore the RADIUS server will not receive another Access-Request to
continue the EAP conversation. So the peer thinks it is
successful/unsuccessful and yet the NAS has never been informed of a
result. 

> And some peers might have already disconnected upon receiving the failure 

Yup. In the EAP implementation survey, we didn't get much response for
"alternate indications". I suspect that most peers will take the Failure
as final and not consider alternate indications of success at all. 

> and not on the RADIUS type. So the NAS is not transparent to EAP anymore.

Can you elaborate? A NAS can just execute a "pass through" in all these
corner cases, correct? This wreaks some havoc, but it's havoc that was
caused by the AAA server, so presumably if "Dr., it hurts when I do
this" then the answer can be "don't do that". 

> messages upon reception of AAA Access-Accept or -Reject messages.

Yes. But if we decide that another approach makes more sense, there may
still be time to get it changed.

> cryptographically protected anyway (unless it is encapsulated into 

Right. It can be sent down an encrypted TLS tunnel (PEAP, TTLS). But there
is no room for a MIC at the end.