Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
"Beck01, Wolfgang" <BeckW@t-systems.com> Tue, 13 December 2005 15:03 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 13 Dec 2005 15:12:46 +0000
Message-Id: <97A461F3EE5284469E41ED3728202F41121F09@S4DE9JSAAMW.ost.t-com.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org, alexey.melnikov@isode.com, hartmans-ietf@mit.edu
Subject: Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
Date: Tue, 13 Dec 2005 16:03:33 +0100
MIME-Version: 1.0
Content-Type: text/plain
Alexey Melnikov wrote: > 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. This would introduce some redundancy. A developer implementing the draft for both modes would have to join those sections anyway. > > 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. > Blindly removing the surrounding quotes is exactly what was meant. quoted-string is used to allow characters that would break the HTTP syntax. This is not relevant for RADIUS, as we have TLV. (Un-)Escaping the actual value would not save very much space (I'd guess that escapes are rare) but complicate the implementation. > 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. > What's wrong with message flow given in 1.3.1 figure 2? > > 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. > This paragraph used to include a RADIUS client protocol action, so I put it here. I agree that it is better to move it to the SC section now. > [...] > > > 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. > The paragraph talks about the handling of an HTTP-style request containing an Authorization header. Scenario 2 Step 2 follows an HTTP-style request without an Authorization header. Is this really that unclear? > > 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. OK > > 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. OK > >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. > In this paragraph or in the Security Considerations section? > > 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? > This is defined in RfC 2617. If the HTTP-style client receives a 'stale' directive, it does not need to prompt the user for the password again. > > 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. This is a conditional MUST. Digest-HA1 is mandatory, if Digest-Qop was auth-int. > > > 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. I don't understand the problem. > > >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. This is one possibility. I've chosen a different one: "If the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop attribute." Do you object to splitting up the qop directive into various TLVs? > > >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. > What if your current policy was to assign HTTP user names containing '@' signs? A RADIUS infrastructure would interpret those User-Names as NAIs which may lead to undesired effects. > >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. OK. > > 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. > OK Regards, Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- 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/>
- Re: IESG Review of draft-ietf-radext-digest-auth0… Beck01, Wolfgang
- IESG Review of draft-ietf-radext-digest-auth06.tx… Bernard Aboba