authentication issues

draft-ietf-http-authentication-03 does not specify whether the
"algorithm" and "qop" attributes are case-sensitive or case-insensitive.
I presume they are both meant to be case-insensitive (which is also
supported by the code in section 5) and therefore suggest the following
changes:

Section 3.2.1, change 

  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". If
    the algorithm is not understood, the challenge should be ignored (and
    a different one used, if there is more than one).

to

  algorithm
    A string (case-insensitive) indicating a pair of algorithms used to
    produce the digest and a checksum. If this is not present it is assumed
    to be "MD5". If the algorithm is not understood, the challenge should be
    ignored (and a different one used, if there is more than one).

and change

  qop-options
    This directive is optional, but is made so only for backward
    compatibility with RFC 2069 [6]; it SHOULD be used by all
    implementations compliant with this version of the Digest scheme.
    If present, it is a quoted string of one or more tokens indicating
    the "quality of protection" values supported by the server.  The
    value "auth" indicates authentication; the value "auth-int" indicates
    authentication with integrity protection; see the descriptions below
    for calculating the response directive value for the application of
    this choice. Unrecognized options MUST be ignored.

to 

  qop-options
    This directive is optional, but is made so only for backward
    compatibility with RFC 2069 [6]; it SHOULD be used by all
    implementations compliant with this version of the Digest scheme.
    If present, it is a quoted string of one or more case-insensitive
    tokens indicating the "quality of protection" values supported by
    the server.  The value "auth" indicates authentication; the value
    "auth-int" indicates authentication with integrity protection; see
    the descriptions below for calculating the response directive value
    for the application of this choice. Unrecognized options MUST be
    ignored.

I believe the case-sensitivity of the other attributes can be safely
implied by virtue of them defined elsewhere (URIs) or by being opaque to
the client (nonce, nextnonce, and opaque).

Finally, I have some nits with the code in Section 5:

  void main(int argc, char ** argv) {

is invalid ansi C, and should be

  int main(int argc, char ** argv) {

(and a "return 0;" should probably also be added to the end too). In
CvtHex()

	    Hex[i*2] = (j + 'a' - 10);

is not guaranteed to work correctly (i.e. ('b' == 'a'+1) need not be
true). Under both ASCII and EBCDIC this will be correct, however. A
nicer (IMHO) and more portable solution would be to use something like
the following:

const char *HexVal = "0123456789abcdef";
...
    for (i = 0; i < HASHLEN; i++) {
	Hex[i*2]   = HexVal[(Bin[i] >> 4) & 0xf];
	Hex[i*2+1] = HexVal[Bin[i] & 0xf];
    }

And lastly, since stricmp() is non-standard (neither ANSI C nor POSIX) it
might be worth mentioning that it is supposed to be case-insensitive
version of strcmp() .


  Cheers,

  Ronald

Received on Friday, 20 November 1998 18:02:53 UTC