SimpleMD5 access authentication, second draft

I submitted this proposal yesterday to the WG list.  I have incorporated a
few revisions, and am submitting it again:

1.  Remove tab characters to clean up formatting
2.  Clarify intent of <opaque>
3.  Clarify intent of <oldNonce>
4.  Clarify that the header lines are single-line.
5.  Clarify the server's responsibility for comparing the MD5 hash.

Thanks for the comments.  I will be gone for a week or so over the Christmas
holiday.

Happy Holidays!

-- cut here --

[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

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   Distribution of this document is unlimited. Please send comments
   to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
   Discussions of the working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
   about HTTP and the applications which use HTTP should take place
   on the <www-talk@info.cern.ch> mailing list.

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 "SimpleMD5
   Access Authentication".  The encryption method used is the RSA Data
   Security, Inc. MD5 Message-Digest Algorithm.

Table of Contents

   1.  Introduction
       1.1  Purpose
       1.2  Overall Operation
   2.  Basic Access Authentication Scheme
       2.1  Specification
       2.2  Security protocol negotiation
       2.3  Example
   3.  Acknowledgments
   4.  References
   5.  Authors Addresses


1. Introduction

1.1  Purpose

   The protocol referred to as "HTTP/1.0" includes specification
   for a Basic Access Authentication scheme[1].  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 "SimpleMD5
   Access Authentication".

   The SimpleMD5 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 the proposed HTTP/1.1 specification.

1.2  Overall Operation

   Like Basic Access Authentication, the SimpleMD5 scheme is based on
   a simple challenge-response paradigm.  The SimpleMD5 scheme challenges
   using a nonce value.  A valid response contains the MD5 checksum of
   the password and the given nonce value.  In this way, the password
   is never sent in the clear.  Just as with the Basic scheme, the
   username and password must be prearranged in some fashion.


2. SimpleMD5 Access Authentication Scheme

2.1 Specification

   The SimpleMD5 Access Authentication scheme is conceptually similar to
   the Basic scheme.  The formats of the modified WWW-Authenticate header line
   and the Authorization header line are specified below.

   Due to formatting constraints, both the WWW-Authenticate and the
   Authorization header are depicted on multiple lines.  In actual usage,
   they are required to be a single line of comma-separated attribute-value
   pairs, terminated by <CRLF>.  Whitespace between the attribute-value pairs
   is allowed.

   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>"

   The client is expected to retry the request, passing an Authorization header
   line as follows:

Authorization: SimpleMD5    username="<username>",
                            realm="<realm>",
                            nonce="<nonce>",
                            response="<MD5response>",
                            opaque="<opaque>"

   The meanings of the identifers used above are as follows:

      <realm>
         A name given to users so they know which username and password
         to send.

      <domain>
         A comma separated list of URIs, as specified for HTTP/1.0.  The
         intent is that the client could use this information to know the
         set of URIs for which the same authentication information should be
         sent.  The URIs in this list may exist on different servers.  If
         this keyword is omitted or empty, the client should assume that
         the domain consists of all URIs on the responding server.

      <nonce>
         A server-specified integer value which may be uniquely generated
each time
         a 401 response is made.  Servers may defend themselves against replay
         attacks by refusing to reuse nonce values.

      <opaque>
         A string of data, specified by the server, which should returned by
         the client unchanged.  It is recommended that this string be
         base64 or hexadecimal data.  Specifically, since the string is passed
         in the header lines as a quoted string, the double-quote character
         is not allowed.

      <username>
         It is assumed that both client and server know of a prearranged
         username and password pair.  The Authorization header returned
         by the client specifies the username.  The password is not specified
         in the clear.

      <response>
         The MD5 encoding of "<nonce> <password>".  The resulting string
         should be a 32 digit hexadecimal string.

      <oldNonce>
         A flag, indicating that the previous request from the client
         was rejected because the nonce value was stale.  If oldNonce
         is TRUE, the client may wish to simply retry the request with
         a new encrypted response, without reprompting the user for a
         new username and password.

   Upon receiving the Authorization information, the server may check its
   validity by looking up its known password which corresponds to the submitted
   <username>.  Then, the server must perform the same MD5 operation performed
   by the client, and compare the result to the given <response>.

   When the server is constructing the WWW-Authenticate header, the domain,
   opaque, and oldNonce keywords may be omitted.

   All keyword-value pairs must be expressed in characters from the
   US-ASCII character set, excluding control characters.

   A client may remember the username, password and nonce values, so that
   future requests within the specified <domain> may include the Authorization
   line preemptively.  The server may choose to accept the old Authorization
   information, even though the nonce value included might not be fresh.
   Alternatively, the server could return a 401 response with a new nonce
   value, causing the client to retry the request.  By specifying oldNonce=TRUE
   with this response, the server hints to the client that the request should
   be retried with the new nonce, without reprompting the user for a new
   username and password.

   The <opaque> data is useful for transporting state information around.
   For example, a server could be responsible for authenticating content
   which actual sits on another server.  The first 401 response would include
   a <domain> which includes the URI on the second server, and the <opaque>
   for specifying state information.  The client will retry the request, at
   which time the server may respond with a 301/302 redirection, pointing
   to the URI on the second server.  The client will follow the redirection,
   and pass the same Authorization line, including the <opaque> data which
   the second server may require.

   As with the basic scheme, proxies must be completely transparent in
   the SimpleMD5 access authentication scheme. That is, they must forward the
   WWW-Authenticate and Authorization headers untouched. If a proxy
   wants to authenticate a client before a request is forwarded to
   the server, it can be done using the Proxy-Authenticate and
   Proxy-Authorization headers.

2.2 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes
   a client is capable of handling.  It is recommended that the HTTP extension
   mechanism proposed by Dave Kristol [2] be used.  If the client includes
   the following header line with the request, then a server can safely assume
   that the client can handle SimpleMD5 authentication.

Extension: Security SimpleMD5

   If this proposal is accepted as a required part of the HTTP/1.1
   specification, then a server may assume SimpleMD5 support when a client
   identifies itself as HTTP/1.1 compliant, by sending:

HTTP-Version: HTTP/1.1

   It is possible that a server may want to require SimpleMD5 as its
   authentication method, even if the server does not know that the client
   supports it.  A client is encouraged to fail gracefully if the server
   specifies any authorization scheme it cannot handle.

2.3 Example

   The following example assumes that an access-protected document is being
   requested from the server.  Both client and server know that the username
   for this document is "Mufasa", and the password is "CircleOfLife".

   The first time the client requests the document, no Authorization header
   is sent, so the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: SimpleMD5 realm="PrideRock",
                            domain="",
                            nonce="67654464",
                            opaque="76da3afcb7c9a0",
                            oldNonce="FALSE"

   The client may prompt the user for the username and password, after which it
   will respond with a new request, including the following Authorization
header:

Authorization: SimpleMD5    username="Mufasa",
                            realm="PrideRock",
                            nonce="67654464",
                            response="9524c2516e37df5c6a3c7ef5e334a31b",
                            opaque="76da3afcb7c9a0"

   Note that the hexadecimal string for the response is the MD5 encoding of
   "67654464 CircleOfLife".  The space character between the nonce value and the
   password is required, and part of the encrypted result.

3. Acknowledgments

   Larry Stewart, at OpenMarket, Inc., contributed to the development and
   implementation of this authorization scheme.

   Source code in C for the RSA Data Security, Inc. MD5 Message-Digest
   Algorithm is available free of charge from RSA Data Security, Inc.

4. References

   [1]  T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
        "Hypertext Transfer Protocol -- HTTP/1.0"
        Internet-Draft (work in progress), UC Irvine,
        <URL:http://ds.internic.net/internet-drafts/
        draft-fielding-http-spec-01.txt>, December 1994.

   [2]  D. Kristol. "A Proposed Extension Mechanism for HTTP"
        <URL:http://www.research.att.com/~dmk/extend.txt>,
        December 1994.

5. Authors Addresses

   Jeffery L. Hostetler
   jeff@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   1800 Woodfield Drive
   Savoy, IL  61874

   Eric W. Sink
   eric@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   1800 Woodfield Drive
   Savoy, IL  61874

--
Eric W. Sink, Senior Software Engineer --  eric@spyglass.com
                                           I don't speak for Spyglass.
"Can I get a direct flight back to reality, or do I have to change planes
in Denver?" - The Santa Clause

Received on Thursday, 22 December 1994 10:49:53 UTC