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?


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.


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.


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 )


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.


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.


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


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?


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.


  Cheers,

  Ronald

Received on Friday, 27 March 1998 02:47:40 UTC