[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF last call comments on RADIUS Digest Authentication document not addressed
---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 02:26:43 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: bwijnen@lucent.com, david.kessens@nokia.com, dnelson@enterasys.com,
john.loughney@nokia.com, dromasca@avay.com, beckw@t-systems.com,
miguel.an.garcia@nokia.com
Subject: Re: IETF last call comments on RADIUS Digest Authentication
document
I've just checked the updated document and about half of the issues I've
I've reduced my original comments to the following list (Note, even though
some of the comments are minor, I would like to at least hear back some
argument
from authors on why they would not be addressed. My new comments are
enclosed in
<<>>):
1). [Major]: 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.
[Wolfgang]
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.
[Alexey]
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 Digest-Username (section 4.13),
Digest-Realm
(section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce (section 4.11).
2). [Medium]: 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.
[Wolfgang]
What's wrong with message flow given in 1.3.1 figure 2?
[Alexey]
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.
3). [Minor]
3.2.5. Obtaining Nonces
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.
4). [Medium]
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.
[Wolfgang]
In this paragraph or in the Security Considerations section?
[Alexey]
In this section.
5). [Medium]
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.
[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if
Digest-Qop
was auth-int.
[Alexey]
The following text from section 3.1 (in -06, 3.2.3 in -07) 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.
<<Not addressed. Suggestion how to address the issue:
If the previously received Digest-Qop attribute
was 'auth-int' (without surrounding quotes), the RADIUS server
MUST NOT send a Digest-Response-Auth attribute and SHOULD send
a Digest-HA1 attribute instead (see section 4.19).
6). [Medium]
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.
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 should be reworded to say something like
this:
"A RADIUS client sends the Qop value received from the HTTP client in the
Digest-Qop attribute."
7). [Medium]
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.
[Wolfgang] 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?
[Alexey]
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.
<<Suggestions how to address: either say that all qop values are sent in a
single HTTP Digest qop directive, or add a note explaining possible
interoperability issue if this is not done.>>
8). [Minor]
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.
[Wolfgang]
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.
[Alexey]
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.
===
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/>