[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)
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/>