[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF last call comments on RADIUS Digest AWUthentcation
---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 14:31:45 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: "Beck01, Wolfgang" <BeckW@t-systems.com>
Cc: aboba@internaut.com, bwijnen@lucent.com, david.kessens@nokia.com,
dnelson@enterasys.com, john.loughney@nokia.com, dromasca@avay.com,
miguel.an.garcia@nokia.com
Subject: Re: AW: IETF last call comments on RADIUS Digest Authentication
docum
ent
Beck01, Wolfgang wrote:
Alexey,
my main focus for the -07 version was to address the 'discuss'
points from the IESG site.
That is fine. I was under impression that all issues raised were addressed
in
-07.
> 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.
I guess you can do that. In which case you still have to say that Digest
servers
MUST unescape values before processing them, as this is not obvious (I
certainly
wouldn't have implemented this way).
> 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.
I've seen this change and it improved the readability, thank you. But I
still
want another example ;-).
> 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."
Ok. The original issue seemed to be addressed.
> 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...
There is a tradeoff, IMHO, the document should explain both problems with
following and not following MAY. This would be much better than just
explaining
one side.
> 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.'?
The best I can see is to use conditional "if C, then MAY ..., else MUST
...".
I suggested specific text above, do you think it is wrong?
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.
I will get back to you on this one.
> 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.
I am not saying that doing one way or another is *difficult*. I am just
pointing
out that there are existing implementations which can't cope with
"qop=foo,qop=bar". They will either treat it is an error, or ignore all but
the
last value.
> 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.
> >
There are two attributes with nearly identical meaning. The document doesn't
explain why both ot them are needed. An example you've mentioned will
explain
why both are needed.
> 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.
Sorry, this doesn't prove anything.
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/>