ISSUE: Improper use of Access-Reject in RFC 2869

["Alan DeKok" <aland@ox.org>]

Description: Improper use of Access-Reject in RFC 2869
Submitter name: Alan DeKok
Submitter email address: aland@ox.org
Date first submitted: March 7, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00186.html
		http://ops.ietf.org/lists/radiusext/2005/msg00253.html
Document: RFC 2869, and "issues and fixes" draft
Comment type: T
Priority: S
Section: 2.2
Rationale:

RFC 2869 uses Access-Reject packets in a manner where one would
normally use Access-Challenge packets.  As a result, the RFC 2865
definition of Access-Reject is violated, including semantics and contents.

Requested Change: Add proposed text as section to "issues and fixes"
draft

Section 2.2, Page 8 of RFC 2869 says:

<quote>
   If that authentication fails, the RADIUS server should return an
   Access-Reject packet to the NAS, with optional Password-Retry and
   Reply-Messages attributes.  The presence of Password-Retry indicates
   the ARAP NAS MAY choose to initiate another challenge-response cycle,
</quote>

However, this use of Access-Reject violates the RFC 2865 Section 2,
page 6 requirements on Access-Reject:

<quote>
   If any condition is not met, the RADIUS server sends an "Access-
   Reject" response indicating that this user request is invalid.  If
   desired, the server MAY include a text message in the Access-Reject
   which MAY be displayed by the client to the user.  No other
   Attributes (except Proxy-State) are permitted in an Access-Reject.
</quote>

The violation is two-fold.  One, attributes other than Reply-Message
and Proxy-State are being returned in an Access-Reject.  Two, the
Access-Reject packet is being used in the context of a continuing
authentication conversation, where RFC 2865 would require the use of
Access-Challenge.  The text in RFC 2869 uses the text
"challenge-response" to describe its use of Access-Reject, indicating
that the semantics of Access-Challenge are being used.

In addition, we note that RFC 2865, Section 4.4, page 19 addresses the
semantics of Access-Challenge being equivalent to Access-Reject in
some cases:

<quote>
      If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead.
</quote>

While it is difficult to correct existing deployments of RFC 2869, we
have the following recommendations:

1) New deployments of RADIUS MUST NOT use Access-Reject where the
semantics of Access-Challenge are intended.

2) Access-Reject MUST mean rejection of the users authentication
request, and the NAS MUST NOT send any additional Access-Request
packets for that user session.  The question of what defines a "user
session" is a complex one, and is discussed in ISSUE 68.

3) New deployments of ARAP as described in RFC 2869 SHOULD use
Access-Challenge instead of Access-Reject packets in the conversations
described in Section 2.2.

We also note that the table of attributes in Section 5.19 of RFC 2869
has an error for the Password-Retry attribute.  It says:

<quote>
Request  Accept  Reject  Challenge   #    Attribute
...
0        0       0-1     0           75   Password-Retry
</quote>

  Where the text in Section 2.3.2 says that Password-Rety can be
included within an Access-Challenge packet, for EAP authentication
sessions.  We recommend the following change to the table, based on
RFC 3579 and the discussion here:

Request  Accept  Reject  Challenge   #    Attribute
...
0        0       0       0-1         75   Password-Retry [Note 2]

[Note 2] As per RFC 3579, the use of the Password-Rety in EAP
authentications is deprecated.  The Password-Retry attribute can
be used only for ARAP authentication.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>