W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

RE: questions regarding draft-ietf-http-authentication-01

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 27 Mar 1998 15:25:56 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587031E3CA6@red-msg-51.dns.microsoft.com>
To: "HTTP-WG@cuckoo.hpl.hp.com" <http-wg@cuckoo.hpl.hp.com>, "'Ronald.Tschalaer@psi.ch'" <Ronald.Tschalaer@psi.ch>


> ----------
> From: 	Ronald.Tschalaer@psi.ch[SMTP:Ronald.Tschalaer@psi.ch]
> Sent: 	Friday, March 27, 1998 1:36 AM
> To: 	HTTP-WG@cuckoo.hpl.hp.com
> Subject: 	Re: questions regarding draft-ietf-http-authentication-01
> 
> 
> > 1)  Section 3.2.2, request-digest description:
> > 
> >         If the "qop" value is "auth":
> [snip]
> >     Shouldn't that be
> > 
> >         If the "qop" value is "auth" or "auth-int":
> [snip]
> 
> Ooops, sorry, my scan of David Kristol's mail missed that he had already
> mentioned this.
> 
> However, on to more questions and comments regarding
> draft-ietf-http-authentication-01.txt :
> 
> 3) Section 3.2.2, digest-response description:
> 
>         digest-response  = 1#( username | realm | nonce | digest-uri |
>                            response | [ algorithm ] | [cnonce] |
>                            [opaque] | [server] | [message-qop] |
>                                      ^^^^^^^^^^^
>                            [ nonce-count ] )
> 
>     "server" is not defined anywhere. What is the syntax supposed to
>     be, and what purpose does it serve?
> 
Left from a previous edit. It shouldn't be there.


> 4) Section 3.2.2, digest-response description:
> 
>         cnonce
>           An opaque quoted string value provided by the client and used by
> both
>           client and server to avoid chosen plaintext attacks, to provide
>           mutual authentication, and to provide some message integrity
>           protection.  See the descriptions below of the calculation of
> the
>           response-digest and request-digest values.
> 
>         nonce-count
>           This MUST be specified if a qop attribute is sent (see above),
> and
>           MUST NOT be specified if the server did not send a qop attribute
> in
>           the WWW-Authenticate header field. ...
> 
>     I presume the "MUST NOT" above is to avoid problems with rfc-2068
>     implementations which might not handle an unknown attribute correctly
>     (although they ought to just be ignoring it)? If so, why isn't the
>     same language used for the cnonce? I.e. something like
> 
>         cnonce
>           An opaque quoted string value provided by the client and used by
> both
>           client and server to avoid chosen plaintext attacks, to provide
>           mutual authentication, and to provide some message integrity
>           protection.  See the descriptions below of the calculation of
> the
>           response-digest and request-digest values. This attribute MUST
> NOT
>           be specified if the server did not send a qop attribute in the
>           WWW-Authenticate header field.
> 
Actually, I don't know why the MUST NOT is there. But it does serve the
purpose you suggest, so why not put it in both places. Sure.


> 5) For backwards compatibility with rfc-2069 there should be words to
>    explictly prevent a server from sending "algorithm=MD5-sess" but no
>    qop attribute. Maybe something like the following (just reusing the
>    wording from above again):
> 
>         algorithm
>           A string indicating a pair of algorithms used to produce the
> digest
>           and a checksum. If this is not present it is assumed to be
> "MD5".
>           ...
>           colon concatenated with the data. The "MD5-sess" algorithm is
>           intended to allow efficient 3rd party authentication servers;
>           for the difference in usage, see the description. The "MD5-sess"
>           algorithm MUST NOT be specified if the qop-options attribute
>           is not present.
> 
I appreciate the intent, but I don't think this helps backward compatibility
at all. If the client doesn't understand MD5-Sess, then adding "qop" (which
isn't in 2069 either) won't help.


> 6) The "algorithm" attribute is defined as:
> 
>         algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" )
> 
>      whereas rfc-2069 used the more general form
> 
>         algorithm           = "algorithm" "=" ( "MD5" | token )
> 
>      In the interest of possible future enhancements, I suggest changing
>      the current definition to:
> 
>         algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
> 
Sure.


> 7) Section 3.2.2, a small nit:
> 
>         response
>           A string of 32 hex digits computed as defined below, which
> proves
>  
> ^^^^^^
>           that the user knows a password
> 
>     I'm not very familiar with usage of "prove" in cryptographic circles,
>     but a correct "response" attribute certainly does not prove anything
>     in a mathematical sense. How about
> 
>         response
>           A string of 32 hex digits computed as defined below. The
> reception
>           of a correct response provides a strong indication that the user
>           knows a password.
> 
The use is consistent with crypto use.

> 8) Section 3.2.3: no words prohibit the server from sending, say, a qop
>    attribute but not a rspauth attribute. Also, while the cnonce is
>    required to be the same as used in the request, the nonce-count isn't.
>    Hence I propose the following change in wording:
> 
>    Replace
> 
>         where "Status-Code" is the status code (e.g., "200") from the
>         "Status-Line" of the response, as defined in section 6.1 of [2],
>         and "digest-uri-value" is the value of the "uri" directive on the
>         Authorization header in the request. The "cnonce-value" MUST be
>         one for the client request to which this message is the response.
> 
>    by
> 
>         where "Status-Code" is the status code (e.g., "200") from the
>         "Status-Line" of the response, as defined in section 6.1 of [2],
>         and "digest-uri-value" is the value of the "uri" directive on the
>         Authorization header in the request. The "cnonce-value" and
>         "nc-value" MUST be the ones used in the client request to which
>         this message is the response.
> 
>         The "response-auth", "cnonce", and "nonce-count" attributes MUST
>         BE present if "qop=auth" or "qop=auth-int" is specified.
> 
Good. Thanks for the proposed wording.


> 9) Section 3.2.3: Actually, why are the cnonce and nonce-count attributes
>    sent in the Authorization-Info header? Or put differently, what makes
>    these two attributes special, as opposed to the nonce and uri (which
>    aren't sent back)?
> 
Good question.

> 10) Section 3.2.2:
> 
>         Implementers should be aware of how authenticated transactions
>         interact with shared caches. The HTTP/1.1 protocol specifies that
>         when a shared cache (see section 13.10 of [2]) has received a
>                                          ^^^^^
>         request containing an Authorization header and a response from
>         relaying that request, it MUST NOT return that response as a
>         reply to any other request, unless one of two Cache-Control (see
>         section 14.9 of [2]) directives was present in the response. If
>                 ^^^^
> 
>     Shouldn't those be sections 13.7 and 14.8, respectively?
> 
Quite possibly. They may have renumbered the HTTP/1.1 spec while we weren't
noticing.

> 11) What's the status of the AUTH-INFO-SYNTAX issue? The issues page
>     http://www.w3.org/Protocols/HTTP/Issues/ lists the status as
> "Drafting",
>     but it's not in the current draft.
> 
I never saw it. I don't know why it's closed. I'll make the change it
requested.

Paul
Received on Saturday, 28 March 1998 04:45:08 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:14 EDT