Re: IESG Review of draft-ietf-radext-digest-auth-06.txt

["Bernard Aboba" <[e-mail]>]

>From: Alexey Melnikov <[e-mail]>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
>             Gecko/20040804 Netscape/7.2 (ax)
>X-Accept-Language: en-us, en
>To: "Beck01, Wolfgang" <[e-mail]>
>CC: [e-mail], [e-mail], 
>[e-mail]
>Subject: Re: IESG Review of draft-ietf-radext-digest-auth06.txt (fwd)

>
>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
>



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>