- From: John Franks <john@math.nwu.edu>
- Date: Thu, 22 Dec 1994 09:22:37 -0600 (CST)
- To: "Eric W. Sink" <eric@spyglass.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Eric W. Sink: > -- > > [PROPOSED] HTTP Working Group Jeffery L. Hostetler > INTERNET-DRAFT Eric W. Sink > <draft-NOT_YET_SUBMITTED-simplemd5-aa-00.txt> > Expires SIX MONTHS FROM---> December 21, 1994 > > A Proposed Extension to HTTP : SimpleMD5 Access Authentication > This is a very good proposal and should be included as part of HTTP1.1. There are a couple of things I would like to clarify though. > > If a server receives a request for an access-protected object, > and an acceptable Authorizatation header is not sent, the server > responds with: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: SimpleMD5 realm="<realm>", > domain="<domain>", > nonce="<nonce>", > opaque="<opaque>", > oldNonce="<true | > false>" > Does this mean the following? HTTP/1.1 401 Unauthorized<CRLF> WWW-Authenticate: SimpleMD5 realm="<realm>", domain="<domain>",\\ nonce="<nonce>", opaque="<opaque>", oldNonce="<true | false>"<CRLF> I.e. should the WWW-Authenticate header be a single line of ',' separated key-value pairs terminated by <CRLF>? Is whitespace also ok between key-value pairs? Presumably the same format would apply to this: > > Authorization: SimpleMD5 username="<username>", > realm="<realm>", > nonce="<nonce>", > > response="<MD5response>", > opaque="<opaque>" Another question: > <response> > The MD5 encoding of "<nonce> <password>". The resulting string > should be a 32 digit hexadecimal string. Is there a space between <nonce> and <password> that gets encoded? If so that should be explicitly stated. It might be better to use a visible character there, e.g. make response be the MD5 encoding of "<nonce>:<password>". Finally, what is the intended function (or functions) of opaque? It might be nice to have a sentence like "Possible uses of the <opaque> string include..." Things like an encoded timestamp or for nonce aging or encoded IP address of the client come to mind, but there are likely other potential uses. John Franks
Received on Thursday, 22 December 1994 07:24:22 UTC