Subject: [eap] Proposed Resolution to Issue 157: Order of attribute processing

From: [email-masked] (Bernard Aboba)
Date: Wed, 23 Jul 2003 14:20:38 -0700 (PDT)

The text of Issue 157 is enclosed below.  During IETF 57, we discussed the
issue and Pasi Eronen suggested that the best solution might not be to
specify the order of attribute processing in RFC 2869bis, since it might
not be the same for all media.

I think that makes sense. However, we do need to make sure that
the attributes get processed before the Accept/Reject indication. For
example, when receiving Access-Reject with EAP-Failure the EAP-Failure
needs to be sent before the port goes down or elese the EAP peer won't
receive the EAP-Failure and could hang.

There was also some discussion as to whether the User-Name in the
Access-Accept needs to be the same as in the Access-Request.

RFC 2865 indicates that the User-Name in the Access-Accept can
be different than the one in the Access-Request. For example,
the text below from Section 5.1 would have no purpose if they were
required to be the same:

"It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function."

Proposed fix:

Change Section 2.6.4 to:

"A RADIUS Access-Accept or Access-Reject packet may contain
EAP-Message attribute(s). In order to ensure
the correct processing of RADIUS packets, the NAS
MUST first process the attributes, including the
EAP-Message attribute(s), prior to processing the
Accept/Reject indication."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , delete:
"EAP-Message attributes are processed last (Section 2.6.4)."

-------------------------------------------------------
Issue 157: Order of attribute processing
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 6, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001429.html
Document: RFC 2869bis-22
Comment type: T
Priority: S
Section: 2.6.4, 3, Appendix B
Rationale/Explanation of issue:

Existing implementations process EAP-Message attributes first, and
changing the processing order will cause backward compatibility issues as
well as problems with operation of IEEE 802.11i. If approved, this change
will be made in Author 48 hours, since the draft has already been approved
for publication as an RFC.

In Section 2.6.4, change:

"Reject or Access-Challenge, the NAS SHOULD process other attributes
first, then decapsulate EAP-Message attribute(s), reconstitute the EAP
packet and send it to the peer."

To:

"Reject or Access-Challenge, the NAS SHOULD first decapsulate EAP-Message
attribute(s), reconstitute the EAP packet and send it to the peer, then
process other attributes."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , change:

"EAP-Message attributes are processed last (Section 2.6.4)."

To:

"EAP-Message attributes are processed first (Section 2.6.4)."