[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 4590bis Issue 206
The text of Issue 206 is enclosed below. The proposed resolution is as
follows:
Change Section 5 to the following:
"5. Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
+-----+--------+--------+-----------+-----+-------------------------+
| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
| 0-1 | 0 | 0 | 1 | 24 | State (see Note 4) |
+-----+--------+--------+-----------+-----+-------------------------+
Table 1
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
Digest-Qop is 'auth-int'.
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
Digest-Qop is 'auth'.
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
[Note 4] An Access-Challenge MUST contain a State attribute, which is
copied to the subsequent Access-Request. A server receiving an
Access-Request that contains a State attribute MUST respond with
either an Access-Accept or an Access-Reject; the server MUST NOT
respond with an Access-Challenge."
=============================
Issue 206: Attribute Table
Submitter name: Alan DeKok
Submitter email address: aland@nitros9.org
Date first submitted: Sept. 26, 2006
Reference: https://ops.ietf.org/lists/radiusext/2006/msg00870.html
Document: RFC 4590
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:
The body text, and examples in Section 6 appear to indicate that at
least Digest-Method is required in every Access-Request. Yet in
Section 5, the Table of Attributes indicates that no Digest attributes
are required in an Access-Request packet.
I first ran into this issue when I was looking at an implementation of
RFC 4590, and wanted to enforce the requirement that the
Message-Authenticator attribute must appear in every packet
implementing Digest authentication. If the server sends an
Access-Accept or Access-Challenge packet with Digest attributes, it is
simple to determine that the Message-Authenticator must be included in
the packet.
However, for Access-Request, there appears to be no way to determine
if the request is, in fact a request for Digest authentication,
because there is no requirement that any Digest attributes exist in
the Access-Request.
Reading Section 1.3, the paragraph at the top of page 6 seems to
indicate that a Digest-Method is always sent in an Access-Request.
Other text in the document also indicates that the first
Access-Request always contains a Digest-Method attribute.
It may be that Digest-Method does NOT have to appear in Access-Request
if the Access-Request is in response to an Access-Challenge, but this
is not clear from the text. My recommendation is to make
Digest-Method required in the Access-Request, which simplifies
implementation. It also appears that this requirement is the intent
in RFC 4590, because all of the examples have Digest-Method in every
Access-Request.
I also have noted that none of the Access-Challenges in the examples
contain a State attribute, and the State attribute is not mentioned
anywhere in RFC 4590. That indicates to me that the Access-Request in
response to an Access-Challenge MUST contain sufficient information to
finish the authentication process, and have the server return either
Access-Accept or Access-Reject. The alternative is for the server to
repeatedly challenge the client, which does not appear to be the
intent.
That says to me that the Access-Challenge MUST contain a State
attribute, which is copied to the subsequent Access-Request. The
server MUST respond with either an Access-Accept or Access-Reject to
an Access-Request that contains a State attribute. The server MUST
NOT respond with Access-Challenge to an Access-Request that contains a
State attribute.
I believe that may be another issue.
Requested change:
Update the Table of Attributes as follows:
....
| 1 | 0 | 0 | 0 | 108 | Digest-Method |
....
--
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/>