Subject: [eap] Issue 20: Reply-Message or Notification within Access-Accept/Reject

From: [email-masked] (Bernard Aboba)
Date: Sun, 14 Apr 2002 12:06:45 -0700 (PDT)

Issue 20: Reply-Message or EAP-Request/Notification attribute within
Access-Accept or Access-Reject
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 14, 2002
Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html
Document: RFC2869bis-01
Comment type: T
Priority: S
Section: 2.5

Rationale/Explanation of issue:

If an EAP-Message/EAP-Request/Notification attribute is sent within an
Access-Accept or Access-Reject, then the Peer is likely to reply with an
EAP-Response/Notification, and the NAS will pass this back to the RADIUS
server as an Access-Request/EAP-Message/EAP-Response/Notification. Since
an Access-Accept or Access-Reject terminates the RADIUS conversation, this
will be unexpected. The same thing is true of a Reply-Message attribute
sent within the Access-Accept or Access-Reject, assuming that we allow a
NAS to translate this to an EAP-Request/Notification. 

Change:
Add the following text to section 2.5:

"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, during an EAP conversation, the RADIUS server SHOULD encapsulate
displayable messages within an EAP-Message/EAP-Request/Notification,
rather than within a Reply-Message attribute.

While a NAS receiving a Reply-Message attribute within an EAP conversation 
MAY copy the value of the Reply-Message attribute into the Type-Data of an
EAP-Request/Notification and send this to the Peer, several issues may arise from this:

[1] Unexpected Responses. On receiving an EAP-Request/Notification,
the EAP Peer will send an EAP-Response/Notification, and the NAS will pass
this on to the RADIUS server, encapsulated within an EAP-Message
attribute. However, the RADIUS server may not be expecting an
EAP-Response/Notification. For example, consider what happens when a
Reply-Message attribute is included within an Access-Accept or
Access-Reject packet with no EAP-Message attribute present. 

If the value of the Reply-Message attribute is copied into the Type-Data
of an EAP-Request/Notification and sent to the peer, this will result in
an Access-Request containing an EAP-Message/EAP-Response/Notification
attribute being sent by the NAS to the RADIUS server. Since an
Access-Accept or Access-Reject message terminates the RADIUS conversation,
such an Access-Request would not be expected.

[2] Identifier conflicts. While the EAP-Request/Notification contains an
an Identifier, a Reply-Message attribute does
not. As a result, a NAS receiving a Reply-Message and wishing to
translate this to an EAP-Request/Notification 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. 

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.

Within an EAP conversation a Reply-Message attribute 
MAY be translated to an EAP-Request/Notification. As a result, 
a Reply-Message attribute MUST NOT be included in a RADIUS message 
containing an EAP-Message attribute. EAP-Message/EAP-Request/Notification
or Reply-Message attributes SHOULD NOT be included within an Access-Accept
or Access-Reject packet representing the conclusion of an EAP conversation.