- From: John Franks <john@math.nwu.edu>
- Date: Wed, 11 Sep 1996 11:19:30 -0500 (CDT)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Fri, 6 Sep 1996, Larry Masinter wrote: > > I'll let those who want to make proposed changes to the digest > authentication draft suggest them on the list, and hope that we can > arrive at our own conclusions quickly. > > This is just a 'heads up' so that people might expect to respond > fairly quickly. I think most of the changes are editorial, but, > because of where we are in the process, we need clear direction from > YOU. > > Larry > (http-wg chair) > There has been some dissatisfaction with the description of what the protocol provides. Accordingly we will try to accommodate these concerns. Please, this is NOT an invitation to suggest new changes, even if you have a great new idea or an incredible editorial suggestion. Any substantive change at this point will stop the publication of the digest specification and could delay the publication of the HTTP/1.1 specification. What we need now is to know if anyone has serious objections to the changes described below. The changes made are all editorial in nature. They have no effect on the protocol specified and are only changes in the description of what the protocol accomplishes. The primary change was in the abstract, and one other sentence where version 04 spoke of "secure access authentication". Some potential implementors felt that this description is too strong and preferred weaker claims. We have accommodated this request. We also took the opportunity to correct some typographical errors and to remove one paragraph which made an erroneous assertion about the definition of "quoted-string" in the HTTP/1.1 specification. The diffs from version 04 to 05 are attached below. The complete new version (version 05) can be obtained at http://hopf.math.nwu.edu/~john/draft-ietf-http-digest-aa-05.txt John Franks Dept of Math. Northwestern University john@math.nwu.edu *** draft.04 Tue Sep 10 07:53:02 1996 --- draft.05 Tue Sep 10 09:09:48 1996 *************** *** 1,16 **** HTTP Working Group John Franks INTERNET-DRAFT Philip Hallam-Baker ! <draft-ietf-http-digest-aa-04.txt> Jeffery L. Hostetler Paul Leach Ari Luotonen Eric W. Sink Lawrence C. Stewart ! Expires SIX MONTHS FROM---> June 6, 1996 ! A Proposed Extension to HTTP : Digest Access Authentication Status of this Memo --- 1,16 ---- HTTP Working Group John Franks INTERNET-DRAFT Philip Hallam-Baker ! <draft-ietf-http-digest-aa-05.txt> Jeffery L. Hostetler Paul Leach Ari Luotonen Eric W. Sink Lawrence C. Stewart ! Expires SIX MONTHS FROM---> Sept. 10, 1996 ! An Extension to HTTP : Digest Access Authentication Status of this Memo *************** *** 41,55 **** Abstract ! The protocol referred to as "HTTP/1.0" includes specification for a ! Basic Access Authentication scheme. This scheme is not considered to ! be a secure method of user authentication, as the user name and ! password are passed over the network in an unencrypted form. A ! specification for a new authentication scheme is needed for future ! versions of the HTTP protocol. This document provides specification ! for such a scheme, referred to as "Digest Access Authentication". ! The digesting method used by default is the RSA Data Security, Inc. ! MD5 Message-Digest Algorithm [3]. --- 41,59 ---- Abstract ! The protocol referred to as "HTTP/1.0" includes the specification for ! a Basic Access Authentication scheme. This scheme is not considered ! to be a secure method of user authentication, as the user name and ! password are passed over the network as clear text. A specification ! for a different authentication scheme is needed to address this severe ! limitation. This document provides specification for such a scheme, ! referred to as "Digest Access Authentication". Like Basic, Digest ! access authentication verifies that both parties to a communication ! know a shared secret (a password); unlike Basic, this verification can ! be done without sending the password in the clear, which is Basic's ! biggest weakness. As with most other authentication protocols, the ! greatest sources of risks are usually found not in the core protocol ! itself but in policies and procedures surrounding its use. *************** *** 117,124 **** The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This ! scheme provides no encryption of object content. The intent is ! simply to facilitate secure access authentication. It is proposed that this access authentication scheme be included in the proposed HTTP/1.1 specification. --- 121,129 ---- The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This ! scheme provides no encryption of object content. The intent is simply ! to create a weak access authentication method which avoids the most ! serious flaws of Basic authentication. It is proposed that this access authentication scheme be included in the proposed HTTP/1.1 specification. *************** *** 169,184 **** commonly used with telnet and ftp, and better than Basic authentication. - Some keyword-value pairs occurring in headers described below are - required to have values which are of the type "quoted-string" as - defined in section 2.2 of the HTTP/1.1 specification [2]. A - consequence is that these values represent strings in the US-ASCII - character set. An unfortunate side effect of this is that digest - authentication is not capable of handling either user names or realm - names (see 2.1.1 below) which are not expressed in this character set. - 2. Digest Access Authentication Scheme --- 174,181 ---- *************** *** 470,476 **** of the response has not been changed en-route. The server would probably only send this when it has the document and can compute it. The server would probably not bother generating this header for CGI ! output. The value of the "digested-entity" is an <entity-digest> which is computed as described above. The value of the nextnonce parameter is the nonce the server wishes --- 467,473 ---- of the response has not been changed en-route. The server would probably only send this when it has the document and can compute it. The server would probably not bother generating this header for CGI ! output. The value of the "digest" is an <entity-digest> which is computed as described above. The value of the nextnonce parameter is the nonce the server wishes
Received on Wednesday, 11 September 1996 09:26:48 UTC