Subject: [AAA-WG]: [Issue] NASREQ: EAP corner conditions

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

Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 5, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 4.0
Rationale/Explanation of issue:

NASREQ 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 Diameter message within which it is encapsulated. These problems
are inherited from RFC 2869. 

NASREQ needs to make clear, as RFC 2865 does, that a NAS makes its
access decision based on the Diameter message alone (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 
the following packets may be sent by the Diameter server:

    a. Accept/EAP-Message/EAP-Failure
    b. Reject/EAP-Message/EAP-Success
    c. Accept/EAP-Message/Notification
    d. Reject/EAP-Message/Notification
    e. Accept (no EAP Message)
    f. Reject (no EAP Message)
    g. Accept/EAP-Message/EAP-Failure, Reply-Message
    h. Accept/EAP-Message/EAP-Success, Reply-Message
    i. Reject/EAP-Message/EAP-Failure, Reply-Message
    j. Accept/EAP-Message/EAP-Success, Reply-Message
    k. Challenge/EAP-Message/EAP-Success
    l. 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 NASREQ 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 Diameter Server will not receive a response to
these messages -- but the NAS will neither have granted nor rejected
access. 

Proposed change:

Here are some possible ways to address the Reply-Message issue:

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 NASREQ should state 
that Diameter servers SHOULD NOT (MUST NOT?) send these messages. Since an
Diameter 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 Diameter message
(Accept/Reject). In this approach, NASREQ states that a
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
Diameter 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 NASREQ, 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 NASREQ. 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.