Digest access authentication format
yawnmoth
username = "username" "=" username-value
username-value = quoted-string
digest-uri = "uri" "=" digest-uri-value
digest-uri-value = request-uri ; As specified by HTTP/1.1
From a Wireshark capture of Digest access authentication:
Authorization: Digest username="test", realm="...",
nonce="AAR638Epy8c=89095bd24b74677157136987475f5b678ca33945", uri="/
path/to/test.php", algorithm=MD5,
response="44ace83593f6562119a38aef0c34b76a", qop=auth, nc=00000007,
cnonce="c4859daa492b97e6"
My question is... why does uri, in the Wireshark capture, have double
quotes? username has them because quoted-string (which is what
username-value is defined as) has them but request-uri (which is what
digest-uri-value is defined as), as defined in <http://tools.ietf.org/
html/rfc2616#section-5.1.2> does not appear to. So why are they there?
yawnmoth
Related to this, <http://tools.ietf.org/html/rfc2069#section-2.1.2>'s
Authorization header has an optional parameter - digest. <http://
tools.ietf.org/html/rfc2617#section-3.2.2>, however, makes no mention
of a digest header. Why was the 'digest' header dropped? (note that I
haven't read all of RFC2617 yet so if it's explained further within
that I probably just haven't gotten to that part of it).
Also, what's the point of including an algorithm parameter in the
Authorization header? The domains parameter, as defined in the WWW-
Authorize header, isn't returned in the Authorization header because
presumably it'd serve no point. It seems to me that the algorithm
parameter is similarly pointless? And if the client can pick and
choose what algorithms it wants to use then why does the server send
the algorithm parameter in the WWW-Authorize header? It doesn't seem
to me that RFC2617 has any provisions for algorithm negotiation so
it's not as if the server can say "here's a list of algorithms I
support" and the client can pick among them.
Ilmari Karonen
>
> Also, what's the point of including an algorithm parameter in the
> Authorization header? The domains parameter, as defined in the WWW-
> Authorize header, isn't returned in the Authorization header because
> presumably it'd serve no point. It seems to me that the algorithm
> parameter is similarly pointless? And if the client can pick and
> choose what algorithms it wants to use then why does the server send
> the algorithm parameter in the WWW-Authorize header? It doesn't seem
> to me that RFC2617 has any provisions for algorithm negotiation so
> it's not as if the server can say "here's a list of algorithms I
> support" and the client can pick among them.
I know nothing about RFC 2917, but in general I'd assume that, even in
the absence of an explicit negotiation mechanism, the server might
still (in principle, at least) choose to use different algorithms with
different clients (if, say, it knew that some clients only support
certain algorithms). Including the algorithm identifier in the client
header means the server won't have to remember (or guess) which
algorithm it asked this particular client to use.
Also, specifying the algorithm in the header may allow for more
informative server error messages ("wrong hash algorithm used" instead
of just an opaque "authentication failed"). It could also be useful
for miscellaneous debugging purposes. And it's not like including it
carries any significant cost.
--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.