W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: HTTP-authentication-01.txt comments

From: John Franks <john@math.nwu.edu>
Date: Tue, 14 Apr 1998 15:27:05 -0500 (CDT)
To: Dave Kristol <dmk@bell-labs.com>
Cc: John Franks <john@dehn.math.nwu.edu>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.LNX.3.96.980414151424.15175C-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/51
On Tue, 14 Apr 1998, Dave Kristol wrote:

> John Franks wrote:
> > 
> > On Mon, 13 Apr 1998, Dave Kristol wrote:
> > 
> > >
> > > If (to use cnonce as the example) cnonce was omitted, should
> > > Authentication-Info omit cnonce, or should it send cnonce=""?  Same
> > > question for auth.
> > >
> > 
> > It might be better to say that Authentication-Info should only be
> > sent if qop (and hence cnonce) are present.
> But cnonce is not required, even when qop is specified.  Only
> nonce-count is required.

I think this is an oversight.  I suspect the intent was that
cnonce MUST be supplied if qop is.

> > 
> > Another question: Unless I am mistaken, at one point in the long
> > sequence of digest drafts, the Authentication-Info header could be
> > supplied by either the server or the client.  It would be useful
> > for the client to be able to supply the digest of POSTed data
> > or a file which is PUT.  Being able to assure the integrity of
> > client supplied data would be very useful.  Did this fall through
> > the cracks, or am I just missing this functionality somewhere in
> > the draft?
> Hmmm.  There does not seem to be a way for the client to send a digest
> of the entity-body.  If it could, though, there's an ambiguity about
> qop=auth-int:

Actually Scott Lawrence straightened me out about this.  The client's
POSTed or PUT data must be MD5 digested if qop="auth-int".  The digest
result is part or the response digest.  It is included in "A2" in
the case that qop="auth-int".

> 1) C<-S
> 	HTTP/1.1 401 Unauthorized
> 	WWW-Authenticate: ... qop="auth,auth-int", ...
> 2) C->S (speculative)
> 	POST /some/entity HTTP/1.1
> 	Host: blah
> 	Authorization: ... qop=auth-int, ...
> 	Authentication-Info:  reqauth=<some suitable digest>, ...
> 3) C<-S (problematic)
> 	HTTP/1.1 200 OK
> 	Authentication-Info:  qop=auth-int, rspauth=<entity digest>
> The problem is that the client chose (this is speculative -- the spec.
> doesn't read this way) "auth-int", in order to send an entity digest.
> But the server is obliged to respond in kind, which means it must do a
> digest of what is probably not a very interesting response.

Actually I think the spec DOES read this way and the server is
required to respond with a digest of what may be an uninteresting
response.  The choice is not entirely with the client.  The server
may only offer one of "auth" or "auth-int".  But if it offers both
the client gets to pick and the server must digest its response.

John Franks
Received on Tuesday, 14 April 1998 14:52:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC