Subject: (radius) Some issues with RFC 2869

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Mar 2002 17:04:32 -0800 (PST)

RFC 2869 has some corner conditions that have turned out to be a big
headache. These occur when the encapsulated EAP Message does not agree
with the RADIUS message within which it is encapsulated
(Accept/Reject/Challenge). 

RFC 2865 is clear that a NAS makes its access decision based on
the RADIUS message alone (Access Accept or Reject), *not* based on
the contents of any enclosed attributes, including an EAP-Message
attribute. This makes sense, since the NAS acts as a "passthrough" for
EAP. 

However, this makes for some interesting corner conditions, because 
RFC 2869 allows the following packets to be sent by the RADIUS 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
    k. Access Challenge/EAP-Message/EAP-Success
    l. Access Challenge/EAP-Message/EAP-Failure

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

a. Message a 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. For media in which there are no such indications (IEEE 802 and 802.11 
are examples), a timeout will result. 

b. Message b 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, so a timeout will result.

c-d. These are an issue since the peer receives a displayable
Notification, but no indication of Success/Failure. Alternate indications 
might help, but for media in which they don't exist, a timeout will
result.

e-f. Ditto, except no notification. 

g-j. These are a problem since it is not clear within RFC 2869 how a
Reply-Message is to be handled within an EAP conversation. Some NAS
implementations translate Reply-Mesage to an EAP-Notification, resulting
in the NAS having  *two* EAP messages to send to the peer. Some NAS
implementations treat the Reply-Message as a terminal non-ACK'd message,
in which case the subsequent EAP-Message attributes are never sent. Which
interpretation is correct? 

If you're in the "translate to Notification" camp, then presumably the
Notification has to be sent first, since the Success/Failure message
terminates the conversation and therefore nothing can be sent after
that. Note that the Reply-Message doesn't come with an Identifier field,
so presumably the NAS 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. 

k-l. These are problematic because an Access-Challenge indicates a
continuing conversation, but an EAP-Success/EAP-Failure is a terminating
message. Therefore the RADIUS Server will not receive a response to these
messages -- but the NAS will neither have granted nor rejected access. 

OK. If you've gotten this far, hopefully you understand why these messages
are a headache. 

Here are some possible ways to address the Reply-Message issue in RFC
2869bis:

1. On the Reply-Message processing issue, we could suggest that the right
way to notify the EAP peer in an EAP conversation is to use
EAP-Notification instead of Reply-Message, and that Reply-Message is a
terminal message that is sent, and not translated to EAP-Motification. 

2. Alternatively, we could specify that Reply Message is to be translated
to EAP-Notification by an EAP capable NAS (what about one which isn't EAP
capable?). 

Here are some approaches to addressing the issue of a mismatch between the
RADIUS message (accept/reject) and the EAP-Message attribute: 

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 that RFC 2869bis should state 
that RADIUS servers SHOULD NOT (MUST NOT?) send these messages. Since an
RFC 2869bis compliant RADIUS-server can be assumed not to send these
messages, the NAS can blithely decapsulate and send whatever is inside an 
EAP-Message attribute, if one is present, then act on the RADIUS message
(Accept/Reject). In this approach, RFC 2869bis states that an
Access-Challenge MUST NOT contain an EAP-Success/Failure message, and that
if a Reply-Message needs to be sent, then this should be encapsulated in
a packet with no EAP-Message attribute, adding an extra round-trip; the
Reply-Message is translated to EAP-Notification, and an
Access-Request/EAP-Message/Notification-Response is sent back to the
RADIUS server, after which the EAP conversation continues.  

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. 

In proposals to cryptographically protect EAP (such as EAP TTLS or PEAP),
it is desirable to have as much of the EAP conversation as possible be
protected. The idea of these protocols is to create an encrypted channel,
then complete the EAP conversation within that channel. That means that in
theory the final Success/Failure message is sent down the encrypted
channel. 

