[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF last call comments on RADIUS Digest Authentication document
---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 15:02:28 +0100
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: alexey.melnikov@isode.com, aboba@internaut.com
Cc: bwijnen@lucent.com, david.kessens@nokia.com, dnelson@enterasys.com,
john.loughney@nokia.com, dromasca@avay.com, miguel.an.garcia@nokia.com
Subject: AW: IETF last call comments on RADIUS Digest Authentication
document
Alexey,
my main focus for the -07 version was to address the 'discuss'
points from the IESG site.
1). [Major]: Everywhere in section 4: all references to "without quotes"
[..]
[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.
Why do you think the RADIUS client should deal with escapes?
It does not look into the values. That's the RADIUS server's
task.
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.
[..]
[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.
I've split up the larger text blocks into sections to make it easier
to follow.
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.
I can't find the quoted section in -07. The closest match is:
"The RADIUS server can send Digest-Qop, Digest-
Algorithm, Digest-Domain and Digest-Opaque attributes in the Access-
Challenge carrying the nonce. If these attributes are present, the
client MUST use them."
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.
Not following the MAY might result in cracked passwords...
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).
We have discussed that before. How do you express 'A MUST be sent if
conditions C holds, and MAY be sent if condition C doesn't hold.'?
Is A mandatory? Is A optional?
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."
See the 'Text' paragraph of the section.
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.>>
A RADIUS attribute consisting of a list of items would be a structured
attribute.
The use of structured attributes is >>highly<< controversial in the WG.
I dont see a problem with existing implementations. The server has to parse
the RADIUS message anyway. If you have a RfC 2617 lib, just concat the
attributes
to form a comma-separated list.
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.
Implementers of the original draft-sterman didn't seem to have that
problem.
Thanks for your efforts,
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/>