Dunno if there will be another authentication draft or not.
In any case, such comments go to the http working group mailing list;
I'm forwarding them there.
- Jim
Forwarded message 1
Hello Jim,
Here are some of the notes I have been taking while implementating
this protocol inside libwww.
If the authors or editor find them interesting, it'd be nice to have
an acknowledgment somewhere :)
I'm also planning to make a formal analysis of the security protocol
later on.
If things work out correctly, we'll ship a first implementation of the
protocol next week, inside Amaya. At least, it'll be backward
compatible with previous message digest protocol and will work with the
code shipped inside the latest Apache.
If I can make some interoperability tests during this week, I'll be able to
provide more new features.
Cheers,
-Jose
=========================================
Notes on the Internet-Draft <draft-ietf-http-authentication-03>
by: Jose Kahan (kahan@w3.org)
Who am I?
I'm currently implementing the digest authentication protocol inside libwww.
General impression:
Nice draft and easy to read. The C code for digest authentication
works right out of the box.
I have some remarks concerning digest authentication.
==========
pg. 9
About domains... consider the following scenario:
* client request URL1
* server sends back a challenge, with a domain value (list of URLs)
* later on, client requests URL1
* server sends back a new challenge, with no domain valeu
* later on, client requests URL1
* server sends back a new challenge, with a different domain value
Should the client keep a track of the "root" URL which gave access to a
domain and invalidate that domain whenever the challenge for the "root" URL
changes?
Another scenario
* client request URL
* server sends back a challenge, with a domain value (list of URLs)
* client requests one of the URLs in the domain, which happens to
be stored in server 2
* server 2 sends back a new challenge, with another domain value
Is server 2 authoritative, in that it can tell the client that the same
password can be used with other domains, or it should only be the case with
the "root" URL?
===========
pg. 11
Algorithm sounds confusing when combined with the word "MD5".
MD5 is a message digest algorithm, indepent of the one used by the
authentication protocol.
I'd redefine the two algorithms as "MD5-base", "MD5-sess". Better, I'd
separate this word into two pieces:
"digest-algorithm" = (MD4 | MD5 | SHA | ...)
and use anoter keyword to precise the type of digest:
"digest-type" = "base" | "sess"
>From an implementor's points of view, this gives a better separation of
functionality and allows to write a more generic code. For example, in
my libwww implementation, I have three levels:
- a high level part deals with the "digest-type",
- a middle level which gives a generic interface to the message digest
algorithms
- a low level part, where the digest algorithms are called.
Anyway, I think that what I call the "digest-type" is independent of
the "digest-algorithm".
================
pg. 12:
cnonce value is not quoted, but it is quoted in the example on pg. 18
================
pg. 12:
A suggestion or example on how to generate the cnonce would be useful.
===============
pg. 16
I suppose that the Authentication-Info header doesn't include a scheme
identifier (e.g., Digest) as the client already knows what scheme it used
when contacting the server. Maybe a paragraph precising this would be useful.
==============
pg. 18
the defy and response in the example don't include an algorithm string, but
9 and pg. 12 say they should.
------
That's it for the moment.
I hope this is helpful,
-Jose