Since EAP Success/Failure messages are not ACK'd, such a message, if sent,
must terminate the EAP conversation. This implies that they must be the
last message sent, and so if the NAS is to know the result of the
conversation, then they need to be sent within an Access Accept or Reject
message. 

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. 

So it seems to me that, to address these issues in an RFC 2869bis, we
need to do one of two things:

1. If we adopt the "Dr., it hurts when I do this" approach, then we need
to suggest changes to the 802.1X state machine to conform to a clarified
RFC 2869bis. In this approach, we would presumably leave the EAP
Success/Failure messages as they are in RFC 2284, forbid the bad messages,
and add some text on how Reply-Message attributes are to be processed
within an EAP conversation. 

2. If we adopt the "Mr. NAS will make it better" approach, then we may
need to introduce new ACK'd Success and Failure messages within EAP. Doing
this will ensure a response to the success/failure indication, removing
the need for "alternative indications" and ensuring that the encrypted
Success/Failure indication gets through. 

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Mar 2002 10:03:02 -0800 (PST)

> but it can do this in most (all?) cases now - right?  802.11 does it with a self
> generated EAP message, and others do it somehow now.  I guess it would be
> interesting to look through the PPP state diagram to see what is supposed to happen
> if no success/failure is sent.

IEEE 802 does not provide all the "alternate indications" that PPP
does. RFC 2284 discusses how LCP-Terminate can be taken as an alternate
indication of failure, and NCP as an alternate indication of success. IEEE
802.11 has an alternate failure indication (Disassociate), but no
alternate success indication. For wired IEEE 802, "carrier loss" is the
closest we come to an alternate failure indicator (most implementations
don't use it this way), and there is no alternate success indicator. This
is one reason why IEEE 802.1X chose the "Mr. NAS will make it
better" approach. But today, NAS behavior is *not* consistent across
media. 

> But if I send an Access Challenge, presumably the NAS would have to do something to
> finish authentication.  I guess it is not clear what it would do with EAP, but we
> could spell it out.

Remember, the NAS is acting as a passthrough device here. It sends EAP
frames to the peer, and then takes the response and encapsulates it in a
RADIUS Access-Request. If there is no response from the peer, it can't
send an Access-Request on its own, since it is typically not aware of the
contents of the EAP-Message that was sent. For example, based on RFC 2869
and 2284, it is not even clear that a NAS needs to understand the meaning
of EAP Success and Failure when used with AAA, although 802.1X does appear
to require this. The NAS could just rely on the AAA Accept/Reject to
provide the information on what it is supposed to do.  

> > Unfortunately, the EAP/{encrypted/Success} is not ACK'd, so the peer will
> > not reply. There is therefore no way to generate an Access-Request, and no
> > vehicle for sending a subsequent EAP Success/Failure message.
> 
> Yes, but if the encrypted success is sent in a EAP/REQ/encrpted type, the peer must
> send a REPLY/encrypted type.  Or am I missing something?

If the encrypted message is an EAP-Success or EAP-Failure, then no reply
is possible. RFC 2284 does not define an ACK'd Failure or Success message
to encrypt and send down the channel. 

Are you suggesting that new Types be allocated to Success and Failure? If
this were done, then an EAP-Request/Type=Success could be sent, followed
by an EAP-Response/Type=Success, and similarly with Failure. 

This solves two problems. First, it eliminates the need for "alternate
indications" which are problematic for media that don't provide them. 

Second, it enables the EAP conversation to be continued, and thus for EAP
methods to be developed which can work regardless of media. The
conversation would look like this:

                                <--- Challenge/EAP-Message
                                     {EAP-Request/Type=Success}
Request/EAP-Message
(EAP-Response/Type=Success} --->
                                <--- Accept/EAP-Message/EAP-Success

Here {} denotes encryption. 

This approach could even be made backward compatible in that the Success
and Failure types could be NAK'd by implementations which don't support
them. 

-