Subject: [eap] Proposed resolution to EAP issue #16

From: [email-masked] (Bernard Aboba)
Date: Mon, 8 Apr 2002 18:39:05 -0700 (PDT)

I have come up with the following text for RFC2869bis, to resolve
EAP Issue #16 and Diameter issue #300. Comments welcome. 

Diameter issues: http://www.drizzle.com/~aboba/AAA/issues.html
EAP issues: http://www.drizzle.com/~aboba/EAP/eapissues.htmlA

2.5.  Usage guidelines

2.5.1.  Conflicting messages

In some cases, the authentication result implied by the encapsulated EAP
packet may not match the result communicated in the RADIUS message. For
example, and EAP Failure packet may be encapsulated within an Access-
Accept message and an EAP Success packet may be encapsulated within an
Access-Reject. Alternatively, no EAP-Message attribute may be included
within an Access-Accept or Access-Reject.

Such combinations are likely to cause confusion, because the NAS and
Peer will arrive at different conclusions as to the outcome of the
authentication. For example, if the NAS receives an Access-Reject with
an encapsulated EAP Success, it will not grant access to the Peer.
However, on receiving the Success, the Peer will be lead to believe that
it authenticated successfully. Similarly, if the NAS receives an Access-
Accept with an encapsulated EAP Failure, it will grant access to the
Peer. However, on receiving a Failure, the Peer will be lead to believe
that it failed authentication. If no EAP-Message attribute is included
within an Access-Accept or Access-Reject, then the Peer may not be
informed as to the outcome of the authentication, while the NAS will
take action to allow or deny access.

As described in [RFC2284bis], the EAP Success and Failure packets are
not acknowledged, and these packets terminate the EAP conversation. As a
result, if these packets are encapsulated within an Access-Challenge, no
response will be received, and therefore no further Access-Requests will
be sent to the RADIUS server. As a result, the NAS will not be given an
indication of whether to Allow or Deny access while the Peer will be
informed as to the outcome of the authentication.

To avoid these conflicts, the RADIUS server SHOULD check to make sure
that the results implied by an  encapsulated EAP-Message attribute and
the RADIUS message are in agreement. The following combinations SHOULD
NOT be sent by a RADIUS server as part of an EAP conversation:

   Access-Accept/EAP-Message/EAP-Failure
   Access-Accept/no EAP-Message attribute
   Access-Reject/EAP-Message/EAP-Success
   Access-Reject/no EAP-Message attribute
   Access-Challenge/EAP-Message/EAP-Success
   Access-Challenge/EAP-Message/EAP-Failure

Since the responsibility for avoiding these conflicts lies with the
RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to
correct contradictory messages that it receives.

2.5.2.  Priority

In addition to containing EAP-Message attributes, RADIUS messages may
also contain other attributes. In order to ensure the correct processing
of RADIUS messages, the NAS SHOULD process EAP-Message attributes last.

2.5.3.  Displayable messages

The Reply-Message attribute, defined in section 5.18 of [RFC2865],
indicates text which MAY be displayed to the user. This is similar in
concept to the EAP Notification Type, defined in [RFC2284bis].  However,
when sent during an EAP conversation, displayable messages SHOULD be
encapsulated within an EAP-Message/Notification-Request rather than
within a Reply-Message attribute.

While a NAS receiving a Reply-Message attribute MAY send an EAP
Notification-Request to the peer, several issues may arise from this:

[1]  Unexpected Notification-Responses. On receiving an EAP
     Notification-Request, the EAP Peer will send a Notification-
     Response, and the NAS will pass this on to the RADIUS server,
     encapsulated within an EAP-Message attribute.  Since the RADIUS
     server may not be expecting a Notification-Response, it may
     silently discard the packet.

[2]  Identifier conflicts. While the Notification-Request contains an an
     Identifier, a Reply-Message attribute does not. As a result, a NAS
     receiving a Reply-Message and wishing to translate it to a
     Notification-Request will need to make up an Identifier. Since the
     NAS cannot make assumptions about how the RADIUS server chooses
     Identifiers, it is possible that the chosen Identifier will
     conflict with a value chosen by the RADIUS server for another
     packet within the EAP conversation. As noted in [RFC2284bis] this
     would violate the requirement that Identifier values be unique
     within an EAP conversation.

2.5.4.  Multiple EAP-Message attributes

An Access-Challenge, Access-Accept, Access-Reject or Access-Request
message MAY contain zero or more EAP-Message attributes. However, where
more than one EAP-Message attribute is included, it is assumed that the
attributes are to be concatenated to to form a single EAP packet. Since
EAP is a "lockstep" protocol, a new EAP-Request cannot be sent until an
EAP-Response is received to an outstanding request and only a single
Request can be outstanding at a given time.  As a result, multiple EAP
packets MUST NOT be encoded within EAP-Message attributes contained
within a single Access-Challenge, Access-Accept, Access-Reject or
Access-Request message.

In addition, since a Reply-Message attribute MAY be translated to a
Notification-Request by some NASes, a Reply-Message attribute MUST NOT
be included in a RADIUS message containing an EAP-Message attribute.