[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 119: More NITs
Issue 119: More NITs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
General:
RADIUS RFCs use the term "packet" to refer to RADIUS Access-Request,
Challenge, Accept and Reject messages, not "message". Please change
"message" to "packet" throughout the document.
Section 3
The term 'HTTP-style' denotes any protocol that uses HTTP-like
headers and uses HTTP digest authentication as described in
[RFC2617]. Examples are HTTP and SIP.
Why is this here? Shouldn't this be moved to the terminology section?
Section 3.1
Change:
" If this attribute is present in an Access-Request message, the
RADIUS server MUST view the Access-Request as a Digest one."
to:
" If this attribute is present in an Access-Request message, a
RADIUS server implementing this specification MUST treat the
Access-Request as a request for Digest Authentication."
Change:
"The attribute proves the user knows the password
and MUST only be used in Access-Requests."
To:
"This attribute (which enables the user to prove possession of the
password) MUST only be used in Access-Requests"
Change:
" When using HTTP digest, the text field is 32 octets long and
contains hexadecimal representation of 16 octet digest value as
it was calculated by the authenticated client. Other digest
algorithms MAY define different digest lengths. The text field
MUST be copied from request-digest of digest-response
([RFC2617]) without quotes."
To:
" When using HTTP digest, the text field is 32 octets long and
contains a hexadecimal representation of the 16 octet digest value as
it was calculated by the authenticated client. Other digest
algorithms MAY define different digest lengths. The text field
MUST be copied from request-digest of digest-response
([RFC2617]) without quotes."
Section 3.3
Change:
" This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a
Digest-URI but no Digest-Nonce attribute and the RADIUS server
is configured to choose nonces, it MUST put a Digest-Nonce
attribute into its Access-Challenge message. This attribute
MUST only be used in Access-Request and Access-Challenge
messages."
to:
" This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a
Digest-URI but no Digest-Nonce attribute and the RADIUS server
is configured to choose nonces, it MUST put a Digest-Nonce
attribute into its Access-Challenge message. This attribute
MUST only be used in Access-Request and Access-Challenge
messages."
Section 3.4
Change:
" This text proves the RADIUS server knows the password. If the
previously received Digest-Qop attribute was 'auth-int'
(without quotes), the RADIUS server MUST send a Digest-HA1
attribute instead of Digest-Response-Auth. The Digest-
Response-Auth attribute MUST only be used in Access-Accept
messages. The RADIUS client puts the attribute value without
quotes into the rspauth directive of the Authentication-Info
header."
To:
" This attribute enables the RADIUS server to prove possesion
of the password. If the previously received Digest-Qop
attribute was 'auth-int' (without quotes), the RADIUS server
MUST send a Digest-HA1 attribute instead of a Digest-Response-Auth
attribute. The Digest-Response-Auth attribute MUST only be used
in Access-Accept messages. The RADIUS client puts the attribute
value without quotes into the rspauth directive of the
Authentication-Info header."
Section 3.11
Change:
" This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access-
Request messages.u"
To:
" This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access-
Request messages."
Section 3.13
Change:
" This attribute holds the user name parameter that is used in
the HTTP digest calculation. The RADIUS server MUST NOT use
this value for password finding, but only for digest
calculation purpose. In order to find the user record
containing the password, the RADIUS server MUST use the value
of the ([RFC2865] -)User-Name attribute. This attribute MUST
only be used in Access-Request packets."
To:
" This attribute holds the user name used in the HTTP digest
calculation. The RADIUS server MUST use this attribute
only for the purposes of calculating the digest. In order to
determine the appropriate user credentials, the RADIUS
server MUST use the User-Name (1) attribute, and MUST NOT
use the Digest-Username attribute. This attribute MUST
only be used in Access-Request packets."
Section 3.15
Change:
" If the Digest header contains several unknown parameters, then
the RADIUS implementation MUST repeat this attribute and each
instance MUST contain one different unknown Digest parameter/
value combination.
This attribute MUST ONLY be used in Access-Request, Access-
Challenge, or Access-Accept messages."
To:
" If the Digest header contains several unknown parameters, then
the RADIUS implementation MUST repeat this attribute and each
instance MUST contain one different unknown Digest parameter/
value combination. This attribute MUST ONLY be used in
Access-Request, Access-Challenge, or Access-Accept messages."
In Section 3.20, change:
"However, the exact mapping of
this attribute to SIP can change due to new developments in the
protocol.
This attribute MUST only be used when the RADIUS client wants
to authorize SIP users and MUST only be used in Access-Request
messages."
To:
"However, the exact mapping of this attribute to SIP can change
due to new developments in the protocol. This attribute MUST
only be used in Access-Request messages, when the RADIUS client
wants to authorize SIP users."
Section 4
Please remove Section 4 (Migration Path to Diameter) as was discussed
at IETF 63.
Section 5
Please reformat the attribute table in the format used in other RADIUS
RFCs,
such as RFC 2865 Section 5.44:
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
--
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/>