draft-ietf-http-digest-aa-02.txt   draft-ietf-http-digest-aa-03.txt 
HTTP Working Group Jeffery L. Hostetler HTTP Working Group Jeffery L. Hostetler
INTERNET-DRAFT John Franks INTERNET-DRAFT John Franks
<draft-ietf-http-digest-aa-02.txt> Philip Hallam-Baker <draft-ietf-http-digest-aa-03.txt> Philip Hallam-Baker
Paul Leach
Ari Luotonen Ari Luotonen
Eric W. Sink Eric W. Sink
Lawrence C. Stewart Lawrence C. Stewart
Expires SIX MONTHS FROM---> December 20, 1995
Expires SIX MONTHS FROM---> March 1, 1996
A Proposed Extension to HTTP : Digest Access Authentication A Proposed Extension to HTTP : Digest Access Authentication
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 36 skipping to change at line 38
the "1id-abstracts.txt" listing contained in the Internet- the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net (US East Coast), Drafts Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim). munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited. Please send comments Distribution of this document is unlimited. Please send comments
to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>. to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
Discussions of the working group are archived at Discussions of the working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
about HTTP and the applications which use HTTP should take place about HTTP and the applications which use HTTP should take place
on the <www-talk@info.cern.ch> mailing list. on the <www-talk@www10.w3.org> mailing list.
Abstract Abstract
The protocol referred to as "HTTP/1.0" includes specification The protocol referred to as "HTTP/1.0" includes specification
for a Basic Access Authentication scheme. This scheme is not for a Basic Access Authentication scheme. This scheme is not
considered to be a secure method of user authentication, as the considered to be a secure method of user authentication, as the
user name and password are passed over the network in an user name and password are passed over the network in an
unencrypted form. A specification for a new authentication scheme unencrypted form. A specification for a new authentication scheme
is needed for future versions of the HTTP protocol. This document is needed for future versions of the HTTP protocol. This document
provides specification for such a scheme, referred to as "Digest provides specification for such a scheme, referred to as "Digest
Access Authentication". The encryption method used is the RSA Data Access Authentication". The encryption method used by default is the
Security, Inc. MD5 Message-Digest Algorithm [3]. RSA Data Security, Inc. MD5 Message-Digest Algorithm [2].
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 Purpose 1.1 Purpose
1.2 Overall Operation 1.2 Overall Operation
1.3 Representation of MD5 digest values 1.3 Representation of MD5 digest values
2. Basic Access Authentication Scheme 2. Basic Access Authentication Scheme
2.1 Specification 2.1 Specification of Digest Headers
2.2 Security protocol negotiation 2.2 Digest Operation
2.3 Example 2.3 Security protocol negotiation
3. Acknowledgments 2.4 Example
4. References 3. Security Considerations
5. Authors Addresses 4. Acknowledgments
5. References
6. Authors Addresses
1. Introduction 1. Introduction
1.1 Purpose 1.1 Purpose
The protocol referred to as "HTTP/1.0" includes specification The protocol referred to as "HTTP/1.0" includes specification
for a Basic Access Authentication scheme[1]. This scheme is not for a Basic Access Authentication scheme[1]. This scheme is not
considered to be a secure method of user authentication, as the considered to be a secure method of user authentication, as the
user name and password are passed over the network in an user name and password are passed over the network in an
unencrypted form. A specification for a new authentication scheme unencrypted form. A specification for a new authentication scheme
skipping to change at line 87 skipping to change at line 91
The Digest Access Authentication scheme is not intended to be The Digest Access Authentication scheme is not intended to be
a complete answer to the need for security in the World Wide Web. a complete answer to the need for security in the World Wide Web.
This scheme provides no encryption of object content. The intent This scheme provides no encryption of object content. The intent
is simply to facilitate secure access authentication. is simply to facilitate secure access authentication.
It is proposed that this access authentication scheme be included It is proposed that this access authentication scheme be included
in the proposed HTTP/1.1 specification. in the proposed HTTP/1.1 specification.
1.2 Overall Operation 1.2 Overall Operation
Like Basic Access Authentication, the Digest scheme is based on Like Basic Access Authentication, the Digest scheme is based on a
a simple challenge-response paradigm. The Digest scheme challenges simple challenge-response paradigm. The Digest scheme challenges
using a nonce value. A valid response contains the MD5 checksum of using a nonce value. A valid response contains a checksum (by default
the password and the given nonce value. In this way, the password the MD5 checksum) of the username, the password, the given nonce
is never sent in the clear. Just as with the Basic scheme, the value, and the requested URI. In this way, the password is never sent
username and password must be prearranged in some fashion. 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 MD5 digest values 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 For the purposes of this document, an MD5 digest of 128 bits
is represented as 32 ASCII printable characters. The bits is represented as 32 ASCII printable characters. The bits
in the 128 bit digest are converted from most significant in the 128 bit digest are converted from most significant
to least significant bit, four bits at a time to their to least significant bit, four bits at a time to their
ASCII presentation as follows. Each four bits is ASCII presentation as follows. Each four bits is
represented by its familiar hexadecimal notation from the represented by its familiar hexadecimal notation from the
characters 0123456789abcdef. That is binary 0000 gets characters 0123456789abcdef. That is binary 0000 gets
represented by the character '0', 0001, by '1', and so on represented by the character '0', 0001, by '1', and so on
up to the representation of 1111 as 'f'. 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. Digest Access Authentication Scheme
2.1 Specification 2.1 Specification of Digest Headers
The Digest Access Authentication scheme is conceptually similar to the Basic The Digest Access Authentication scheme is conceptually similar to the Basic
scheme. The formats of the modified WWW-Authenticate header line and the scheme. The formats of the modified WWW-Authenticate header line and the
Authorization header line are specified below. In addition, a new header, Authorization header line are specified below. In addition, a new header,
Digest-MessageDigest, is specified as well. Digest-MessageDigest, is specified as well.
Due to formatting constraints, all of the headers are depicted here Due to formatting constraints, all of the headers are depicted here
on multiple lines. In actual usage, they must follow the syntactic on multiple lines. In actual usage, they must follow the syntactic
rules for HTTP/1.0 header lines [1]. Whitespace between the rules for HTTP/1.0 header lines [1]. Whitespace between the
attribute-value pairs is allowed. attribute-value pairs is allowed.
If a server receives a request for an access-protected object, and an If a server receives a request for an access-protected object, and an
acceptable Authorizatation header is not sent, the server responds with: acceptable Authorization header is not sent, the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="<realm>", WWW-Authenticate: Digest realm="<realm>",
domain="<domain>", domain="<domain>",
nonce="<nonce>", nonce="<nonce>",
opaque="<opaque>", opaque="<opaque>",
stale="<TRUE | FALSE>" stale="<TRUE | FALSE>",
algorithm="<digest-algorithm>"
The meanings of the identifers used above are as follows: The meanings of the identifiers used above are as follows:
<realm> <realm>
A name given to users so they know which username and password A string to be displayed to users so they know which
to send. 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 <domain> OPTIONAL
A comma separated list of URIs, as specified for HTTP/1.0. The 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 intent is that the client could use this information to know the
set of URIs for which the same authentication information should be set of URIs for which the same authentication information should be
sent. The URIs in this list may exist on different servers. If sent. The URIs in this list may exist on different servers. If
this keyword is omitted or empty, the client should assume that this keyword is omitted or empty, the client should assume that
the domain consists of all URIs on the responding server. the domain consists of all URIs on the responding server.
<nonce> <nonce>
A server-specified integer value which may be uniquely generated each A server-specified data string which may be uniquely generated each
time a 401 response is made. Servers may defend themselves against time a 401 response is made. It is recommended that this string be
replay attacks by refusing to reuse nonce values. The nonce should be base64 or hexadecimal data. Specifically, since the string is passed
considered opqaue by the client. 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 <opaque> OPTIONAL
A string of data, specified by the server, which should returned by A string of data, specified by the server, which should returned by
the client unchanged. It is recommended that this string be the client unchanged. It is recommended that this string be
base64 or hexadecimal data. Specifically, since the string is passed base64 or hexadecimal data. Specifically, since the string is passed
in the header lines as a quoted string, the double-quote character in the header lines as a quoted string, the double-quote character
is not allowed. is not allowed.
<stale> OPTIONAL <stale> OPTIONAL
A flag, indicating that the previous request from the client A flag, indicating that the previous request from the client
was rejected because the nonce value was stale. If stale was rejected because the nonce value was stale. If stale
is TRUE, the client may wish to simply retry the request with is TRUE, the client may wish to simply retry the request with
a new encrypted response, without reprompting the user for a a new encrypted response, without reprompting the user for a
new username and password. 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 The client is expected to retry the request, passing an Authorization header
line as follows: line as follows:
Authorization: Digest Authorization: Digest
username="<username>", -- required username="<username>", -- required
realm="<realm>", -- required realm="<realm>", -- required
nonce="<nonce>", -- required nonce="<nonce>", -- required
uri="<requested-uri>", -- required uri="<requested-uri>", -- required
response="<digest>", -- required response="<digest>", -- required
message="<message-digest>", -- OPTIONAL message="<message-digest>", -- OPTIONAL
opaque="<opaque>" -- required if provided by server algorithm="<digest-algorithm>" -- OPTIONAL
opaque="<opaque>", -- required if provided
by server
where <digest> := H( H(A1) + ":" + N + ":" + H(A2) ) where <digest> := H( H(A1) + ":" + N + ":" + H(A2) )
and <message-digest> := H( H(A1) + ":" + N + ":" + H(<message-body>) ) and <message-digest> := H( H(A1) + ":" + N + ":" + H(<entity-body>) )
where: where:
A1 := U + ':' + R + ':' + P A1 := U + ':' + R + ':' + P
A2 := <Method> + ':' + <requested-uri> A2 := <Method> + ':' + <requested-uri>
with: with:
N -- nonce value N -- nonce value
U -- username U -- username
R -- realm R -- realm
P -- password P -- password
<Method> -- from header line 0
<requested-uri> -- uri sans proxy/routing <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 When authorization succeeds, the Server may optionally provide the
following: following:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Digest-MessageDigest: Digest-MessageDigest:
username="<username>", message="<message-digest>",
realm="<realm>", nextnonce="<nextnonce>"
nonce="<nonce>",
message="<message-digest>"
The Digest-MessageDigest header indicates that the server wants to The Digest-MessageDigest header indicates that the server
communicate some info regarding the successful wants to communicate some information regarding the
authentication (such as a message digest or a successful authentication (such as a message digest or a
receipt of some kind). new nonce to be used for the next transaction).
<message-digest> is computed as given above for <message-digest> is computed by the same algorithm given
the client. this allows the client to verify that above for the body of the client request. This allows the
the message body has not been changed en-route. 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.
(The server would probably only send this when it <nextnonce> is the nonce the server wishes the client to use for
has the document and can compute it (like the the next authentication response. Either field is optional. In
content-length field); the server would probably particular the server may send the Digest-MessageDigest header
not bother generating this header for CGI output.) 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."
Upon receiving the Authorization information, the server may check its The Digest-MessageDigest header has many limitations. Only the
validity by looking up its known password which corresponds to the submitted entity body is digested, not any headers. This limitation is due
<username>. Then, the server must perform the same MD5 operation performed to the fact that proxy caches may (and do) alter the headers of
by the client, and compare the result to the given <response>. 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 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 clear text password. As long as H(A1) is available to the server, the
validity of an Authorization header may be verified. validity of an Authorization header may be verified.
All keyword-value pairs must be expressed in characters from the All keyword-value pairs must be expressed in characters from the
US-ASCII character set, excluding control characters. US-ASCII character set, excluding control characters.
A client may remember the username, password and nonce values, so that A client may remember the username, password and nonce values, so that
future requests within the specified <domain> may include the Authorization future requests within the specified <domain> may include the Authorization
skipping to change at line 255 skipping to change at line 361
and pass the same Authorization line, including the <opaque> data which and pass the same Authorization line, including the <opaque> data which
the second server may require. the second server may require.
As with the basic scheme, proxies must be completely transparent in As with the basic scheme, proxies must be completely transparent in
the Digest access authentication scheme. That is, they must forward the the Digest access authentication scheme. That is, they must forward the
WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched. WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched.
If a proxy wants to authenticate a client before a request is forwarded to 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 the server, it can be done using the Proxy-Authenticate and
Proxy-Authorization headers. Proxy-Authorization headers.
2.2 Security Protocol Negotiation 2.3 Security Protocol Negotiation
It is useful for a server to be able to know which security schemes 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 a client is capable of handling.
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 Digest authentication.
Extension: Security/Digest
If this proposal is accepted as a required part of the HTTP/1.1 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 specification, then a server may assume Digest support when a client
identifies itself as HTTP/1.1 compliant. identifies itself as HTTP/1.1 compliant.
It is possible that a server may want to require Digest as its 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 authentication method, even if the server does not know that the client
supports it. A client is encouraged to fail gracefully if the server supports it. A client is encouraged to fail gracefully if the server
specifies any authentication scheme it cannot handle. specifies any authentication scheme it cannot handle.
2.3 Example 2.4 Example
The following example assumes that an access-protected document is being The following example assumes that an access-protected document is being
requested from the server. The URI of the document is requested from the server. The URI of the document is
"http://www.nowhere.org/simp/". "http://www.nowhere.org/dir/index.html".
Both client and server know that the username for this document is "eric", Both client and server know that the username for this document is
and the password is "spyglass". "Mufasa", and the password is "CircleOfLife".
The first time the client requests the document, no Authorization header The first time the client requests the document, no Authorization header
is sent, so the server responds with: is sent, so the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="testrealm", WWW-Authenticate: Digest realm="testrealm@host.com",
nonce="72540723369", nonce="72540723369",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
The client may prompt the user for the username and password, after which it The client may prompt the user for the username and password, after which it
will respond with a new request, including the following Authorization will respond with a new request, including the following Authorization
header: header:
Authorization: Digest username="eric", Authorization: Digest username="Mufasa",
realm="testrealm", realm="testrealm@host.com",
nonce="72540723369", nonce="72540723369",
uri="/simp/", uri="/dir/index.html",
response="e966c932a9242554e42c8ee200cec7f6", response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
3. References 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. [1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
"Hypertext Transfer Protocol -- HTTP/1.0" "Hypertext Transfer Protocol -- HTTP/1.0"
Internet-Draft (work in progress), UC Irvine, Internet-Draft (work in progress), UC Irvine,
<URL:http://ds.internic.net/internet-drafts/ <URL:http://ds.internic.net/internet-drafts/
draft-ietf-http-v10-spec-00.txt>, March 1995. draft-ietf-http-v10-spec-00.txt>, March 1995.
[2] D. Kristol. "A Proposed Extension Mechanism for HTTP" [2] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm",
<URL:http://ds.internic.net/internet-drafts/
draft-kristol-http-extensions-00.txt>,
December 1994.
[3] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm",
<URL:http://ds.internic.net/rfc/rfc1321.txt>, <URL:http://ds.internic.net/rfc/rfc1321.txt>,
April 1992. April 1992.
4. Authors Addresses 6. Authors Addresses
John Franks John Franks
john@math.nwu.edu john@math.nwu.edu
Professor of Mathematics Professor of Mathematics
Department of Mathematics Department of Mathematics
Northwestern University Northwestern University
Evanston, IL 60208-2730, USA Evanston, IL 60208-2730, USA
Phillip M. Hallam-Baker Phillip M. Hallam-Baker
hallam@w3.org hallam@w3.org
skipping to change at line 342 skipping to change at line 566
Geneva Geneva
Switzerland Switzerland
Jeffery L. Hostetler Jeffery L. Hostetler
jeff@spyglass.com jeff@spyglass.com
Senior Software Engineer Senior Software Engineer
Spyglass, Inc. Spyglass, Inc.
3200 Farber Drive 3200 Farber Drive
Champaign, IL 61821, USA Champaign, IL 61821, USA
Paul J. Leach
paulle@microsoft.com
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
Ari Luotonen Ari Luotonen
luotonen@netscape.com luotonen@netscape.com
Member of Technical Staff Member of Technical Staff
Netscape Communications Corporation Netscape Communications Corporation
501 East Middlefield Road 501 East Middlefield Road
Mountain View, CA 94043, USA Mountain View, CA 94043, USA
Eric W. Sink Eric W. Sink
eric@spyglass.com eric@spyglass.com
Senior Software Engineer Senior Software Engineer
Spyglass, Inc. Spyglass, Inc.
3200 Farber Drive 3200 Farber Drive
Champaign, IL 61821, USA Champaign, IL 61821, USA
Lawrence C. Stewart Lawrence C. Stewart
stewart@OpenMarket.com stewart@OpenMarket.com
Open Market, Inc. Open Market, Inc.
215 First Street 215 First Street
Cambridge, MA 02142, USA Cambridge, MA 02142, USA
Eric W. Sink
eric@spyglass.com
 End of changes. 36 change blocks. 
75 lines changed or deleted 305 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/