Beck01, Wolfgang wrote:
>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.
>
>
See also my comment about examples for both scenarios.
>>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.
>
>
I think you are missing the point. Unescaping is not an optional HTTP
feature. An HTTP Digest username can contain "\" or <"> characters. They
must be escaped as per HTTP quoted string syntax. For example if you
have a username 'domain\user' it will be represented in HTTP Digest as
"domain\\user". If a naive implementation just strips the quotes it will
end up with 2 slashes and not 1, which will lead to digest verification
failure.
This comment applies to at least to username, realm, nonce and cnonce.
>>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?
>
>
The message flow is fine, but there are so many optional RADIUS options
that a regular reader will be easily lost. An additional example can
also help verify that your description is actually correct. I had to
reread section 3.1 multiple times to understand how it relates to the
two scenarios.
>[...]
>
>>[...]l
>>
>> > 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?
>
>
IMHO, if somebody is reading the document for the first time, it might
be confusing a bit.
One way to address that is to move the discussion of nonce generation
(which is later in the same section) to the front of the section.
> [...]
>
>> >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?
>
>
In this 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.
>
Ok.
>If the HTTP-style client receives
>a 'stale' directive, it does not need to prompt the user for the
>password again.
>
>
My question was if nonce verification should be done before or after
client response verification. (I don't know the answer.)
>> > 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 following text from section 3.1 suggests that Digest-HA1 is truly
optional:
o If the Access-Accept packet contains neither a Digest-Response-
Auth nor a Digest-HA1 attribute, the RADIUS client will not create
an Authentication-Info header for its HTTP-style response.
>> > 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.
>
>
The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop
attributes it has received in a previous Access-Challenge packet."
implies that the RADIUS client (== HTTP server) is the one picking the
Qop. I think the last sentence can say:
"A RADIUS client sends the Qop value received from the HTTP client in the
Digest-Qop attribute."
>> >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?
>
>
I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is
backward compatible with HTTP Digest) implementations.
The problem is that the behavior you propose was never explicitly
allowed or disallowed in the HTTP Digest document.
>> >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.
>
>
I think giving this example in the document would explain why they may
be different.
You also need to add some text explaining how User-Name can be derived
from the Digest-Username.
Cheers,
Alexey