[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
---------- Forwarded message ----------
Date: Mon, 12 Dec 2005 13:38:59 -0500
From: Sam Hartman <hartmans-ietf@mit.edu>
To: dnelson@enterasys.com, aboba@internaut.com
Cc: david.kessens@nokia.com, housley@vigilsec.com
Subject: [Alexey Melnikov] Re: Review request:
draft-ietf-radext-digest-auth06.txt
I'd appreciate it if you could engage Alexey on these comments. I
think at least some of these might be blocking; I won't get around to
evaluating whether I want to hold a discuss until Wednesday evening.
I also expect another review tomorrow.
Date: Mon, 12 Dec 2005 15:28:43 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: secdir@mit.edu
Cc: Sam Hartman <hartmans-ietf@mit.edu>, Kurt D. Zeilenga
<Kurt@OpenLDAP.org>, housley@vigilsec.com
Subject: Re: Review request: draft-ietf-radext-digest-auth06.txt
Hi everyone,
Sam has asked me to review draft-ietf-radext-digest-auth-06.txt. I think
for the most part the document is ready, but I would recommend at least
one more revision to address some issues outlined below.
General comments on the document:
1). sections 3.1 and 3.2 are too complex to follow, because they allow
for so many different modes of operations: nonce generated on the RADIUS
client or the RADIUS server, hash is calculated on the RADIUS client or
the RADIUS server, etc. I understand why the document is trying to be so
flexible, but the text suffers as the result. I would suggest to
separately talk about scenarios described in sections 1.3.1 and 1.3.2.
2). everywhere in section 4: all references to "without quotes" has to
be replaced with "unquoted" or similar. "Without quotes" can be
interpreted as just blindly removing the surrounding quote characters,
however many attribute values are allowed to contain quoted (escaped)
"\" and <">, so just removing the quotes will not produce proper result.
3). It would be nice to see examples of both scenario 1 and 2 in the
document. I think it will clean up a lot of confusion.
Specific comments on the document (please let me know if I got anything
wrong):
>3.1. RADIUS Client Behavior
>
> 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.
This paragraph is an important security consideration, so I think it
should be moved to section 9 (Security Considerations section),
otherwise it is too easy to overlook.
[...]
> If the RADIUS client recognizes the nonce or does not generate
> nonces,
Regarding "does not generate nonces" case - does this paragraph talk
about scenario 2 step 2, or scenario 2 step 6?
I think the latter, but the text is no clear.
> it takes the header directives and puts them into a RADIUS
> Access-Request packet. 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 packet to the RADIUS server.
[...]
> If the RADIUS client did receive an HTTP-style request without a
> (Proxy-)Authorization header matching its locally configured realm
> value, it obtains a new nonce and sends an error response (401 or
> 407) containing a (Proxy-)Authenticate header.
>
> If the RADIUS client receives an Access-Reject from the RADIUS
> server, it sends an error response to the HTTP-style request it has
> received. If the RADIUS client does not receive a response, it
> retransmits or fails over to another RADIUS server as described in
> [RFC2865].
>
> The RADIUS client has three ways to obtain nonces: it generates them
> locally, it has received one in a Digest-Nextnonce attribute of a
> previously received Access-Accept packet, or it asks the RADIUS
> server for one. To do the latter, it sends an Access-Request
> containing a Digest-Method and a Digest-URI attribute but without a
> Digest-Nonce attribute. It adds a Message-Authenticator (see
> [RFC3579]) attribute to the Access-Request packet. The RADIUS server
> chooses a nonce and responds with an Access-Challenge containing a
> Digest-Nonce attribute.
I suggest to move the second quoted above paragraph before the first, so
that the two paragraphs talking about nonces are sequential.
> The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
> Realm, Digest-Domain and Digest-Opaque attributes in the Access-
> Challenge carrying the nonce. If these attributes are present, the
> client MUST use them.
The Digest-Realm attribute is required as per section 3.2. The use of
"can" is confusing in this case, as all other attributes are optional.
>3.2. RADIUS Server Behavior
[...]
> A RADIUS server MUST check if the RADIUS client is authorized to
> serve users of the realm mentioned in the Digest-Realm attribute. If
> the RADIUS client is not authorized, the RADIUS server MUST send an
> Access-Reject. The RADIUS server SHOULD log the event so as to
> notify the operator, and MAY take additional action such as sending
> an Access-Reject in response to all future requests from this client,
> until this behavior is reset by management action.
If the server follow the last MAY, this can be used by DOS attacks, so I
think this should be pointed out.
> If the RADIUS server does not accept the nonce received in an Access-
> Request packet but authentication was successful,
Does the server always have to check that the authentication was
successful before reporting nonce mismatch?
Are there any security implications?
> the RADIUS server
> MUST send an Access-Challenge packet containing a Digest-Stale
> attribute set to 'true' (without quotes). The RADIUS server MUST add
> Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
> SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
> Digest-Domain, Digest-Opaque attributes to the Access-Challenge
> packet.
>4.4. Digest-Response-Auth attribute
>
> Description
> This attribute enables the RADIUS server to prove possession 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.
This MUST is confusing, as other sections say that both
Digest-Response-Auth and Digest-HA1 are optional.
> The Digest-Response-Auth attribute MUST only be
> used in Access-Accept packets. The RADIUS client puts the
> attribute value without quotes into the rspauth directive of
> the Authentication-Info header.
>4.8. Digest-Qop attribute
>
> Description
> This attribute holds the Quality of Protection parameter that
> influences the HTTP Digest calculation. This attribute MUST
> only be used in Access-Request and Access-Challenge packets. A
> RADIUS client SHOULD insert one of the Digest-Qop attributes it
> has received in a previous Access-Challenge packet.
I was under impression that the HTTP[-like] client is the one choosing
Qop from the list of Qops specified by the RADIUS server.
>RADIUS
> servers SHOULD insert at least one Digest-Qop attribute in an
> Access-Challenge packet. Digest-Qop is optional in order to
> preserve backward compatibility with a minimal implementation
> of [RFC2069].
> Type
> [IANA: use 109 if possible] for Digest-Qop
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> qop directive (qop-value as described in [RFC2617]) without the
> quotes from the HTTP-style request it wants to authenticate.
> In Access-Challenge packets, the RADIUS server puts a desired
> qop-value into this attribute. If the RADIUS server supports
> more than one "quality of protection" value, it puts each qop-
> value into a separate Digest-Qop attribute.
As per my comment above - if multiple Qop values were specified by the
RADIUS server, the RADIUS client needs to put them into a single "qop"
directive containing comma separated list of Qop values.
>4.13. Digest-Username attribute
>
> Description
> 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.
I am still not convinced that the Digest-Username is ever different from
the User-Name attribute. I would like to see an example when they would
be different.
>4.17. Digest-Domain attribute
>
> Description
> When a RADIUS client has asked for a nonce, the RADIUS server
> MAY send one or more Digest-Domain attributes in its Access-
> Challenge packet. The RADIUS client puts them into the quoted,
> space-separated list of URIs of the 'domain' directive of a
> WWW-Authenticate header. The URIs in the list define the
> protection space (see [RFC2617], section 3.2.1). RADIUS
> servers MAY send one or more attributes of this type in Access-
> Challenge packets.
The last sentence is just repeating the first sentence in the same
paragraph.
> This attribute MUST only be used in Access-
> Challenge packets.
>9. Security Considerations
[...]
> The Message-Authenticator attribute, described in [RFC3579] section
> 3.2 MUST be included in Access-Request, Access-Challenge, Access-
> Reject and Access-Accept messages that contain attributes described
> in this specification.
I couldn't see this required attribute in the examples.
Regards,
Alexey
--
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/>