HTTP Working Group Jeffery L. Hostetler INTERNET-DRAFT John Franks <draft-ietf-http-digest-aa-03.txt> Philip Hallam-Baker Paul Leach Ari Luotonen Eric W. Sink Lawrence C. Stewart Expires SIX MONTHS FROM---> March 1, 1996 A Proposed Extension to HTTP : Digest 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@www10.w3.org> 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 "Digest Access Authentication". The encryption method used by default is the RSA Data Security, Inc. MD5 Message-Digest Algorithm [2]. Table of Contents 1. Introduction 1.1 Purpose 1.2 Overall Operation 1.3 Representation of MD5 digest values 2. Basic Access Authentication Scheme 2.1 Specification of Digest Headers 2.2 Digest Operation 2.3 Security protocol negotiation 2.4 Example 3. Security Considerations 4. Acknowledgments 5. References 6. 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 "Digest Access Authentication". 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. 1.2 Overall Operation Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by default the MD5 checksum) of the username, the password, the given nonce value, and the requested URI. 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 which is not addressed by this document. 1.3 Representation of digest values An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document. For the purposes of this document, an MD5 digest of 128 bits is represented as 32 ASCII printable characters. The bits in the 128 bit digest are converted from most significant to least significant bit, four bits at a time to their ASCII presentation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef. That is binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'. 1.4 Limitations The digest authentication scheme described in this document suffers from many known limitations. It is intended as a replacement for basic authentication and nothing more. It is a password-based system and (on the server side) suffers from all the same problems of any password system. In particular no provision is made in this protocol for the initial secure arrangement between user and server establishing the user's password. Users and implementors should be aware that this protocol is not as secure as kerberos, and not as secure as any client-side private-key scheme. Nevertheless it is better than nothing, better than what is commonly used with telnet and ftp and better than Basic authentication. 2. Digest Access Authentication Scheme 2.1 Specification of Digest Headers The Digest 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. In addition, a new header, Digest-MessageDigest, is specified as well. Due to formatting constraints, all of the headers are depicted here on multiple lines. In actual usage, they must follow the syntactic rules for HTTP/1.0 header lines [1]. Whitespace between the attribute-value pairs is allowed. If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="<realm>", domain="<domain>", nonce="<nonce>", opaque="<opaque>", stale="<TRUE | FALSE>", algorithm="<digest-algorithm>" The meanings of the identifiers used above are as follows: <realm> A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered users @ gotham.news.com." <domain> OPTIONAL 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 data string which may be uniquely generated each time a 401 response is made. 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. The contents of the nonce is implementation dependent. The quality of the implementation depends on a good choice. A recommended nonce would include H(<client IP> + ":" + <timestamp> + ":" + <private key> ) Where <client IP> is the dotted quad IP address of the client making the request, <timestamp> is a server generated time value, <private key> is data known only to the server. With a nonce of this form a server would normally recalculate the nonce after receiving the client authentication header and reject the request if it did not match the nonce from that header. In this way the server can limit the reuse of a nonce to the IP address to which it was issued and limit the time of the nonce's validity. A server might also wish to include the client request or the contents of the Host: header in the data digested to create the nonce. Further discussion of the rationale for nonce construction is in section 3.2 below. An implementation might choose not to accept a previously used <nonce> or a previously used <digest> to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a timestamp for GET requests. For more details on the issues involved see section 3. of this document. The nonce is opaque to the client. <opaque> OPTIONAL 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. <stale> OPTIONAL A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale 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. The server should only set stale to true if it receives a request for which the nonce is invalid but with a valid digest for that nonce (indicating the the client knows the correct username/password). <algorithm> OPTIONAL A string indicating the algorithm used to produce the digest or checksum. If this not present the MD5 algorithm is assumed. In this document the string obtained by applying this algorithm to the data "<data>" will be denoted by H(<data>). The client is expected to retry the request, passing an Authorization header line as follows: Authorization: Digest username="<username>", -- required realm="<realm>", -- required nonce="<nonce>", -- required uri="<requested-uri>", -- required response="<digest>", -- required message="<message-digest>", -- OPTIONAL algorithm="<digest-algorithm>" -- OPTIONAL opaque="<opaque>", -- required if provided by server where <digest> := H( H(A1) + ":" + N + ":" + H(A2) ) and <message-digest> := H( H(A1) + ":" + N + ":" + H(<entity-body>) ) where: A1 := U + ':' + R + ':' + P A2 := <Method> + ':' + <requested-uri> with: N -- nonce value U -- username R -- realm P -- password <Method> is the HTTP method specified at the beginning of the first line of the client request. <requested-uri> is the part of the requested URL transmitted by the client to the server in the first line of an HTTP request. In particular it does not include the "http://host:port" part of the URL but does include any "query" part which might, for example, include form data after a '?' in the URL. The purpose of the <message-digest> is to allow the server to ensure that the content of the request body has not been tampered with after leaving the client. This would normally be used with a POST or PUT request and would allow the server to check the validity of the posted data. The <entity-body> is the "entity body" as prescribed in the Hypertext Transfer Protocol version 1.1. When authorization succeeds, the Server may optionally provide the following: HTTP/1.1 200 OK Digest-MessageDigest: message="<message-digest>", nextnonce="<nextnonce>" The Digest-MessageDigest header indicates that the server wants to communicate some information regarding the successful authentication (such as a message digest or a new nonce to be used for the next transaction). <message-digest> is computed by the same algorithm given above for the body of the client request. This allows the client to verify that the body 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. <nextnonce> is the nonce the server wishes the client to use for the next authentication response. Either field is optional. In particular the server may send the Digest-MessageDigest header with only the nextnonce=<nextnonce> field as a means of implementing one-time nonces. If the nextnonce field is present the client is strongly encouraged to use it for the next WWW-Authenticate header. Failure of the client to do so may result in a request to re-authenticate from the server with the "stale=TRUE." The Digest-MessageDigest header has many limitations. Only the entity body is digested, not any headers. This limitation is due to the fact that proxy caches may (and do) alter the headers of documents which they relay. Future authentication schemes will have to deal with the complexities imposed by the behavior of intermediaries handling documents on their way from the origin server to the client, but those issues are beyond the scope of digest authentication, whose purpose is to replace Basic Authentication. Despite its limitations the Digest-MessageDigest can be useful. 2.2 Digest Operation 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>. Note that the HTTP server does not actually need to know the user's clear text password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified. 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 stale=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 Digest access authentication scheme. That is, they must forward the WWW-Authenticate, Digest-MessageDigest 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.3 Security Protocol Negotiation It is useful for a server to be able to know which security schemes a client is capable of handling. If this proposal is accepted as a required part of the HTTP/1.1 specification, then a server may assume Digest support when a client identifies itself as HTTP/1.1 compliant. It is possible that a server may want to require Digest 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 authentication scheme it cannot handle. 2.4 Example The following example assumes that an access-protected document is being requested from the server. The URI of the document is "http://www.nowhere.org/dir/index.html". 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: Digest realm="testrealm@host.com", nonce="72540723369", opaque="5ccc069c403ebaf9f0171e9517f40e41" 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: Digest username="Mufasa", realm="testrealm@host.com", nonce="72540723369", uri="/dir/index.html", response="e966c932a9242554e42c8ee200cec7f6", opaque="5ccc069c403ebaf9f0171e9517f40e41" 3. Security Considerations Digest Authentication does not provide provide a strong authentication mechanism. That is not its intent. It is intended solely to replace a much weaker and even dangerous authentication mechanism: Basic Authentication. An important design constraint is that the new authentication scheme be free of patent and export restrictions. Most needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs SSL or SHTTP are more appropriate protocols. In particular digest authentication cannot be used for any transaction requiring encrypted content. Nevertheless many functions remain for which digest authentication is both useful and appropriate. 3.1 Comparison with Basic Authentication Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum. But a comparison between the two points out the utility, even necessity, of replacing Basic by Digest. The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a database whose use is restricted to paying subscribers. With Basic authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the data base, but often worse, will permit access to anything else the user protects with the same password. By contrast, with Digest Authentication the eavesdropper only gets access to the transaction in question and not to the user's password. The information gained by the eavesdropper would permit a replay attack, but only with a request for the same document and even that might be difficult. 3.2 Replay Attacks A replay attack against digest authentication would usually be pointless for a simple GET request since an eavesdropper would already have seen the only document he could obtain with a replay. This is because the URI of the requested document is digested in the client response and the server will only deliver that document. By contrast under Basic Authentication once the eavesdropper has the user's password any document protected by that password is open to him. A GET request containing form data could only be "replayed" with the identical data. However, this could be problematic if it caused a CGI script to take some action on the server. Thus, for some purposes, it is necessary to protect against replay attacks. A good digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a timestamp, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the timestamp expires. Digesting the client IP and timestamp in the nonce permits an implementation which does not maintain state between transactions. For applications where no possibility of replay attack can be tolerated the server can use one-time response digests which will not be honored for a second use. This requires the overhead of the server remembering which digests have been used until the nonce timestamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks. Instead of maintaining a list of the values of used digests, a server would hash these values and require re-authentication whenever a hash collision occurs. An implementation must give special attention to the possibility of replay attacks with POST and PUT requests. A successful replay attack could result in counterfeit form data or a counterfeit version of a PUT file. The use of one-time digests or one-time nonces is recommended. It is also recommended that the optional <message-digest> be implemented for use with POST or PUT requests to assure the integrity of the posted data. Alternatively, a server may choose to allow digest authentication only with GET requests. Responsible server implementors will document the risks described here as they pertain to a given implementation. 3.3 Man in the Middle Both Basic and Digest authentication are vulnerable to "man in the middle" attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But it could also offer some additional threats. In particular, even with digest authentication, a hostile proxy might spoof the client into making a request the attacker wanted rather than one the client wanted. Of course, this is still much harder than a comparable attack against Basic Authentication. 3.4 Spoofing by Counterfeit Servers Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a host containing information protected by a password she knows when in fact she is connecting to a hostile server then the hostile server can request a password, store it away for later use, and feign an error. This type of attack is not possible with Digest Authentication. 3.5 Summary By modern cryptographic standards Digest Authentication is weak. But for a large range of purposes it is valuable as a replacement for Basic Authentication. It remedies many, but not all, weaknesses of Basic Authentication. Its strength may vary depending on the implementation. In particular the structure of the nonce (which is dependent on the server implementation) may affect the ease of mounting a replay attack. A range of server options is appropriate since, for example, some implementations may be willing to accept the server overhead of one-time nonces or digests to eliminate the possibility of replay while others may satisfied with a nonce like the one recommended above restricted to a single IP address and with a limited lifetime. The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication. 4. Acknowledgments In addition to the authors, valuable discussion instrumental in creating this document have come from Peter J Churchyard, Ned Freed, and David Kristol. 5. 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-ietf-http-v10-spec-00.txt>, March 1995. [2] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm", <URL:http://ds.internic.net/rfc/rfc1321.txt>, April 1992. 6. Authors Addresses John Franks john@math.nwu.edu Professor of Mathematics Department of Mathematics Northwestern University Evanston, IL 60208-2730, USA Phillip M. Hallam-Baker hallam@w3.org European Union Fellow CERN Geneva Switzerland Jeffery L. Hostetler jeff@spyglass.com Senior Software Engineer Spyglass, Inc. 3200 Farber Drive Champaign, IL 61821, USA Paul J. Leach paulle@microsoft.com Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA Ari Luotonen luotonen@netscape.com Member of Technical Staff Netscape Communications Corporation 501 East Middlefield Road Mountain View, CA 94043, USA Eric W. Sink eric@spyglass.com Senior Software Engineer Spyglass, Inc. 3200 Farber Drive Champaign, IL 61821, USA Lawrence C. Stewart stewart@OpenMarket.com Open Market, Inc. 215 First Street Cambridge, MA 02142, USA
Datatracker
Report a datatracker bug
draft-ietf-http-digest-aa-03
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2069.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |