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

>>>>> "PL" == Paul Leach <paulle@MICROSOFT.com> writes:

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

  This may be a merge problem - in my working draft, the definition of
  request-digest is followed by:
===
    If the "qop" value is "auth-int", then request-digest is as for
    "auth", except that A2 is computed as:

      A2 = method ":" digest-uri-value ":" H(entity-body)
===
  this may have been accidentally dropped merging my edits with Pauls.

>> "server" is not defined anywhere. What is the syntax supposed to
>> be, and what purpose does it serve?

PL> Left from a previous edit. It shouldn't be there.

  Agreed.

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

PL> Actually, I don't know why the MUST NOT is there. But it does serve the
PL> purpose you suggest, so why not put it in both places. Sure.

  I wrote that section, and yes, the idea was be explicit that the
  behaviour should be as specified by 2069 in this case.  Perhaps it
  is stronger than it needs to be.

>> In the interest of possible future enhancements, I suggest changing
>> the current definition to:
>>
>> algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )

PL> Sure.

  Agreed.

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

PL> Good. Thanks for the proposed wording.

  This was a cut-and-paste error, I think; the nc-value is not used in
  the construction of the response-digest, so it need not be in the
  syntax for the Authentication-Info header at all.  From client to
  server the requests may be pipelined, so we needed the nonce count
  to prevent replay, but each response is to exactly one unique
  request, so no count is needed or used.

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

PL> Good question.

  See above for nonce-count; I thought that returning the cnonce value
  might make implementation in the client easier; the client can then
  use the same kind of self-validation that servers can with nonces so
  that they need not be actually stored while waiting for the response.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Sunday, 29 March 1998 11:22:19 UTC