- 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
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 john@math.nwu.edu
Received on Tuesday, 14 April 1998 14:52:14 UTC