You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/09 01:12:29 UTC
svn commit: r582995 [4/5] - in /labs/webarch/trunk/http/draft-fielding-http:
rfc2617.html rfc2617.xml
Added: labs/webarch/trunk/http/draft-fielding-http/rfc2617.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/rfc2617.xml?rev=582995&view=auto
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/rfc2617.xml (added)
+++ labs/webarch/trunk/http/draft-fielding-http/rfc2617.xml Mon Oct 8 16:12:27 2007
@@ -0,0 +1,2161 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+<?rfc toc="yes"?>
+<?rfc symrefs="no"?>
+<?rfc sortrefs="no"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc-ext allow-markup-in-artwork="yes"?>
+<?rfc-ext include-references-in-index="yes" ?>
+
+<!DOCTYPE rfc [
+ <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
+ <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
+ <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
+ <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
+ <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
+ <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
+ <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
+ <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
+ <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
+ <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
+]>
+<rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext'>
+ <front>
+ <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
+ <author initials="J." surname="Franks" fullname="John Franks">
+ <organization>Northwestern University, Department of Mathematics</organization>
+ <address>
+ <postal>
+ <street>Northwestern University</street>
+ <city>Evanston</city>
+ <region>IL</region>
+ <code>60208-2730</code>
+ <country>USA</country>
+ </postal>
+ <email>john@math.nwu.edu</email>
+ </address>
+ </author>
+ <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
+ <organization>Verisign Inc.</organization>
+ <address>
+ <postal>
+ <street>301 Edgewater Place</street>
+ <street>Suite 210</street>
+ <city>Wakefield</city>
+ <region>MA</region>
+ <code>01880</code>
+ <country>USA</country>
+ </postal>
+ <email>pbaker@verisign.com</email>
+ </address>
+ </author>
+ <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
+ <organization>AbiSource, Inc.</organization>
+ <address>
+ <postal>
+ <street>6 Dunlap Court</street>
+ <city>Savoy</city>
+ <region>IL</region>
+ <code>61874</code>
+ <country>USA</country>
+ </postal>
+ <email>jeff@AbiSource.com</email>
+ </address>
+ </author>
+ <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
+ <organization>Agranat Systems, Inc.</organization>
+ <address>
+ <postal>
+ <street>5 Clocktower Place</street>
+ <street>Suite 400</street>
+ <city>Maynard</city>
+ <region>MA</region>
+ <code>01754</code>
+ <country>USA</country>
+ </postal>
+ <email>lawrence@agranat.com</email>
+ </address>
+ </author>
+ <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
+ <organization>Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+ <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
+ <organization>Netscape Communications Corporation</organization>
+ <address>
+ <postal>
+ <street>501 East Middlefield Road</street>
+ <city>Mountain View</city>
+ <region>CA</region>
+ <code>94043</code>
+ <country>USA</country>
+ </postal>
+ </address>
+ </author>
+ <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
+ <organization>Open Market, Inc.</organization>
+ <address>
+ <postal>
+ <street>215 First Street</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02142</code>
+ <country>USA</country>
+ </postal>
+ <email>stewart@OpenMarket.com</email>
+ </address>
+ </author>
+ <date month="June" year="1999"/>
+
+ <abstract>
+ <t>
+ "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 (unless used in conjunction with some
+ external secure system such as SSL <xref target="RFC2246"/>), as the user name and
+ password are passed over the network as cleartext.
+ </t><t>
+ This document also provides the specification for HTTP's
+ authentication framework, the original Basic authentication scheme
+ and a scheme based on cryptographic hashes, referred to as "Digest
+ Access Authentication". It is therefore also intended to serve as a
+ replacement for RFC 2069 <xref target="RFC2069"/>. Some optional elements specified by
+ RFC 2069 have been removed from this specification due to problems
+ found since its publication; other new elements have been added for
+ compatibility, those new elements have been made optional, but are
+ strongly recommended.
+ </t><t>
+ 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.
+ </t>
+ </abstract>
+ </front>
+ <middle>
+
+<section title="Access Authentication">
+
+<section title="Reliance on the HTTP/1.1 Specification">
+<t>
+ This specification is a companion to the HTTP/1.1 specification <xref target="RFC2616"/>.
+ It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x:sec="2.1"/> of that document, and relies on
+ both the non-terminals defined in that document and other aspects of
+ the HTTP/1.1 specification.
+</t>
+</section>
+
+<section title="Access Authentication Framework" anchor="access.authentication.framework">
+<t>
+ HTTP provides a simple challenge-response authentication mechanism
+ that &MAY; be used by a server to challenge a client request and by a
+ client to provide authentication information. It uses an extensible,
+ case-insensitive token to identify the authentication scheme,
+ followed by a comma-separated list of attribute-value pairs which
+ carry the parameters necessary for achieving authentication via that
+ scheme.
+</t>
+<figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"
+/> auth-scheme = token
+<iref item="auth-param" primary="true"
+/> auth-param = token "=" ( token | quoted-string )
+</artwork></figure>
+<t>
+ The 401 (Unauthorized) response message is used by an origin server
+ to challenge the authorization of a user agent. This response &MUST;
+ include a WWW-Authenticate header field containing at least one
+ challenge applicable to the requested resource. The 407 (Proxy
+ Authentication Required) response message is used by a proxy to
+ challenge the authorization of a client and &MUST; include a Proxy-Authenticate
+ header field containing at least one challenge
+ applicable to the proxy for the requested resource.
+</t>
+<figure><artwork type="abnf2616"><iref item="challenge" primary="true"
+/> challenge = auth-scheme 1*SP 1#auth-param
+</artwork></figure>
+<t>
+ Note: User agents will need to take special care in parsing the WWW-Authenticate
+ or Proxy-Authenticate header field value if it contains
+ more than one challenge, or if more than one WWW-Authenticate header
+ field is provided, since the contents of a challenge may itself
+ contain a comma-separated list of authentication parameters.
+</t>
+<t>
+ The authentication parameter realm is defined for all authentication
+ schemes:
+</t>
+<figure><artwork type="abnf2616"><iref item="realm" primary="true"
+/> realm = "realm" "=" realm-value
+<iref item="realm-value" primary="true"
+/> realm-value = quoted-string
+</artwork></figure>
+<t>
+ The realm directive (case-insensitive) is required for all
+ authentication schemes that issue a challenge. The realm value
+ (case-sensitive), in combination with the canonical root URL (the
+ absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/>
+ of <xref target="RFC2616"/>) of the server being accessed, defines the protection space.
+ These realms allow the protected resources on a server to be
+ partitioned into a set of protection spaces, each with its own
+ authentication scheme and/or authorization database. The realm value
+ is a string, generally assigned by the origin server, which may have
+ additional semantics specific to the authentication scheme. Note that
+ there may be multiple challenges with the same auth-scheme but
+ different realms.
+</t>
+<t>
+ A user agent that wishes to authenticate itself with an origin
+ server--usually, but not necessarily, after receiving a 401
+ (Unauthorized)--MAY do so by including an Authorization header field
+ with the request. A client that wishes to authenticate itself with a
+ proxy--usually, but not necessarily, after receiving a 407 (Proxy
+ Authentication Required)--MAY do so by including a Proxy-Authorization
+ header field with the request. Both the Authorization
+ field value and the Proxy-Authorization field value consist of
+ credentials containing the authentication information of the client
+ for the realm of the resource being requested. The user agent &MUST;
+ choose to use one of the challenges with the strongest auth-scheme it
+ understands and request credentials from the user based upon that
+ challenge.
+</t>
+<figure><artwork type="abnf2616"><iref item="credentials" primary="true"
+/> credentials = auth-scheme #auth-param
+</artwork></figure>
+<t>
+ <list><t>
+ Note that many browsers will only recognize Basic and will require
+ that it be the first auth-scheme presented. Servers should only
+ include Basic if it is minimally acceptable.
+ </t></list>
+</t>
+<t>
+ The protection space determines the domain over which credentials can
+ be automatically applied. If a prior request has been authorized, the
+ same credentials &MAY; be reused for all other requests within that
+ protection space for a period of time determined by the
+ authentication scheme, parameters, and/or user preference. Unless
+ otherwise defined by the authentication scheme, a single protection
+ space cannot extend outside the scope of its server.
+</t>
+<t>
+ If the origin server does not wish to accept the credentials sent
+ with a request, it &SHOULD; return a 401 (Unauthorized) response. The
+ response &MUST; include a WWW-Authenticate header field containing at
+ least one (possibly new) challenge applicable to the requested
+ resource. If a proxy does not accept the credentials sent with a
+ request, it &SHOULD; return a 407 (Proxy Authentication Required). The
+ response &MUST; include a Proxy-Authenticate header field containing a
+ (possibly new) challenge applicable to the proxy for the requested
+ resource.
+</t>
+<t>
+ The HTTP protocol does not restrict applications to this simple
+ challenge-response mechanism for access authentication. Additional
+ mechanisms &MAY; be used, such as encryption at the transport level or
+ via message encapsulation, and with additional header fields
+ specifying authentication information. However, these additional
+ mechanisms are not defined by this specification.
+</t>
+<t>
+ Proxies &MUST; be completely transparent regarding user agent
+ authentication by origin servers. That is, they must forward the
+ WWW-Authenticate and Authorization headers untouched, and follow the
+ rules found in section <xref target="RFC2616" x:fmt="number" x:sec="14.8"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and
+ the Proxy-Authorization header fields are hop-by-hop headers (see
+ section <xref target="RFC2616" x:fmt="number" x:sec="13.5.1"/> of <xref target="RFC2616"/>).
+</t>
+</section>
+</section>
+
+<section title="Basic Authentication Scheme">
+<t>
+ The "basic" authentication scheme is based on the model that the
+ client must authenticate itself with a user-ID and a password for
+ each realm. The realm value should be considered an opaque string
+ which can only be compared for equality with other realms on that
+ server. The server will service the request only if it can validate
+ the user-ID and password for the protection space of the Request-URI.
+ There are no optional authentication parameters.
+</t>
+<t>
+ For Basic, the framework above is utilized as follows:
+</t>
+<figure><artwork type="abnf2616"><iref item="challenge"
+/> challenge = "Basic" realm
+<iref item="credentials"
+/> credentials = "Basic" basic-credentials
+</artwork></figure>
+<t>
+ Upon receipt of an unauthorized request for a URI within the
+ protection space, the origin server &MAY; respond with a challenge like
+ the following:
+</t>
+<figure><artwork type="example">
+ WWW-Authenticate: Basic realm="WallyWorld"
+</artwork></figure>
+<t>
+ where "WallyWorld" is the string assigned by the server to identify
+ the protection space of the Request-URI. A proxy may respond with the
+ same challenge using the Proxy-Authenticate header field.
+</t>
+<t>
+ To receive authorization, the client sends the userid and password,
+ separated by a single colon (":") character, within a base64 <xref target="RFC2396"/>
+ encoded string in the credentials.
+</t>
+<figure><artwork type="abnf2616"><iref item="basic-credentials" primary="true"
+/> basic-credentials = base64-user-pass
+<iref item="base64-user-pass" primary="true"
+/> base64-user-pass = <base64 [4] encoding of user-pass,
+ except not limited to 76 char/line>
+<iref item="user-pass" primary="true"
+/> user-pass = userid ":" password
+<iref item="userid" primary="true"
+/> userid = *<TEXT excluding ":">
+<iref item="password" primary="true"
+/> password = *TEXT
+</artwork></figure>
+<t>
+ Userids might be case sensitive.
+</t>
+<t>
+ If the user agent wishes to send the userid "Aladdin" and password
+ "open sesame", it would use the following header field:
+</t>
+<figure><artwork type="example">
+ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+</artwork></figure>
+<t>
+ A client &SHOULD; assume that all paths at or deeper than the depth of
+ the last symbolic element in the path field of the Request-URI also
+ are within the protection space specified by the Basic realm value of
+ the current challenge. A client &MAY; preemptively send the
+ corresponding Authorization header with requests for resources in
+ that space without receipt of another challenge from the server.
+ Similarly, when a client sends a request to a proxy, it may reuse a
+ userid and password in the Proxy-Authorization header field without
+ receiving another challenge from the proxy server. See <xref target="security.considerations"/> for
+ security considerations associated with Basic authentication.
+</t>
+</section>
+
+<section title="Digest Access Authentication Scheme">
+
+<section title="Introduction">
+
+<section title="Purpose">
+<t>
+ The protocol referred to as "HTTP/1.0" includes the specification for
+ a Basic Access Authentication scheme<xref target="RFC1945"/>. That 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.
+ This section provides the specification for a scheme that does not
+ send the password in cleartext, referred to as "Digest Access
+ Authentication".
+</t>
+<t>
+ 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 message content. The intent is
+ simply to create an access authentication method that avoids the most
+ serious flaws of Basic authentication.
+</t>
+</section>
+
+<section title="Overall Operation">
+<t>
+ 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, the HTTP method, 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 not
+ addressed by this document.
+</t>
+</section>
+
+<section title="Representation of digest values">
+<t>
+ 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.
+</t>
+<t>
+ 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'.
+</t>
+</section>
+
+<section title="Limitations">
+<t>
+ 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 to
+ establish the user's password.
+</t>
+<t>
+ 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.
+</t>
+</section>
+</section>
+
+<section title="Specification of Digest Headers" anchor="specification.of.digest.headers">
+<t>
+ 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, Authentication-Info, is specified.
+</t>
+
+<section title="The WWW-Authenticate Response Header" anchor="the.www-authenticate.response.header">
+<iref item="Headers" subitem="WWW-Authenticate" primary="true"/>
+<iref item="WWW-Authenticate header" primary="true"/>
+<t>
+ If a server receives a request for an access-protected object, and an
+ acceptable Authorization header is not sent, the server responds with
+ a "401 Unauthorized" status code, and a WWW-Authenticate header as
+ per the framework defined above, which for the digest scheme is
+ utilized as follows:
+</t>
+<figure><artwork type="abnf2616">
+<iref item="challenge"
+/> challenge = "Digest" digest-challenge
+
+<iref item="digest-challenge" primary="true"
+/> digest-challenge = 1#( realm | [ domain ] | nonce |
+ [ opaque ] |[ stale ] | [ algorithm ] |
+ [ qop-options ] | [auth-param] )
+
+
+<iref item="domain" primary="true"
+/> domain = "domain" "=" <"> URI ( 1*SP URI ) <">
+<iref item="URI" primary="true"
+/> URI = absoluteURI | abs_path
+<iref item="nonce" primary="true"
+/> nonce = "nonce" "=" nonce-value
+<iref item="nonce-value" primary="true"
+/> nonce-value = quoted-string
+<iref item="opaque" primary="true"
+/> opaque = "opaque" "=" quoted-string
+<iref item="stale" primary="true"
+/> stale = "stale" "=" ( "true" | "false" )
+<iref item="algorithm" primary="true"
+/> algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" |
+ token )
+<iref item="qop-options" primary="true"
+/> qop-options = "qop" "=" <"> 1#qop-value <">
+<iref item="qop-value" primary="true"
+/> qop-value = "auth" | "auth-int" | token
+</artwork></figure>
+<t>
+ The meanings of the values of the directives used above are as
+ follows:
+</t>
+<t>
+ realm
+ <list><t>
+ 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".
+ </t></list>
+</t>
+<t>
+ domain
+ <list><t>
+ A quoted, space-separated list of URIs, as specified in RFC XURI
+ <xref target="RFC2396"/>, that define the protection space. If a URI is an abs_path, it
+ is relative to the canonical root URL (see <xref target="access.authentication.framework"/> above) of
+ the server being accessed. An absoluteURI in this list may refer to
+ a different server than the one being accessed. The client can use
+ this list to determine the set of URIs for which the same
+ authentication information may be sent: any URI that has a URI in
+ this list as a prefix (after both have been made absolute) may be
+ assumed to be in the same protection space. If this directive is
+ omitted or its value is empty, the client should assume that the
+ protection space consists of all URIs on the responding server.
+ This directive is not meaningful in Proxy-Authenticate headers, for
+ which the protection space is always the entire proxy; if present
+ it should be ignored.
+ </t></list>
+</t>
+<t>
+ nonce
+ <list><t>
+ A server-specified data string which should 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.
+ </t>
+ <t>
+ The contents of the nonce are implementation dependent. The quality
+ of the implementation depends on a good choice. A nonce might, for
+ example, be constructed as the base 64 encoding of
+ </t>
+ <t><figure><artwork type="code">
+ time-stamp H(time-stamp ":" ETag ":" private-key)
+ </artwork></figure></t>
+ <t>
+ where time-stamp is a server-generated time or other non-repeating
+ value, ETag is the value of the HTTP ETag header associated with
+ the requested entity, and private-key is data known only to the
+ server. With a nonce of this form a server would recalculate the
+ hash portion after receiving the client authentication header and
+ reject the request if it did not match the nonce from that header
+ or if the time-stamp value is not recent enough. In this way the
+ server can limit the time of the nonce's validity. The inclusion of
+ the ETag prevents a replay request for an updated version of the
+ resource. (Note: including the IP address of the client in the
+ nonce would appear to offer the server the ability to limit the
+ reuse of the nonce to the same client that originally got it.
+ However, that would break proxy farms, where requests from a single
+ user often go through different proxies in the farm. Also, IP
+ address spoofing is not that hard.)
+ </t>
+ <t>
+ An implementation might choose not to accept a previously used
+ nonce or a previously used digest, in order 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 time-stamp for GET
+ requests. For more details on the issues involved see <xref target="security.considerations"/>
+ of this document.
+ </t>
+ <t>
+ The nonce is opaque to the client.
+ </t></list></t>
+<t>
+ opaque
+ <list><t>
+ A string of data, specified by the server, which should be returned
+ by the client unchanged in the Authorization header of subsequent
+ requests with URIs in the same protection space. It is recommended
+ that this string be base64 or hexadecimal data.
+ </t></list>
+</t>
+<t>
+ stale
+ <list><t>
+ A flag, indicating that the previous request from the client was
+ rejected because the nonce value was stale. If stale is TRUE
+ (case-insensitive), 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 that the client knows the
+ correct username/password). If stale is FALSE, or anything other
+ than TRUE, or the stale directive is not present, the username
+ and/or password are invalid, and new values must be obtained.
+ </t></list>
+</t>
+<t>
+ algorithm
+ <list><t>
+ A string indicating a pair of algorithms used to produce the digest
+ and a checksum. If this is not present it is assumed to be "MD5".
+ If the algorithm is not understood, the challenge should be ignored
+ (and a different one used, if there is more than one).
+ </t>
+ <t>
+ In this document the string obtained by applying the digest
+ algorithm to the data "data" with secret "secret" will be denoted
+ by KD(secret, data), and the string obtained by applying the
+ checksum algorithm to the data "data" will be denoted H(data). The
+ notation unq(X) means the value of the quoted-string X without the
+ surrounding quotes.
+ </t>
+ <t>
+ For the "MD5" and "MD5-sess" algorithms
+ </t>
+ <t><figure><artwork type="code">
+ H(data) = MD5(data)
+ </artwork></figure></t>
+ <t>
+ and
+ </t>
+ <t><figure><artwork type="code">
+ KD(secret, data) = H(concat(secret, ":", data))
+ </artwork></figure></t>
+ <t>
+ i.e., the digest is the MD5 of the secret concatenated with a colon
+ concatenated with the data. The "MD5-sess" algorithm is intended to
+ allow efficient 3rd party authentication servers; for the
+ difference in usage, see the description in <xref target="A1"/>.
+ </t></list>
+</t>
+<t>
+ qop-options
+ <list><t>
+ This directive is optional, but is made so only for backward
+ compatibility with RFC 2069 <xref target="RFC2069"/>; it &SHOULD; be used by all
+ implementations compliant with this version of the Digest scheme.
+ If present, it is a quoted string of one or more tokens indicating
+ the "quality of protection" values supported by the server. The
+ value "auth" indicates authentication; the value "auth-int"
+ indicates authentication with integrity protection; see the
+ descriptions below for calculating the response directive value for
+ the application of this choice. Unrecognized options &MUST; be
+ ignored.
+ </t></list>
+</t>
+<t>
+ auth-param
+ <list><t>
+ This directive allows for future extensions. Any unrecognized
+ directive &MUST; be ignored.
+ </t></list>
+</t>
+</section>
+
+<section title="The Authorization Request Header" anchor="the.authorization.request.header">
+<iref item="Headers" subitem="Authorization" primary="true"/>
+<iref item="Authorization header" primary="true"/>
+<t>
+ The client is expected to retry the request, passing an Authorization
+ header line, which is defined according to the framework above,
+ utilized as follows.
+</t>
+<figure><artwork type="abnf2616">
+<iref item="credentials"
+/> credentials = "Digest" digest-response
+<iref item="digest-response" primary="true"
+/> digest-response = 1#( username | realm | nonce | digest-uri
+ | response | [ algorithm ] | [cnonce] |
+ [opaque] | [message-qop] |
+ [nonce-count] | [auth-param] )
+
+<iref item="username" primary="true"
+/> username = "username" "=" username-value
+<iref item="username-value" primary="true"
+/> username-value = quoted-string
+<iref item="digest-uri" primary="true"
+/> digest-uri = "uri" "=" digest-uri-value
+<iref item="digest-uri-value" primary="true"
+/> digest-uri-value = request-uri ; As specified by HTTP/1.1
+<iref item="message-qop" primary="true"
+/> message-qop = "qop" "=" qop-value
+<iref item="cnonce" primary="true"
+/> cnonce = "cnonce" "=" cnonce-value
+<iref item="cnonce-value" primary="true"
+/> cnonce-value = nonce-value
+<iref item="nonce-count" primary="true"
+/> nonce-count = "nc" "=" nc-value
+<iref item="nc-value" primary="true"
+/> nc-value = 8LHEX
+<iref item="response" primary="true"
+/> response = "response" "=" request-digest
+<iref item="request-digest" primary="true"
+/> request-digest = <"> 32LHEX <">
+<iref item="LHEX" primary="true"
+/> LHEX = "0" | "1" | "2" | "3" |
+ "4" | "5" | "6" | "7" |
+ "8" | "9" | "a" | "b" |
+ "c" | "d" | "e" | "f"
+</artwork></figure>
+<t>
+ The values of the opaque and algorithm fields must be those supplied
+ in the WWW-Authenticate response header for the entity being
+ requested.
+</t>
+<t>
+ response
+ <list><t>
+ A string of 32 hex digits computed as defined below, which proves
+ that the user knows a password
+ </t></list>
+</t>
+<t>
+ username
+ <list><t>
+ The user's name in the specified realm.
+ </t></list>
+</t>
+<t>
+ digest-uri
+ <list><t>
+ The URI from Request-URI of the Request-Line; duplicated here
+ because proxies are allowed to change the Request-Line in transit.
+ </t></list>
+</t>
+<t>
+ qop
+ <list><t>
+ Indicates what "quality of protection" the client has applied to
+ the message. If present, its value &MUST; be one of the alternatives
+ the server indicated it supports in the WWW-Authenticate header.
+ These values affect the computation of the request-digest. Note
+ that this is a single token, not a quoted list of alternatives as
+ in WWW-Authenticate. This directive is optional in order to
+ preserve backward compatibility with a minimal implementation of
+ RFC 2069 <xref target="RFC2069"/>, but &SHOULD; be used if the server indicated that qop
+ is supported by providing a qop directive in the WWW-Authenticate
+ header field.
+ </t></list>
+</t>
+<t>
+ cnonce
+ <list><t>
+ This &MUST; be specified if a qop directive is sent (see above), and
+ &MUST-NOT; be specified if the server did not send a qop directive in
+ the WWW-Authenticate header field. The cnonce-value is an opaque
+ quoted string value provided by the client and used by both client
+ and server to avoid chosen plaintext attacks, to provide mutual
+ authentication, and to provide some message integrity protection.
+ See the descriptions below of the calculation of the response-digest
+ and request-digest values.
+ </t></list>
+</t>
+<t>
+ nonce-count
+ <list><t>
+ This &MUST; be specified if a qop directive is sent (see above), and
+ &MUST-NOT; be specified if the server did not send a qop directive in
+ the WWW-Authenticate header field. The nc-value is the hexadecimal
+ count of the number of requests (including the current request)
+ that the client has sent with the nonce value in this request. For
+ example, in the first request sent in response to a given nonce
+ value, the client sends "nc=00000001". The purpose of this
+ directive is to allow the server to detect request replays by
+ maintaining its own copy of this count - if the same nc-value is
+ seen twice, then the request is a replay. See the description
+ below of the construction of the request-digest value.
+ </t></list>
+</t>
+<t>
+ auth-param
+ <list><t>
+ This directive allows for future extensions. Any unrecognized
+ directive &MUST; be ignored.
+ </t></list>
+</t>
+<t>
+ If a directive or its value is improper, or required directives are
+ missing, the proper response is 400 Bad Request. If the request-digest
+ is invalid, then a login failure should be logged, since
+ repeated login failures from a single client may indicate an attacker
+ attempting to guess passwords.
+</t>
+<t>
+ The definition of request-digest above indicates the encoding for its
+ value. The following definitions show how the value is computed.
+</t>
+
+<section title="Request-Digest" anchor="request-digest">
+<t>
+ If the "qop" value is "auth" or "auth-int":
+</t>
+<figure><artwork type="abnf2616">
+ request-digest = <"> < KD ( H(A1), unq(nonce-value)
+ ":" nc-value
+ ":" unq(cnonce-value)
+ ":" unq(qop-value)
+ ":" H(A2)
+ ) <">
+</artwork></figure>
+<t>
+ If the "qop" directive is not present (this construction is for
+ compatibility with RFC 2069):
+</t>
+<figure><artwork type="abnf2616">
+ request-digest =
+ <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
+ <">
+</artwork></figure>
+<t>
+ See below for the definitions for A1 and A2.
+</t>
+</section>
+
+<section title="A1" anchor="A1">
+<t>
+ If the "algorithm" directive's value is "MD5" or is unspecified, then
+ A1 is:
+</t>
+<figure><artwork type="abnf2616">
+ A1 = unq(username-value) ":" unq(realm-value) ":" passwd
+</artwork></figure>
+<t>
+ where
+</t>
+<figure><artwork type="abnf2616">
+ passwd = < user's password >
+</artwork></figure>
+<t>
+ If the "algorithm" directive's value is "MD5-sess", then A1 is
+ calculated only once - on the first request by the client following
+ receipt of a WWW-Authenticate challenge from the server. It uses the
+ server nonce from that challenge, and the first client nonce value to
+ construct A1 as follows:
+</t>
+<figure><artwork type="abnf2616">
+ A1 = H( unq(username-value) ":" unq(realm-value)
+ ":" passwd )
+ ":" unq(nonce-value) ":" unq(cnonce-value)
+</artwork></figure>
+<t>
+ This creates a 'session key' for the authentication of subsequent
+ requests and responses which is different for each "authentication
+ session", thus limiting the amount of material hashed with any one
+ key. (Note: see further discussion of the authentication session in
+ <xref target="digest.operation"/>) Because the server need only use the hash of the user
+ credentials in order to create the A1 value, this construction could
+ be used in conjunction with a third party authentication service so
+ that the web server would not need the actual password value. The
+ specification of such a protocol is beyond the scope of this
+ specification.
+</t>
+</section>
+
+<section title="A2">
+<t>
+ If the "qop" directive's value is "auth" or is unspecified, then A2
+ is:
+</t>
+<figure><artwork type="abnf2616">
+ A2 = Method ":" digest-uri-value
+</artwork></figure>
+<t>
+ If the "qop" value is "auth-int", then A2 is:
+</t>
+<figure><artwork type="abnf2616">
+ A2 = Method ":" digest-uri-value ":" H(entity-body)
+</artwork></figure>
+</section>
+
+
+<section title="Directive values and quoted-string">
+<t>
+ Note that the value of many of the directives, such as "username-value",
+ are defined as a "quoted-string". However, the "unq" notation
+ indicates that surrounding quotation marks are removed in forming the
+ string A1. Thus if the Authorization header includes the fields
+</t>
+<figure><artwork type="example">
+ username="Mufasa", realm=myhost@testrealm.com
+</artwork></figure>
+<t>
+ and the user Mufasa has password "Circle Of Life" then H(A1) would be
+ H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks
+ in the digested string.
+</t>
+<t>
+ No white space is allowed in any of the strings to which the digest
+ function H() is applied unless that white space exists in the quoted
+ strings or entity body whose contents make up the string to be
+ digested. For example, the string A1 illustrated above must be
+</t>
+<figure><artwork type="example">
+ Mufasa:myhost@testrealm.com:Circle Of Life
+</artwork></figure>
+<t>
+ with no white space on either side of the colons, but with the white
+ space between the words used in the password value. Likewise, the
+ other strings digested by H() must not have white space on either
+ side of the colons which delimit their fields unless that white space
+ was in the quoted strings or entity body being digested.
+</t>
+<t>
+ Also note that if integrity protection is applied (qop=auth-int), the
+ H(entity-body) is the hash of the entity body, not the message body -
+ it is computed before any transfer encoding is applied by the sender
+ and after it has been removed by the recipient. Note that this
+ includes multipart boundaries and embedded headers in each part of
+ any multipart content-type.
+</t>
+</section>
+
+<section title="Various considerations">
+<t>
+ The "Method" value is the HTTP request method as specified in section
+ <xref target="RFC2616" x:fmt="number" x:sec="5.1.1"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the
+ request line as specified in section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/> of <xref target="RFC2616"/>. This may be "*",
+ an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/> of
+ <xref target="RFC2616"/>, but it &MUST; agree with the Request-URI. In particular, it &MUST;
+ be an "absoluteURL" if the Request-URI is an "absoluteURL". The
+ "cnonce-value" is an optional client-chosen value whose purpose is
+ to foil chosen plaintext attacks.
+</t>
+<t>
+ The authenticating server must assure that the resource designated by
+ the "uri" directive is the same as the resource specified in the
+ Request-Line; if they are not, the server &SHOULD; return a 400 Bad
+ Request error. (Since this may be a symptom of an attack, server
+ implementers may want to consider logging such errors.) The purpose
+ of duplicating information from the request URL in this field is to
+ deal with the possibility that an intermediate proxy may alter the
+ client's Request-Line. This altered (but presumably semantically
+ equivalent) request would not result in the same digest as that
+ calculated by the client.
+</t>
+<t>
+ Implementers should be aware of how authenticated transactions
+ interact with shared caches. The HTTP/1.1 protocol specifies that
+ when a shared cache (see section <xref target="RFC2616" x:fmt="number" x:sec="13.7"/> of <xref target="RFC2616"/>) has received a request
+ containing an Authorization header and a response from relaying that
+ request, it &MUST-NOT; return that response as a reply to any other
+ request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x:sec="14.9"/> of <xref target="RFC2616"/>)
+ directives was present in the response. If the original response
+ included the "must-revalidate" Cache-Control directive, the cache &MAY;
+ use the entity of that response in replying to a subsequent request,
+ but &MUST; first revalidate it with the origin server, using the
+ request headers from the new request to allow the origin server to
+ authenticate the new request. Alternatively, if the original response
+ included the "public" Cache-Control directive, the response entity
+ &MAY; be returned in reply to any subsequent request.
+</t>
+</section>
+</section>
+
+<section title="The Authentication-Info Header">
+<iref item="Headers" subitem="Authentication-Info" primary="true"/>
+<iref item="Authentication-Info header" primary="true"/>
+<t>
+ The Authentication-Info header is used by the server to communicate
+ some information regarding the successful authentication in the
+ response.
+</t>
+<figure><artwork type="abnf2616"><iref item="Authentication-Info" primary="true"
+/> AuthenticationInfo = "Authentication-Info" ":" auth-info
+<iref item="auth-info" primary="true"
+/> auth-info = 1#(nextnonce | [ message-qop ]
+ | [ response-auth ] | [ cnonce ]
+ | [nonce-count] )
+<iref item="nextnonce" primary="true"
+/> nextnonce = "nextnonce" "=" nonce-value
+<iref item="response-auth" primary="true"
+/> response-auth = "rspauth" "=" response-digest
+<iref item="response-digest" primary="true"
+/> response-digest = <"> *LHEX <">
+</artwork></figure>
+<t>
+ The value of the nextnonce directive is the nonce the server wishes
+ the client to use for a future authentication response. The server
+ may send the Authentication-Info header with a nextnonce field as a
+ means of implementing one-time or otherwise changing nonces. If the
+ nextnonce field is present the client &SHOULD; use it when constructing
+ the Authorization header for its next request. Failure of the client
+ to do so may result in a request to re-authenticate from the server
+ with the "stale=TRUE".
+</t>
+<t>
+ <list><t>
+ Server implementations should carefully consider the performance
+ implications of the use of this mechanism; pipelined requests will
+ not be possible if every response includes a nextnonce directive
+ that must be used on the next request received by the server.
+ Consideration should be given to the performance vs. security
+ tradeoffs of allowing an old nonce value to be used for a limited
+ time to permit request pipelining. Use of the nonce-count can
+ retain most of the security advantages of a new server nonce
+ without the deleterious affects on pipelining.
+ </t></list>
+</t>
+<t>
+ message-qop
+</t>
+<t><list><t>
+ Indicates the "quality of protection" options applied to the
+ response by the server. The value "auth" indicates authentication;
+ the value "auth-int" indicates authentication with integrity
+ protection. The server &SHOULD; use the same value for the message-qop
+ directive in the response as was sent by the client in the
+ corresponding request.
+</t></list></t>
+<t>
+ The optional response digest in the "response-auth" directive
+ supports mutual authentication -- the server proves that it knows the
+ user's secret, and with qop=auth-int also provides limited integrity
+ protection of the response. The "response-digest" value is calculated
+ as for the "request-digest" in the Authorization header, except that
+ if "qop=auth" or is not specified in the Authorization header for the
+ request, A2 is
+</t>
+<figure><artwork type="abnf2616">
+ A2 = ":" digest-uri-value
+</artwork></figure>
+<t>
+ and if "qop=auth-int", then A2 is
+</t>
+<figure><artwork type="abnf2616">
+ A2 = ":" digest-uri-value ":" H(entity-body)
+</artwork></figure>
+<t>
+ where "digest-uri-value" is the value of the "uri" directive on the
+ Authorization header in the request. The "cnonce-value" and "nc-value"
+ &MUST; be the ones for the client request to which this message
+ is the response. The "response-auth", "cnonce", and "nonce-count"
+ directives &MUST; BE present if "qop=auth" or "qop=auth-int" is
+ specified.
+</t>
+<t>
+ The Authentication-Info header is allowed in the trailer of an HTTP
+ message transferred via chunked transfer-coding.
+</t>
+</section>
+</section>
+
+<section title="Digest Operation" anchor="digest.operation">
+<t>
+ Upon receiving the Authorization header, the server may check its
+ validity by looking up the password that corresponds to the submitted
+ username. Then, the server must perform the same digest operation
+ (e.g., MD5) performed by the client, and compare the result to the
+ given request-digest value.
+</t>
+<t>
+ Note that the HTTP server does not actually need to know the user's
+ cleartext password. As long as H(A1) is available to the server, the
+ validity of an Authorization header may be verified.
+</t>
+<t>
+ The client response to a WWW-Authenticate challenge for a protection
+ space starts an authentication session with that protection space.
+ The authentication session lasts until the client receives another
+ WWW-Authenticate challenge from any server in the protection space. A
+ client should remember the username, password, nonce, nonce count and
+ opaque values associated with an authentication session to use to
+ construct the Authorization header in future requests within that
+ protection space. The Authorization header may be included
+ preemptively; doing so improves server efficiency and avoids extra
+ round trips for authentication challenges. The server may choose to
+ accept the old Authorization header information, even though the
+ nonce value included might not be fresh. Alternatively, the server
+ may 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 tells the client to retry with the new nonce, but without
+ prompting for a new username and password.
+</t>
+<t>
+ Because the client is required to return the value of the opaque
+ directive given to it by the server for the duration of a session,
+ the opaque data may be used to transport authentication session state
+ information. (Note that any such use can also be accomplished more
+ easily and safely by including the state in the nonce.) For example,
+ a server could be responsible for authenticating content that
+ actually sits on another server. It would achieve this by having the
+ first 401 response include a domain directive whose value includes a
+ URI on the second server, and an opaque directive whose value
+ contains the state information. The client will retry the request, at
+ which time the server might respond with a 301/302 redirection,
+ pointing to the URI on the second server. The client will follow the
+ redirection, and pass an Authorization header , including the
+ <opaque> data.
+</t>
+<t>
+ As with the basic scheme, proxies must be completely transparent in
+ the Digest access authentication scheme. That is, they must forward
+ the WWW-Authenticate, Authentication-Info 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 described in <xref target="proxy-authentication.and.proxy-authorization"/>
+ below.
+</t>
+</section>
+
+<section title="Security Protocol Negotiation">
+<t>
+ It is useful for a server to be able to know which security schemes a
+ client is capable of handling.
+</t>
+<t>
+ 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 only authentication schemes it cannot handle.
+</t>
+</section>
+
+<section title="Example" anchor="specification.of.digest.headers.example">
+<t>
+ The following example assumes that an access-protected document is
+ being requested from the server via a GET request. 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 "Circle Of Life" (with one space between each of the
+ three words).
+</t>
+<t>
+ The first time the client requests the document, no Authorization
+ header is sent, so the server responds with:
+</t>
+<figure><artwork type='message/http; msgytpe="response"'>
+ HTTP/1.1 401 Unauthorized
+ WWW-Authenticate: Digest
+ realm="testrealm@host.com",
+ qop="auth,auth-int",
+ nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
+</artwork></figure>
+<t>
+ 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:
+</t>
+<figure><artwork type="example">
+ Authorization: Digest username="Mufasa",
+ realm="testrealm@host.com",
+ nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+ uri="/dir/index.html",
+ qop=auth,
+ nc=00000001,
+ cnonce="0a4f113b",
+ response="6629fae49393a05397450978507c4ef1",
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
+</artwork></figure>
+</section>
+
+<section title="Proxy-Authentication and Proxy-Authorization" anchor="proxy-authentication.and.proxy-authorization">
+<t>
+ The digest authentication scheme may also be used for authenticating
+ users to proxies, proxies to proxies, or proxies to origin servers by
+ use of the Proxy-Authenticate and Proxy-Authorization headers. These
+ headers are instances of the Proxy-Authenticate and Proxy-Authorization
+ headers specified in sections <xref target="RFC2616" x:fmt="number" x:sec="10.33"/> and <xref target="RFC2616" x:fmt="number" x:sec="10.34"/> of the
+ HTTP/1.1 specification <xref target="RFC2616"/> and their behavior is subject to
+ restrictions described there. The transactions for proxy
+ authentication are very similar to those already described. Upon
+ receiving a request which requires authentication, the proxy/server
+ must issue the "407 Proxy Authentication Required" response with a
+ "Proxy-Authenticate" header. The digest-challenge used in the
+ Proxy-Authenticate header is the same as that for the WWW-Authenticate
+ header as defined above in <xref target="the.www-authenticate.response.header"/>.
+</t>
+<t>
+ The client/proxy must then re-issue the request with a Proxy-Authorization
+ header, with directives as specified for the
+ Authorization header in <xref target="the.authorization.request.header"/> above.
+</t>
+<t>
+ On subsequent responses, the server sends Proxy-Authentication-Info
+ with directives the same as those for the Authentication-Info header
+ field.
+</t>
+<t>
+ Note that in principle a client could be asked to authenticate itself
+ to both a proxy and an end-server, but never in the same response.
+</t>
+</section>
+</section>
+
+<section title="Security Considerations" anchor="security.considerations">
+
+<section title="Authentication of Clients using Basic Authentication">
+<t>
+ The Basic authentication scheme is not a secure method of user
+ authentication, nor does it in any way protect the entity, which is
+ transmitted in cleartext across the physical network used as the
+ carrier. HTTP does not prevent additional authentication schemes and
+ encryption mechanisms from being employed to increase security or the
+ addition of enhancements (such as schemes to use one-time passwords)
+ to Basic authentication.
+</t>
+<t>
+ The most serious flaw in Basic authentication is that it results in
+ the essentially cleartext transmission of the user's password over
+ the physical network. It is this problem which Digest Authentication
+ attempts to address.
+</t>
+<t>
+ Because Basic authentication involves the cleartext transmission of
+ passwords it &SHOULD-NOT; be used (without enhancements) to protect
+ sensitive or valuable information.
+</t>
+<t>
+ A common use of Basic authentication is for identification purposes
+ -- requiring the user to provide a user name and password as a means
+ of identification, for example, for purposes of gathering accurate
+ usage statistics on a server. When used in this way it is tempting to
+ think that there is no danger in its use if illicit access to the
+ protected documents is not a major concern. This is only correct if
+ the server issues both user name and password to the users and in
+ particular does not allow the user to choose his or her own password.
+ The danger arises because naive users frequently reuse a single
+ password to avoid the task of maintaining multiple passwords.
+</t>
+<t>
+ If a server permits users to select their own passwords, then the
+ threat is not only unauthorized access to documents on the server but
+ also unauthorized access to any other resources on other systems that
+ the user protects with the same password. Furthermore, in the
+ server's password database, many of the passwords may also be users'
+ passwords for other sites. The owner or administrator of such a
+ system could therefore expose all users of the system to the risk of
+ unauthorized access to all those sites if this information is not
+ maintained in a secure fashion.
+</t>
+<t>
+ Basic Authentication is also vulnerable to spoofing by counterfeit
+ servers. If a user can be led to believe that he is connecting to a
+ host containing information protected by Basic authentication when,
+ in fact, he is connecting to a hostile server or gateway, then the
+ attacker can request a password, store it for later use, and feign an
+ error. This type of attack is not possible with Digest
+ Authentication. Server implementers &SHOULD; guard against the
+ possibility of this sort of counterfeiting by gateways or CGI
+ scripts. In particular it is very dangerous for a server to simply
+ turn over a connection to a gateway. That gateway can then use the
+ persistent connection mechanism to engage in multiple transactions
+ with the client while impersonating the original server in a way that
+ is not detectable by the client.
+</t>
+</section>
+
+<section title="Authentication of Clients using Digest Authentication">
+<t>
+ Digest Authentication does not provide a strong authentication
+ mechanism, when compared to public key based mechanisms, for example.
+ However, it is significantly stronger than (e.g.) CRAM-MD5, which has
+ been proposed for use with LDAP <xref target="ref10"/>, POP and IMAP (see RFC 2195
+ <xref target="RFC2195"/>). It is intended to replace the much weaker and even more
+ dangerous Basic mechanism.
+</t>
+<t>
+ Digest Authentication offers no confidentiality protection beyond
+ protecting the actual password. All of the rest of the request and
+ response are available to an eavesdropper.
+</t>
+<t>
+ Digest Authentication offers only limited integrity protection for
+ the messages in either direction. If qop=auth-int mechanism is used,
+ those parts of the message used in the calculation of the WWW-Authenticate
+ and Authorization header field response directive values
+ (see <xref target="specification.of.digest.headers"/> above) are protected. Most header fields and their
+ values could be modified as a part of a man-in-the-middle attack.
+</t>
+<t>
+ Many needs for secure HTTP transactions cannot be met by Digest
+ Authentication. For those needs TLS or SHTTP are more appropriate
+ protocols. In particular Digest authentication cannot be used for any
+ transaction requiring confidentiality protection. Nevertheless many
+ functions remain for which Digest authentication is both useful and
+ appropriate. Any service in present use that uses Basic should be
+ switched to Digest as soon as practical.
+</t>
+</section>
+
+<section title="Limited Use Nonce Values">
+<t>
+ The Digest scheme uses a server-specified nonce to seed the
+ generation of the request-digest value (as specified in <xref target="request-digest"/>
+ above). As shown in the example nonce in <xref target="the.www-authenticate.response.header"/>, the
+ server is free to construct the nonce such that it may only be used
+ from a particular client, for a particular resource, for a limited
+ period of time or number of uses, or any other restrictions. Doing
+ so strengthens the protection provided against, for example, replay
+ attacks (see 4.5). However, it should be noted that the method
+ chosen for generating and checking the nonce also has performance and
+ resource implications. For example, a server may choose to allow
+ each nonce value to be used only once by maintaining a record of
+ whether or not each recently issued nonce has been returned and
+ sending a next-nonce directive in the Authentication-Info header
+ field of every response. This protects against even an immediate
+ replay attack, but has a high cost checking nonce values, and perhaps
+ more important will cause authentication failures for any pipelined
+ requests (presumably returning a stale nonce indication). Similarly,
+ incorporating a request-specific element such as the Etag value for a
+ resource limits the use of the nonce to that version of the resource
+ and also defeats pipelining. Thus it may be useful to do so for
+ methods with side effects but have unacceptable performance for those
+ that do not.
+</t>
+</section>
+
+<section title="Comparison of Digest with Basic Authentication">
+<t>
+ 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.
+</t>
+<t>
+ 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 database, but, often worse,
+ will permit access to anything else the user protects with the same
+ password.
+</t>
+<t>
+ 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
+ may be limited by the server's choice of nonce.
+</t>
+</section>
+
+<section title="Replay Attacks">
+<t>
+ 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 request 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.
+</t>
+<t>
+ 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 time-stamp, the resource
+ ETag, 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 time-stamp expires. Digesting the
+ client IP and time-stamp in the nonce permits an implementation which
+ does not maintain state between transactions.
+</t>
+<t>
+ For applications where no possibility of replay attack can be
+ tolerated the server can use one-time nonce values which will not be
+ honored for a second use. This requires the overhead of the server
+ remembering which nonce values have been used until the nonce time-stamp
+ (and hence the digest built with it) has expired, but it
+ effectively protects against replay attacks.
+</t>
+<t>
+ An implementation must give special attention to the possibility of
+ replay attacks with POST and PUT requests. Unless the server employs
+ one-time or otherwise limited-use nonces and/or insists on the use of
+ the integrity protection of qop=auth-int, an attacker could replay
+ valid credentials from a successful request with counterfeit form
+ data or other message body. Even with the use of integrity protection
+ most metadata in header fields is not protected. Proper nonce
+ generation and checking provides some protection against replay of
+ previously used valid credentials, but see 4.8.
+</t>
+</section>
+
+<section title="Weakness Created by Multiple Authentication Schemes">
+<t>
+ An HTTP/1.1 server may return multiple challenges with a 401
+ (Authenticate) response, and each challenge may use a different
+ auth-scheme. A user agent &MUST; choose to use the strongest auth-scheme
+ it understands and request credentials from the user based
+ upon that challenge.
+</t>
+<t>
+ <list><t>
+ Note that many browsers will only recognize Basic and will require
+ that it be the first auth-scheme presented. Servers should only
+ include Basic if it is minimally acceptable.
+ </t></list>
+</t>
+<t>
+ When the server offers choices of authentication schemes using the
+ WWW-Authenticate header, the strength of the resulting authentication
+ is only as good as that of the of the weakest of the authentication
+ schemes. See <xref target="man.in.the.middle"/> below for discussion of particular attack
+ scenarios that exploit multiple authentication schemes.
+</t>
+</section>
+
+<section title="Online dictionary attacks">
+<t>
+ If the attacker can eavesdrop, then it can test any overheard
+ nonce/response pairs against a list of common words. Such a list is
+ usually much smaller than the total number of possible passwords. The
+ cost of computing the response for each password on the list is paid
+ once for each challenge.
+</t>
+<t>
+ The server can mitigate this attack by not allowing users to select
+ passwords that are in a dictionary.
+</t>
+</section>
+
+<section title="Man in the Middle" anchor="man.in.the.middle">
+<t>
+ Both Basic and Digest authentication are vulnerable to "man in the
+ middle" (MITM) attacks, for example, from a hostile or compromised
+ proxy. Clearly, this would present all the problems of eavesdropping.
+ But it also offers some additional opportunities to the attacker.
+</t>
+<t>
+ A possible man-in-the-middle attack would be to add a weak
+ authentication scheme to the set of choices, hoping that the client
+ will use one that exposes the user's credentials (e.g. password). For
+ this reason, the client should always use the strongest scheme that
+ it understands from the choices offered.
+</t>
+<t>
+ An even better MITM attack would be to remove all offered choices,
+ replacing them with a challenge that requests only Basic
+ authentication, then uses the cleartext credentials from the Basic
+ authentication to authenticate to the origin server using the
+ stronger scheme it requested. A particularly insidious way to mount
+ such a MITM attack would be to offer a "free" proxy caching service
+ to gullible users.
+</t>
+<t>
+ User agents should consider measures such as presenting a visual
+ indication at the time of the credentials request of what
+ authentication scheme is to be used, or remembering the strongest
+ authentication scheme ever requested by a server and produce a
+ warning message before using a weaker one. It might also be a good
+ idea for the user agent to be configured to demand Digest
+ authentication in general, or from specific sites.
+</t>
+<t>
+ Or, 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.
+</t>
+</section>
+
+<section title="Chosen plaintext attacks">
+<t>
+ With Digest authentication, a MITM or a malicious server can
+ arbitrarily choose the nonce that the client will use to compute the
+ response. This is called a "chosen plaintext" attack. The ability to
+ choose the nonce is known to make cryptanalysis much easier <xref target="ref8"/>.
+</t>
+<t>
+ However, no way to analyze the MD5 one-way function used by Digest
+ using chosen plaintext is currently known.
+</t>
+<t>
+ The countermeasure against this attack is for clients to be
+ configured to require the use of the optional "cnonce" directive;
+ this allows the client to vary the input to the hash in a way not
+ chosen by the attacker.
+</t>
+</section>
+
+<section title="Precomputed dictionary attacks">
+<t>
+ With Digest authentication, if the attacker can execute a chosen
+ plaintext attack, the attacker can precompute the response for many
+ common words to a nonce of its choice, and store a dictionary of
+ (response, password) pairs. Such precomputation can often be done in
+ parallel on many machines. It can then use the chosen plaintext
+ attack to acquire a response corresponding to that challenge, and
+ just look up the password in the dictionary. Even if most passwords
+ are not in the dictionary, some might be. Since the attacker gets to
+ pick the challenge, the cost of computing the response for each
+ password on the list can be amortized over finding many passwords. A
+ dictionary with 100 million password/response pairs would take about
+ 3.2 gigabytes of disk storage.
+</t>
+<t>
+ The countermeasure against this attack is to for clients to be
+ configured to require the use of the optional "cnonce" directive.
+</t>
+</section>
+
+<section title="Batch brute force attacks">
+<t>
+ With Digest authentication, a MITM can execute a chosen plaintext
+ attack, and can gather responses from many users to the same nonce.
+ It can then find all the passwords within any subset of password
+ space that would generate one of the nonce/response pairs in a single
+ pass over that space. It also reduces the time to find the first
+ password by a factor equal to the number of nonce/response pairs
+ gathered. This search of the password space can often be done in
+ parallel on many machines, and even a single machine can search large
+ subsets of the password space very quickly -- reports exist of
+ searching all passwords with six or fewer letters in a few hours.
+</t>
+<t>
+ The countermeasure against this attack is to for clients to be
+ configured to require the use of the optional "cnonce" directive.
+</t>
+</section>
+
+<section title="Spoofing by Counterfeit Servers">
+<t>
+ 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 more difficult with Digest
+ Authentication -- but the client must know to demand that Digest
+ authentication be used, perhaps using some of the techniques
+ described above to counter "man-in-the-middle" attacks. Again, the
+ user can be helped in detecting this attack by a visual indication of
+ the authentication mechanism in use with appropriate guidance in
+ interpreting the implications of each scheme.
+</t>
+</section>
+
+<section title="Storing passwords">
+<t>
+ Digest authentication requires that the authenticating agent (usually
+ the server) store some data derived from the user's name and password
+ in a "password file" associated with a given realm. Normally this
+ might contain pairs consisting of username and H(A1), where H(A1) is
+ the digested value of the username, realm, and password as described
+ above.
+</t>
+<t>
+ The security implications of this are that if this password file is
+ compromised, then an attacker gains immediate access to documents on
+ the server using this realm. Unlike, say a standard UNIX password
+ file, this information need not be decrypted in order to access
+ documents in the server realm associated with this file. On the other
+ hand, decryption, or more likely a brute force attack, would be
+ necessary to obtain the user's password. This is the reason that the
+ realm is part of the digested data stored in the password file. It
+ means that if one Digest authentication password file is compromised,
+ it does not automatically compromise others with the same username
+ and password (though it does expose them to brute force attack).
+</t>
+<t>
+ There are two important security consequences of this. First the
+ password file must be protected as if it contained unencrypted
+ passwords, because for the purpose of accessing documents in its
+ realm, it effectively does.
+</t>
+<t>
+ A second consequence of this is that the realm string should be
+ unique among all realms which any single user is likely to use. In
+ particular a realm string should include the name of the host doing
+ the authentication. The inability of the client to authenticate the
+ server is a weakness of Digest Authentication.
+</t>
+</section>
+
+<section title="Summary">
+<t>
+ 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 some, 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. Others may satisfied with a nonce like the one
+ recommended above restricted to a single IP address and a single ETag
+ or with a limited lifetime.
+</t>
+<t>
+ 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.
+</t>
+</section>
+</section>
+
+<section title="Sample implementation">
+<t>
+ The following code implements the calculations of H(A1), H(A2),
+ request-digest and response-digest, and a test program which computes
+ the values used in the example of <xref target="specification.of.digest.headers.example"/>. It uses the MD5
+ implementation from RFC 1321.
+</t>
+<figure><preamble>
+ File "digcalc.h":
+</preamble><artwork type="code" name="digcalc.h">
+#define HASHLEN 16
+typedef char HASH[HASHLEN];
+#define HASHHEXLEN 32
+typedef char HASHHEX[HASHHEXLEN+1];
+#define IN
+#define OUT
+
+/* calculate H(A1) as per HTTP Digest spec */
+void DigestCalcHA1(
+ IN char * pszAlg,
+ IN char * pszUserName,
+ IN char * pszRealm,
+ IN char * pszPassword,
+ IN char * pszNonce,
+ IN char * pszCNonce,
+ OUT HASHHEX SessionKey
+ );
+
+/* calculate request-digest/response-digest as per HTTP Digest spec */
+void DigestCalcResponse(
+ IN HASHHEX HA1, /* H(A1) */
+ IN char * pszNonce, /* nonce from server */
+ IN char * pszNonceCount, /* 8 hex digits */
+ IN char * pszCNonce, /* client nonce */
+ IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
+ IN char * pszMethod, /* method from the request */
+ IN char * pszDigestUri, /* requested URL */
+ IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
+ OUT HASHHEX Response /* request-digest or response-digest */
+ );
+</artwork></figure>
+<figure><preamble>
+File "digcalc.c":
+</preamble><artwork type="example" name="digcalc.c">
+#include <global.h>
+#include <md5.h>
+#include <string.h>
+#include "digcalc.h"
+
+void CvtHex(
+ IN HASH Bin,
+ OUT HASHHEX Hex
+ )
+{
+ unsigned short i;
+ unsigned char j;
+
+ for (i = 0; i < HASHLEN; i++) {
+ j = (Bin[i] >> 4) & 0xf;
+ if (j <= 9)
+ Hex[i*2] = (j + '0');
+ else
+ Hex[i*2] = (j + 'a' - 10);
+ j = Bin[i] & 0xf;
+ if (j <= 9)
+ Hex[i*2+1] = (j + '0');
+ else
+ Hex[i*2+1] = (j + 'a' - 10);
+ };
+ Hex[HASHHEXLEN] = '\0';
+};
+
+/* calculate H(A1) as per spec */
+void DigestCalcHA1(
+ IN char * pszAlg,
+ IN char * pszUserName,
+ IN char * pszRealm,
+ IN char * pszPassword,
+ IN char * pszNonce,
+ IN char * pszCNonce,
+ OUT HASHHEX SessionKey
+ )
+{
+ MD5_CTX Md5Ctx;
+ HASH HA1;
+
+ MD5Init(&Md5Ctx);
+ MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
+ MD5Final(HA1, &Md5Ctx);
+ if (stricmp(pszAlg, "md5-sess") == 0) {
+ MD5Init(&Md5Ctx);
+ MD5Update(&Md5Ctx, HA1, HASHLEN);
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
+ MD5Final(HA1, &Md5Ctx);
+ };
+ CvtHex(HA1, SessionKey);
+};
+
+/* calculate request-digest/response-digest as per HTTP Digest spec */
+void DigestCalcResponse(
+ IN HASHHEX HA1, /* H(A1) */
+ IN char * pszNonce, /* nonce from server */
+ IN char * pszNonceCount, /* 8 hex digits */
+ IN char * pszCNonce, /* client nonce */
+ IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
+ IN char * pszMethod, /* method from the request */
+ IN char * pszDigestUri, /* requested URL */
+ IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
+ OUT HASHHEX Response /* request-digest or response-digest */
+ )
+{
+ MD5_CTX Md5Ctx;
+ HASH HA2;
+ HASH RespHash;
+ HASHHEX HA2Hex;
+
+ // calculate H(A2)
+ MD5Init(&Md5Ctx);
+ MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri));
+ if (stricmp(pszQop, "auth-int") == 0) {
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, HEntity, HASHHEXLEN);
+ };
+ MD5Final(HA2, &Md5Ctx);
+ CvtHex(HA2, HA2Hex);
+
+ // calculate response
+ MD5Init(&Md5Ctx);
+ MD5Update(&Md5Ctx, HA1, HASHHEXLEN);
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
+ MD5Update(&Md5Ctx, ":", 1);
+ if (*pszQop) {
+ MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
+ MD5Update(&Md5Ctx, ":", 1);
+ MD5Update(&Md5Ctx, pszQop, strlen(pszQop));
+ MD5Update(&Md5Ctx, ":", 1);
+ };
+ MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN);
+ MD5Final(RespHash, &Md5Ctx);
+ CvtHex(RespHash, Response);
+};
+</artwork></figure>
+<figure><preamble>
+File "digtest.c":
+</preamble><artwork type="example" name="digtest.c">
+#include <stdio.h>
+#include "digcalc.h"
+
+void main(int argc, char ** argv) {
+
+ char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
+ char * pszCNonce = "0a4f113b";
+ char * pszUser = "Mufasa";
+ char * pszRealm = "testrealm@host.com";
+ char * pszPass = "Circle Of Life";
+ char * pszAlg = "md5";
+ char szNonceCount[9] = "00000001";
+ char * pszMethod = "GET";
+ char * pszQop = "auth";
+ char * pszURI = "/dir/index.html";
+ HASHHEX HA1;
+ HASHHEX HA2 = "";
+ HASHHEX Response;
+
+ DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
+pszCNonce, HA1);
+ DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
+ pszMethod, pszURI, HA2, Response);
+ printf("Response = %s\n", Response);
+};
+</artwork></figure>
+</section>
+
+<section title="Acknowledgments">
+<t>
+ Eric W. Sink, of AbiSource, Inc., was one of the original authors
+ before the specification underwent substantial revision.
+</t>
+<t>
+ In addition to the authors, valuable discussion instrumental in
+ creating this document has come from Peter J. Churchyard, Ned Freed,
+ and David M. Kristol.
+</t>
+<t>
+ Jim Gettys and Larry Masinter edited this document for update.
+</t>
+</section>
+ </middle>
+ <back>
+
+<references>
+
+<reference anchor='RFC1945'>
+<front>
+<title abbrev='HTTP/1.0'>Hypertext Transfer Protocol -- HTTP/1.0</title>
+<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
+<organization>MIT, Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street />
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials='H.F.' surname='Nielsen' fullname='Henrik Frystyk Nielsen'>
+<organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<date year='1996' month='May' />
+</front>
+<seriesInfo name='RFC' value='1945' />
+</reference>
+
+<reference anchor="RFC2616">
+
+<front>
+<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92697-3425</code>
+<country>US</country></postal>
+<phone>+1 949 824 1715</phone>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="James Gettys">
+<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<phone/>
+<facsimile>+1 617 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Compaq Computer Corporation, Western Research Laboratory</organization>
+<address>
+<postal>
+<street>250 University Avenue</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94301</code>
+<country>US</country></postal>
+<phone/>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<phone/>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<author initials="L." surname="Masinter" fullname="Larry Masinter">
+<organization>Xerox Corporation</organization>
+<address>
+<postal>
+<street>3333 Coyote Hill Road</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94034</code>
+<country>US</country></postal>
+<phone/>
+<email>masinter@parc.xerox.com</email></address></author>
+<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
+<organization>Microsoft Corporation</organization>
+<address>
+<postal>
+<street>1 Microsoft Way</street>
+<city>Redmond</city>
+<region>WA</region>
+<code>98052</code>
+<country>US</country></postal>
+<phone/>
+<email>paulle@microsoft.com</email></address></author>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>World Wide Web Consortium, MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<phone>+1 617 258 8682</phone>
+<facsimile/>
+<email>timbl@w3.org</email></address></author>
+<date month="June" year="1999"/>
+</front>
+<seriesInfo name="RFC" value="2616"/>
+</reference>
+
+<reference anchor='RFC1321'>
+<front>
+<title abbrev='MD5 Message-Digest Algorithm'>The MD5 Message-Digest Algorithm</title>
+<author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
+<organization>Massachusetts Institute of Technology, (MIT) Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<street>NE43-324</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139-1986</code>
+<country>US</country></postal>
+<phone>+1 617 253 5880</phone>
+<email>rivest@theory.lcs.mit.edu</email></address></author>
+<date year='1992' month='April' /></front>
+<seriesInfo name='RFC' value='1321' />
+</reference>
+
+<reference anchor='RFC2045'>
+<front>
+<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+<author initials='N.' surname='Freed' fullname='Ned Freed'>
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date year='1996' month='November' />
+</front>
+<seriesInfo name='RFC' value='2045' />
+</reference>
+
+<reference anchor='RFC2246'>
+<front>
+<title>The TLS Protocol Version 1.0</title>
+<author initials='T.' surname='Dierks' fullname='Tim Dierks'>
+<organization>Certicom</organization>
+<address>
+<email>tdierks@certicom.com</email></address></author>
+<author initials='C.' surname='Allen' fullname='Christopher Allen'>
+<organization>Certicom</organization>
+<address>
+<email>callen@certicom.com</email></address></author>
+<date year='1999' month='January' />
+</front>
+<seriesInfo name='RFC' value='2246' />
+<format type='TXT' octets='170401' target='ftp://ftp.isi.edu/in-notes/rfc2246.txt' />
+</reference>
+
+
+<reference anchor='RFC2069'>
+<front>
+<title abbrev='Digest Access Authentication'>An Extension to HTTP : Digest Access Authentication</title>
+<author initials='J.' surname='Franks' fullname='John Franks'>
+<organization>Northwestern University, Department of Mathematics</organization>
+<address>
+<postal>
+<street />
+<city>Evanston</city>
+<region>IL</region>
+<code>60208-2730</code>
+<country>US</country></postal>
+<email>john@math.nwu.edu</email></address></author>
+<author initials='P.' surname='Hallam-Baker' fullname='Phillip M. Hallam-Baker'>
+<organization>CERN</organization>
+<address>
+<postal>
+<street />
+<city>Geneva</city>
+<country>CH</country></postal>
+<email>hallam@w3.org</email></address></author>
+<author initials='J.' surname='Hostetler' fullname='Jeffery L. Hostetler'>
+<organization>Spyglass, Inc.</organization>
+<address>
+<postal>
+<street>3200 Farber Drive</street>
+<city>Champaign</city>
+<region>IL</region>
+<code>61821</code>
+<country>US</country></postal>
+<email>jeff@spyglass.com</email></address></author>
+<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
+<organization>Microsoft Corporation</organization>
+<address>
+<postal>
+<street>1 Microsoft Way</street>
+<city>Redmond</city>
+<region>WA</region>
+<code>98052</code>
+<country>US</country></postal>
+<email>paulle@microsoft.com</email></address></author>
+<author initials='A.' surname='Luotonen' fullname='Ari Luotonen'>
+<organization>Netscape Communications Corporation</organization>
+<address>
+<postal>
+<street>501 East Middlefield Road</street>
+<city>Mountain View</city>
+<region>CA</region>
+<code>94043</code>
+<country>US</country></postal>
+<email>luotonen@netscape.com</email></address></author>
+<author initials='E.' surname='Sink' fullname='Eric W. Sink'>
+<organization>Spyglass, Inc.</organization>
+<address>
+<postal>
+<street>3200 Farber Drive</street>
+<city>Champaign</city>
+<region>IL</region>
+<code>61821</code>
+<country>US</country></postal>
+<email>eric@spyglass.com</email></address></author>
+<author initials='L.' surname='Stewart' fullname='Lawrence C. Stewart'>
+<organization>Open Market, Inc.</organization>
+<address>
+<postal>
+<street>215 First Street</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02142</code>
+<country>US</country></postal>
+<email>stewart@OpenMarket.com</email></address></author>
+<date year='1997' month='January' />
+</front>
+<seriesInfo name='RFC' value='2069' />
+</reference>
+
+<reference anchor="RFC2396">
+ <front>
+ <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization>World Wide Web Consortium</organization>
+ <address>
+ <email>timbl@w3.org</email></address>
+ </author>
+ <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+ <organization>Department of Information and Computer Science</organization>
+ <address>
+ <email>fielding@ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization>Xerox PARC</organization>
+ <address>
+ <email>masinter@parc.xerox.com</email>
+ </address>
+ </author>
+ <date month="August" year="1998"/>
+ </front>
+ <seriesInfo name="RFC" value="2396"/>
+</reference>
+
+<reference anchor="ref8" target="http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm">
+ <front>
+ <title>Message Authentication with MD5</title>
+ <author initials="B." surname="Kaliski">
+ <organization/>
+ </author>
+ <author initials="M." surname="Robshaw">
+ <organization/>
+ </author>
+ <date year="1995"/>
+ </front>
[... 72 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org