[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Review of RFC 4590bis



Section 3

Typos have been introduced into this Section.

Currently Section 3 reads as follows:

"3.  New RADIUS Attributes

  If not stated otherwise, the attributes have the following format:

  0                   1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |  Length       | Text ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Quote and backslash characters in Digest-* attributes representing
  HTTP-style directives with a quoted-string syntax are escaped.  The
  surrounding quotes are removed.  They are syntactical delimiters that
  are redundant in RADIUS.  For example, the directive

  realm="the

  is represented as follows:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Digest-Realm  |       23      | the
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Instead, it should read the same as in RFC 4590:

"3.  New RADIUS Attributes

  If not stated otherwise, the attributes have the following format:

  0                   1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |  Length       | Text ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Quote and backslash characters in Digest-* attributes representing
  HTTP-style directives with a quoted-string syntax are escaped.  The
  surrounding quotes are removed.  They are syntactical delimiters that
  are redundant in RADIUS.  For example, the directive

  realm="the \"example\" value"

  is represented as follows:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Digest-Realm  |       23      | the \"example\" value |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Section 5

The attribute table does not include entries for CoA-Request and Accounting-Request packets. It also does not include a key explaining the meaning of the entries. Also, it suggests that the User-Name is always present in an Access-Request, which contradicts the examples (See Issue 196). I suggest that it be rewritten as follows:

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.

Access- Access- Access- Access- CoA- Acct-
Request Accept  Reject  Chlnge  Req  Req   #  Attribute
0-1      0      0      0       1    0-1   1  User-Name
1        1      1      1       1    0-1  80  Message-Authenticator
0-1      0      0      0       0    0   103  Digest-Response
0-1      0      0      1       0    0-1 104  Digest-Realm
0-1      0      0      1       0    0   105  Digest-Nonce
0      0-1      0      0       0    0   106  Digest-Response-Auth [1][2]
0      0-1      0      0       0    0   107  Digest-Nextnonce
1        0      0      0       0    0-1 108  Digest-Method
0-1      0      0      0       0    0-1 109  Digest-URI
0-1      0      0    0+        0    0-1 110  Digest-Qop
0-1      0      0    0-1       0    0-1 111  Digest-Algorithm [3]
0-1      0      0      0       0    0   112  Digest-Entity-Body-Hash
0-1      0      0      0       0    0   113  Digest-CNonce
0-1      0      0      0       0    0   114  Digest-Nonce-Count
0-1      0      0      0       0    0-1 115  Digest-Username
0-1      0      0    0-1       0    0   116  Digest-Opaque
0+      0+      0     0+       0    0   117  Digest-Auth-Param
0-1      0      0      0       0    0   118  Digest-AKA-Auts
0        0      0     0+       0    0-1 119  Digest-Domain
0        0      0    0-1       0    0   120  Digest-Stale
0      0-1      0      0       0    0   121  Digest-HA1 [1][2]
0-1      0      0      0       0    0   122  SIP-AOR
0-1      0      0      1       0    0    24  State [4]

  The following table defines the meaning of the above table entries.

    0     This attribute MUST NOT be present in the packet.
    0+    Zero or more instances of this attribute MAY be
          present in the packet.
    0-1   Zero or one instance of this attribute MAY be
          present in the packet.

  [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.

Appendix A

There is no section listing the changes between RFC 4590 and RFC 4590bis. Recommend that Appendix A be added:

Appendix A - Changes from RFC 4590

  This Appendix lists the major changes between [RFC4590] and this
  document.  Minor changes, including style, grammar, spelling, and
  editorial changes are not mentioned here.

  o The Table of Attributes (Section 5) now indicates that the Digest-
  Method attribute is required within an Access-Request.  Also, an
  entry has been added for the State attribute.  The table also
  includes entries for CoA-Request and Accounting-Request messages.  As
  noted in the examples, the User-Name attribute is not always present
  in an Access-Request.

  o Two errors in attribute assignment have been corrected within the
  IANA Considerations (Section 7).  Digest-Response-Auth is assigned
  attribute 106, and Digest-Nextnonce is assigned attribute 107.



--
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/>