[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 118: Editorial NITs
Issue 118: Editorial 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:
Section 1.1
HTTP-style protocol
a protocol using HTTP digest, like HTTP, SIP.
Change "a protocol" to "A protocol"
The combination of realm and digest URI the use of which is
authorized by the RADIUS server.
Change "URI the" to "URI, the"
Please include definitions of NAS, UA and UAS in the terminology section.
Section 1.3
"digest into the message" -> "digest within the message"
Change:
" Instead of maintaining a local user database, the server could use
RADIUS. However, RADIUS does not support HTTP digest without an
extension like the one described in this document. The RADIUS client
can not send a User-Password attribute as it does not receive a
password from the HTTP-style client. The RADIUS mechanism for CHAP
resembles HTTP digest, but the digest algorithms are not compatible.
This document extends RADIUS to support Digest Authentication, via
addition as a native authentication mechanism. An implementation
supporting this extension MUST include a Digest-Response attribute
within an Access-Request packet where Digest authentication is
desired. An Access-Request MUST NOT contain both a Digest-Response
attribute and another authentication attribute, such as User-
Password, CHAP-Password, or EAP-Message.
This document defines new attributes that enable the RADIUS server to
perform the digest calculation defined in [RFC2617]."
To:
" Instead of maintaining a local user database, the server could use
RADIUS. However, RADIUS [RFC2865] does not include support for
HTTP digest authentication. The RADIUS client can not use the
User-Password attribute, since it does not receive a password
from the HTTP-style client. The CHAP-Challenge and CHAP-Password
attributes are also not suitable since the CHAP algorithm is
not compatible with HTTP digest.
This document defines new attributes that enable the RADIUS server to
perform the digest calculation defined in [RFC2617], providing
support for Digest Authentication as a native authentication
mechanism within RADIUS. An implementation supporting this
extension MUST include a Digest-Response attribute
within an Access-Request packet where Digest authentication is
desired. An Access-Request MUST NOT contain both a Digest-Response
attribute and another authentication attribute, such as User-
Password, CHAP-Password, or EAP-Message."
Change:
" The nonces required by the digest algorithm are either generated by
the RADIUS client or by the RADIUS server. A mix of nonce generation
modes is not supported.
RADIUS clients and servers can support one, or both nonce generation
modes.
If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces. If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally. If at least
one HTTP-style client requires AKA authentication [RFC3310], the
RADIUS server MUST generate nonces and its RADIUS clients MUST NOT
generate nonces locally. The nonce generation mode is a configurable
parameter"
To:
" The nonces required by the digest algorithm are either generated by
the RADIUS client or by the RADIUS server. A mix of nonce generation
modes is not supported. RADIUS clients and servers can support one,
or both nonce generation modes.
If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces. If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally. If at least
one HTTP-style client requires AKA authentication [RFC3310], the
RADIUS server MUST generate nonces and its RADIUS clients MUST NOT
generate nonces locally. The nonce generation mode is a configurable
parameter."
Section 1.3.1
change "without authorization header" to "without an authorization header"
in this section.
"If credentials were accepted B" -> "If credentials were accepted, B"
Section 1.3.2
change:
" In most cases, the operation outlined in Section 1.3.1 is sufficient.
It reduces the load on the RADIUS server to a minimum. However, when
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector. These authentication vectors are often stored
centrally.
Figure 3 depicts a scenario, where the RADIUS server chooses nonces.
It shows a generic case where entities A and B communicate in the
front-end using protocols such as HTTP/SIP, while entities B and C
communicate in the back-end using RADIUS."
To:
" While the usage scenario described in Section 1.3.1 minimizes the load
on the RADIUS server, alternatives are required in some situations. When
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector, which is often stored centrally.
Figure 3 depicts a scenario in which the RADIUS server chooses nonces.
In this case entities A and B communicate in the using HTTP or SIP,
while entities B and C communicate using RADIUS."
Change:
" The relevant order of messages sent in this scenario is as follows:"
to:
" The following messages are sent in this scenario:"
Section 2.1
The first paragraph seems a bit awkard. Does this really belong
in Section 2.1, or might it belong in the Security Considerations
Section?
Change:
" If the messages between RADIUS client and RADIUS server are not
protected with IPsec, the RADIUS client MUST NOT accept secured
connections (like https or sips) from its HTTP-style clients (or else
the HTTP-style clients would have a false sense of security)."
To:
" The attributes described in this document are sent in cleartext.
Therefore were a RADIUS client to accept secured connections
(https or sips) from HTTP-style clients, this could result in
information intentionally protected by HTTP-style clients being
sent in the clear during the RADIUS exchange.
If the messages between RADIUS client and RADIUS server are not
protected with IPsec, the RADIUS client MUST NOT accept secured
connections (like https or sips) from its HTTP-style clients, so
that HTTP-style clients are not provided with a false sense of
security."
Change:
" On reception of an HTTP-style request message, the RADIUS client
checks whether it is responsible to authenticate the request. There
are situation where an HTTP-style request traverses several proxies,
and each of the proxies request to authenticate the HTTP-style
client. In this situation, it is a valid scenario that a HTTP-style
request received at a HTTP-style server contains several sets of
credentials. The 'realm' directive in HTTP is the key that the
RADIUS client can use to determine which credential is applicable.
It may happen also that none of the realms are of interest to the
RADIUS client, in which case the RADIUS client MUST consider that no
credentials (of interest) were sent. In any case, a RADIUS client
MUST send zero or exactly one credential to the RADIUS server. The
RADIUS client MUST choose the credential of the (Proxy-)Authorization
header where the realm directive matches its locally configured realm
value.
If such a header is present and contains HTTP digest information, the
RADIUS client checks the 'nonce' parameter. If the RADIUS client
generates nonces but did not issue the received nonce, it responds
with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to
the HTTP-style client. In this error response, the RADIUS client
sends a new nonce.
If the RADIUS client recognizes the nonce or does not generate
nonces, it takes the header directives and puts them into a RADIUS
Access-Request message. It puts the 'response' directive into a
Digest-Response attribute and the realm / nonce / digest-uri / qop /
algorithm / cnonce / nc / username / opaque directives into the
respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
Username / Digest-Opaque attributes. The request method is put into
the Digest-Method attribute. The RADIUS clients adds a Message-
Authenticator (see [RFC3579]) attribute. Now, the RADIUS client
sends the Access-Request message to the RADIUS server.
The RADIUS server processes the message and responds with an Access-
Accept or an Access-Reject message."
To:
"On reception of an HTTP-style request message, the RADIUS client
checks whether it is authorized to authenticate the request. Where
an HTTP-style request traverses several proxies and each of the
proxies request to authenticate the HTTP-style client the request
at the HTTP-style server may contain multiple credential sets.
The RADIUS client can use the 'realm' directive in HTTP to determine
which credentials are applicable. Where none of the realms are of
interest, the RADIUS client MUST behave as though no
relevant credentials were sent. In all situations the RADIUS client
MUST send zero or exactly one credential to the RADIUS server. The
RADIUS client MUST choose the credential of the (Proxy-)Authorization
header if the realm directive matches its locally configured realm.
If such a (Proxy-)Authorization header is present and contains
HTTP digest information, the RADIUS client checks the 'nonce'
parameter. If the RADIUS client generates nonces but did not issue
the received nonce, it responds with a 401 (Unauthorized) or
407 (Proxy Authentication Required) to the HTTP-style client.
In this error response, the RADIUS client sends a new nonce.
If the RADIUS client recognizes the nonce or does not generate
nonces, it takes the header directives and puts them into a RADIUS
Access-Request message. It puts the 'response' directive into a
Digest-Response attribute and the realm / nonce / digest-uri / qop /
algorithm / cnonce / nc / username / opaque directives into the
respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
Username / Digest-Opaque attributes. The request method is put into
the Digest-Method attribute. The RADIUS client adds a Message-
Authenticator attribute, defined in [RFC3579] and sends the
Access-Request message to the RADIUS server.
The RADIUS server processes the message and responds with an Access-
Accept or an Access-Reject."
--
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/>