< draft-ietf-http-authentication-01.txt   draft-ietf-http-authentication-02.txt >
HTTP Working Group J. Franks, Northwestern University HTTP Working Group J. Franks, Northwestern University
INTERNET DRAFT P. Hallam-Baker, M.I.T. INTERNET DRAFT P. Hallam-Baker, Verisign, Inc.
<draft-ietf-http-authentication-01> J. Hostetler, Spyglass, Inc. <draft-ietf-http-authentication-02> J. Hostetler, Spyglass, Inc.
S. Lawrence, Agranat, Inc.
P. Leach, Microsoft Corporation P. Leach, Microsoft Corporation
A. Luotonen, Netscape Communications Corporation A. Luotonen, Netscape Communications Corporation
E. Sink, Spyglass, Inc.
L. Stewart, Open Market, Inc. L. Stewart, Open Market, Inc.
S. Lawrence, Agranat, Inc. Expires: February 7, 1999 August 7, 1998
Expires: September 13, 1998 March 13, 1998
HTTP Authentication: Basic and Digest Access Authentication HTTP Authentication: Basic and 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, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at any and may be updated, replaced, or made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress". or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast).
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to the Distribution of this document is unlimited. Please send comments to the
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the HTTP working group at <http-wg@hplb.hpl.hp.com>. Discussions of the
working group are archived at working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about <URL:http://www.ics.uci.edu/pub/ietf/http/>.
HTTP and the applications which use HTTP should take place on the <www-
talk@w3.org> mailing list. Copyright NoticeCopyright (C) The Internet Society (1998). All Rights
Reserved. See section 9 for the full copyright notice.
Abstract Abstract
''HTTP/1.0'' includes the specification for a Basic Access Authentication "HTTP/1.0" includes the specification for a Basic Access Authentication
scheme. This scheme is not considered to be a secure method of user scheme. This scheme is not considered to be a secure method of user
authentication (unless used in conjunction with some external secure authentication (unless used in conjunction with some external secure
system such as SSL [5]), as the user name and password are passed over system such as SSL [5]), as the user name and password are passed over
the network as cleartext. the network as cleartext.
This document also provides the specification for HTTP's authentication This document also provides the specification for HTTP's authentication
framework, the original Basic authentication scheme and a scheme based framework, the original Basic authentication scheme and a scheme based
on cryptographic hashes, referred to as ''Digest Access Authentication''. on cryptographic hashes, referred to as "Digest Access Authentication".
It is therefore also intended to serve as a replacement for RFC 2069 It is therefore also intended to serve as a replacement for RFC 2069
[6]. Some optional elements specified by RFC 2069 have been removed [6]. Some optional elements specified by RFC 2069 have been removed
from this specification due to problems found since its publication; from this specification due to problems found since its publication;
other new elements have been added -for compatibility, those new other new elements have been added -for compatibility, those new
elements have been made optional, but are strongly recommended. elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a 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, verification can be done without sending the password in the clear,
which is Basic's biggest weakness. As with most other authentication which is Basic's biggest weakness. As with most other authentication
protocols, the greatest sources of risks are usually found not in the protocols, the greatest sources of risks are usually found not in the
core protocol itself but in policies and procedures surrounding its use. core protocol itself but in policies and procedures surrounding its use.
Table of Contents Table of Contents
HTTP AUTHENTICATION: BASIC AND DIGEST ACCESS AUTHENTICATION1 HTTP AUTHENTICATION: BASIC AND DIGEST ACCESS AUTHENTICATION1
Status of this Memo........................................1 Status of this Memo........................................1
skipping to change at page 3, line 28 skipping to change at page 3, line ?
2 Basic Authentication Scheme ...........................6 2 Basic Authentication Scheme ...........................6
3 Digest Access Authentication Scheme ...................7 3 Digest Access Authentication Scheme ...................7
3.1 Introduction ........................................7 3.1 Introduction ........................................7
3.1.1 Purpose ..........................................7 3.1.1 Purpose ..........................................7
3.1.2 Overall Operation ................................8 3.1.2 Overall Operation ................................8
3.1.3 Representation of digest values ..................8 3.1.3 Representation of digest values ..................8
3.1.4 Limitations ......................................8 3.1.4 Limitations ......................................8
3.2 Specification of Digest Headers .....................8 3.2 Specification of Digest Headers .....................8
3.2.1 The WWW-Authenticate Response Header .............9 3.2.1 The WWW-Authenticate Response Header.............8
3.2.2 The Authorization Request Header ................11 3.2.2 The Authorization Request Header ................11
3.2.3 The Authentication-Info Header ..................15 3.2.3 The Authentication-Info Header ..................15
3.3 Digest Operation ...................................16 3.3 Digest Operation ...................................16
3.4 Security Protocol Negotiation ......................16 3.4 Security Protocol Negotiation ......................16
3.5 Example ............................................17 3.5 Example ............................................17
3.6 Proxy-Authentication and Proxy-Authorization .......17 3.6 Proxy-Authentication and Proxy-Authorization .......17
4 Security Considerations ..............................18 4 Security Considerations ..............................18
4.1 Authentication of Clients using Basic Authentication18 4.1 Authentication of Clients using Basic Authentication18
4.2 Authentication of Clients using Digest Authentication 19 4.2 Authentication of Clients using Digest Authentication18
4.3 Limited Use Nonce Values ...........................19 4.3 Limited Use Nonce Values ...........................19
4.4 Comparison of Digest with Basic Authentication .....20 4.4 Comparison of Digest with Basic Authentication.....19
4.5 Replay Attacks .....................................20 4.5 Replay Attacks .....................................20
4.6 Weakness Created by Multiple Authentication Schemes 21 4.6 Weakness Created by Multiple Authentication Schemes20
4.7 Online dictionary attacks ..........................21 4.7 Online dictionary attacks ..........................21
4.8 Man in the Middle ..................................22 4.8 Man in the Middle..................................21
4.9 Chosen plaintext attacks ...........................22 4.9 Chosen plaintext attacks ...........................22
4.10 Precomputed dictionary attacks .....................23 4.10 Precomputed dictionary attacks.....................22
4.11 Batch brute force attacks ..........................23 4.11 Batch brute force attacks..........................22
4.12 Spoofing by Counterfeit Servers ....................23 4.12 Spoofing by Counterfeit Servers....................22
4.13 Storing passwords ..................................23 4.13 Storing passwords ..................................23
4.14 Summary ............................................24 4.14 Summary............................................23
5 Acknowledgments ......................................24 5 Sample implementation................................23
6 References ...........................................25 6 Acknowledgments......................................27
7 Authors' Addresses ...................................25 7 References...........................................27
8 Authors' Addresses...................................28
1 Access Authentication 1 Access Authentication
1.1 Reliance on the HTTP/1.1 Specification 1.1 Reliance on the HTTP/1.1 Specification
This specification is a companion to the HTTP/1.1 specification [2]. It This specification is a companion to the HTTP/1.1 specification [2]. It
uses using the extended BNF section 2.1 of that document, and relies on uses the augmented BNF section 2.1 of that document, and relies on both
both the BNF defined in that document and other aspects of the HTTP/1.1 the non-terminals defined in that document and other aspects of the
specification. HTTP/1.1 specification.
1.2 Access Authentication Framework 1.2 Access Authentication Framework
HTTP provides a simple challenge-response authentication mechanism which 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 MAY be used by a server to challenge a client request and by a client to
provide authentication information. It uses an extensible, case- provide authentication information. It uses an extensible, case-
insensitive token to identify the authentication scheme, followed by a insensitive token to identify the authentication scheme, followed by a
comma-separated list of attribute-value pairs which carry the parameters comma-separated list of attribute-value pairs which carry the parameters
necessary for achieving authentication via that scheme. necessary for achieving authentication via that scheme.
auth-scheme = token auth-scheme = token
auth-param = token "=" ( token | quoted-string ) auth-param = token "=" ( token | quoted-string )
The 401 (Unauthorized) response message is used by an origin server to The 401 (Unauthorized) response message is used by an origin server to
challenge the authorization of a user agent. This response MUST include challenge the authorization of a user agent. This response MUST include
a WWW-Authenticate header field containing at least one challenge a WWW-Authenticate header field containing at least one challenge
applicable to the requested resource. The 407 (Proxy Authentication applicable to the requested resource. The 407 (Proxy Authentication
Required) response message is used by a proxy to challenge the Required) response message is used by a proxy to challenge the
authorization of a client and MUST include a Proxy-Authenticate header authorization of a client and MUST include a Proxy-Authenticate header
field containing a challenge applicable to the proxy for the requested field containing at least one challenge applicable to the proxy for the
resource. requested resource.
challenge = auth-scheme 1*SP 1#auth-param challenge = auth-scheme 1*SP 1#auth-param
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.
The authentication parameter realm is defined for all authentication The authentication parameter realm is defined for all authentication
schemes: schemes:
realm = "realm" "=" realm-value realm = "realm" "=" realm-value
realm-value = quoted-string realm-value = quoted-string
The realm attribute (case-insensitive) is required for all The realm directive (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value (case- authentication schemes that issue a challenge. The realm value (case-
sensitive), in combination with the canonical root URL (see section sensitive), in combination with the canonical root URL (the absoluteURI
5.1.2 of [2]) of the server being accessed, defines the protection for the server whose abs_path is empty; see section 5.1.2 of [2]) of the
space. These realms allow the protected resources on a server to be server being accessed, defines the protection space. These realms allow
partitioned into a set of protection spaces, each with its own the protected resources on a server to be partitioned into a set of
authentication scheme and/or authorization database. The realm value is protection spaces, each with its own authentication scheme and/or
a string, generally assigned by the origin server, which may have authorization database. The realm value is a string, generally assigned
additional semantics specific to the authentication scheme. 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.
A user agent that wishes to authenticate itself with an origin server-- A user agent that wishes to authenticate itself with an origin server--
usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY
do so by including an Authorization header field with the request. A do so by including an Authorization header field with the request. A
client that wishes to authenticate itself with a proxy--usually, but not client that wishes to authenticate itself with a proxy--usually, but not
necessarily, after receiving a 407 (Proxy Authentication Required)--MAY necessarily, after receiving a 407 (Proxy Authentication Required)--MAY
do so by including a Proxy-Authorization header field with the request. do so by including a Proxy-Authorization header field with the request.
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value consist of credentials containing the authentication information value consist of credentials containing the authentication information
of the client for the realm of the resource being requested. 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.
credentials = basic-credentials | auth-scheme #auth-param credentials = auth-scheme #auth-param
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.
The protection space determines the domain over which credentials can be The protection space determines the domain over which credentials can be
automatically applied. If a prior request has been authorized, the same automatically applied. If a prior request has been authorized, the same
credentials MAY be reused for all other requests within that protection credentials MAY be reused for all other requests within that protection
space for a period of time determined by the authentication scheme, space for a period of time determined by the authentication scheme,
parameters, and/or user preference. Unless otherwise defined by the parameters, and/or user preference. Unless otherwise defined by the
authentication scheme, a single protection space cannot extend outside authentication scheme, a single protection space cannot extend outside
the scope of its server. the scope of its server.
If the origin server does not wish to accept the credentials sent with a If the origin server does not wish to accept the credentials sent with a
skipping to change at page 6, line 55 skipping to change at page 7, line 7
The "basic" authentication scheme is based on the model that the client 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. 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 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 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 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 the protection space of the Request-URI. There are no optional
authentication parameters. authentication parameters.
For Basic, the framework above is utilized as follows: For Basic, the framework above is utilized as follows:
credentials = basic-credentials
challenge = "Basic" realm challenge = "Basic" realm
credentials = "Basic" basic-credentials
Upon receipt of an unauthorized request for a URI within the protection Upon receipt of an unauthorized request for a URI within the protection
space, the origin server MAY respond with a challenge like the space, the origin server MAY respond with a challenge like the
following: following:
WWW-Authenticate: Basic realm="WallyWorld" WWW-Authenticate: Basic realm="WallyWorld"
where "WallyWorld" is the string assigned by the server to identify the 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 protection space of the Request-URI. A proxy may respond with the same
challenge using the Proxy-Authenticate header field. challenge using the Proxy-Authenticate header field.
To receive authorization, the client sends the userid and password, To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7]encoded separated by a single colon (":") character, within a base64
[7
] encoded
string in the credentials. string in the credentials.
basic-credentials = "Basic" SP base64-user-pass basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass, base64-user-pass = <base64 [4] encoding of user-pass,
except not limited to 76 char/line> except not limited to 76 char/line>
user-pass = userid ":" password user-pass = userid ":" password
userid = *<TEXT excluding ":"> userid = *<TEXT excluding ":">
password = *TEXT password = *TEXT
Userids might be case sensitive. Userids might be case sensitive.
If the user agent wishes to send the userid "Aladdin" and password "open If the user agent wishes to send the userid "Aladdin" and password "open
sesame", it would use the following header field: sesame", it would use the following header field:
skipping to change at page 9, line 17 skipping to change at page 9, line 11
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 Authorization header is not sent, the server responds with a acceptable Authorization header is not sent, the server responds with a
"401 Unauthorized" status code, and a WWW-Authenticate header as per the "401 Unauthorized" status code, and a WWW-Authenticate header as per the
framework defined above, which for the digest scheme is utilized as framework defined above, which for the digest scheme is utilized as
follows : follows :
challenge = "Digest" digest-challenge challenge = "Digest" digest-challenge
digest-challenge = 1#( realm | [ domain ] | nonce | digest-challenge = 1#( realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] | [ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] ) [ qop-options ] | [auth-param] )
domain = "domain" "=" <"> URI ( 1*SP URI ) <"> domain = "domain" "=" <"> URI ( 1*SP URI ) <">
URI = absoluteURI | abs_path
nonce = "nonce" "=" nonce-value nonce = "nonce" "=" nonce-value
nonce-value = quoted-string nonce-value = quoted-string
opaque = "opaque" "=" quoted-string opaque = "opaque" "=" quoted-string
stale = "stale" "=" ( "true" | "false" ) stale = "stale" "=" ( "true" | "false" )
algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" |
token )
qop-options = "qop" "=" <"> 1#qop-value <"> qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token qop-value = "auth" | "auth-int" | token
The meanings of the values of the parameters used above are as follows: The meanings of the values of the parameters used above are as follows:
realm realm
A string to be displayed to users so they know which username and 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 password to use. This string should contain at least the name of the
host performing the authentication and might additionally indicate host performing the authentication and might additionally indicate
the collection of users who might have access. An example might be the collection of users who might have access. An example might be
"registered_users@gotham.news.com". "registered_users@gotham.news.com".
domain domain
A space-separated list of URIs, as specified in RFC XURI [7]. The A space-separated list of URIs, as specified in RFC XURI [7], that
intent is that the client could use this information to know the set define the protection space. If a URI is an abs_path, it is relative
of URIs for which the same authentication information should be sent. to canonical root URL (see section 1.2 above) of the server being
The URIs in this list may exist on different servers. If this keyword accessed. An absoluteURI in this list may refer to a different server
is omitted or empty, the client should assume that the domain than the one being accessed. The client can use this list to
consists of all URIs on the responding server. 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.
nonce nonce
A server-specified data string which may be uniquely generated each A server-specified data string which may be uniquely generated each
time a 401 response is made. It is recommended that this string be time a 401 response is made. 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 is in the header lines as a quoted string, the double-quote character is
not allowed. not allowed.
The contents of the nonce are implementation dependent. The quality The contents of the nonce are implementation dependent. The quality
of the implementation depends on a good choice. A nonce might, for of the implementation depends on a good choice. A nonce might, for
skipping to change at page 10, line 43 skipping to change at page 10, line 46
rejected because the nonce value was stale. If stale is TRUE (case- rejected because the nonce value was stale. If stale is TRUE (case-
insensitive), the client may wish to simply retry the request with a insensitive), the client may wish to simply retry the request with a
new encrypted response, without reprompting the user for a new new encrypted response, without reprompting the user for a new
username and password. The server should only set stale to true if it 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 receives a request for which the nonce is invalid but with a valid
digest for that nonce (indicating that the client knows the correct digest for that nonce (indicating that the client knows the correct
username/password). username/password).
algorithm algorithm
A string indicating a pair of algorithms used to produce the digest 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". In and a checksum. If this is not present it is assumed to be "MD5". If
this document the string obtained by applying the digest algorithm to the algorithm is not understood, the challenge should be ignored (and
the data "data" with secret "secret" will be denoted by KD(secret, a different one used, if there is more than one). In this document
data), and the string obtained by applying the checksum algorithm to the string obtained by applying the digest algorithm to the data
the data "data" will be denoted H(data). The notation unq(X) means "data" with secret "secret" will be denoted by KD(secret, data), and
the value of the quoted-string X without the surrounding quotes. 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.
For the "MD5" and "MD5-sess" algorithms For the "MD5" and "MD5-sess" algorithms
H(data) = MD5(data) H(data) = MD5(data)
and and
KD(secret, data) = H(concat(secret, ":", data)) KD(secret, data) = H(concat(secret, ":", data))
i.e., the digest is the MD5 of the secret concatenated with a i.e., the digest is the MD5 of the secret concatenated with a
colon concatenated with the data. The "MD5-sess" algorithm is colon concatenated with the data. The "MD5-sess" algorithm is
intended to allow efficient 3rd party authentication servers; intended to allow efficient 3rd party authentication servers;
for the difference in usage, see the description . for the difference in usage, see the description .
qop-options qop-options
This attribute is optional, but is made so only for backward This directive is optional, but is made so only for backward
compatibility with RFC 2069 [6]; it SHOULD be used by all compatibility with RFC 2069 [6]; it SHOULD be used by all
implementations compliant with this version of the Digest scheme. implementations compliant with this version of the Digest scheme.
If present, it is a quoted string of one or more tokens indicating If present, it is a quoted string of one or more tokens indicating
the "quality of protection" values supported by the server. The the "quality of protection" values supported by the server. The
value "auth" indicates authentication; the value "auth-int" indicates value "auth" indicates authentication; the value "auth-int" indicates
authentication with integrity protection; see the descriptions below authentication with integrity protection; see the descriptions below
for calculating the response attribute value for the application of for calculating the response directive value for the application of
this choice. this choice. Unrecognized options MUST be ignored.
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
3.2.2 The Authorization Request Header 3.2.2 The Authorization Request Header
The client is expected to retry the request, passing an The client is expected to retry the request, passing an
Authorization header line, which is defined according to the Authorization header line, which is defined according to the
framework above, utilized as follows. framework above, utilized as follows.
credentials = "Digest" digest-response credentials = "Digest" digest-response
digest-response = 1#( username | realm | nonce | digest-uri | digest-response = 1#( username | realm | nonce |
response | [ algorithm ] | [cnonce] | digest-uri | response | [ algorithm ] |
[opaque] | [server] | [message-qop] | [cnonce] | [opaque] | [message-qop] |
[ nonce-count ] ) [nonce-count] | [auth-param] )
username = "username" "=" username-value username = "username" "=" username-value
username-value = quoted-string username-value = quoted-string
digest-uri = "uri" "=" digest-uri-value digest-uri = "uri" "=" digest-uri-value
digest-uri-value = request-uri ; As specified by HTTP/1.1 digest-uri-value = request-uri ; As specified by HTTP/1.1
message-qop = "qop" "=" qop-value message-qop = "qop" "=" qop-value
cnonce = "cnonce" "=" cnonce-value cnonce = "cnonce" "=" cnonce-value
cnonce-value = nonce-value cnonce-value = nonce-value
nonce-count = "nc" "=" nc-value nonce-count = "nc" "=" nc-value
nc-value = 8LHEX nc-value = 8LHEX
response = "response" "=" request-digest response = "response" "=" request-digest
LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" request-digest = <"> 32LHEX <">
|"8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
The values of the opaque and algorithm fields must be those The values of the opaque and algorithm fields must be those
supplied in the WWW-Authenticate response header for the entity supplied in the WWW-Authenticate response header for the entity
being requested. being requested.
response response
A string of 32 hex digits computed as defined below, which proves A string of 32 hex digits computed as defined below, which proves
that the user knows a password that the user knows a password
username username
skipping to change at page 12, line 15 skipping to change at page 12, line 15
digest-uri digest-uri
The URI from Request-URI of the Request-Line; duplicated here because The URI from Request-URI of the Request-Line; duplicated here because
proxies are allowed to change the Request-Line in transit. proxies are allowed to change the Request-Line in transit.
qop qop
Indicates what "quality of protection" the client has applied to the Indicates what "quality of protection" the client has applied to the
message. If present, its value MUST be one of the alternatives the message. If present, its value MUST be one of the alternatives the
server indicated it supports in the WWW-Authenticate header. These server indicated it supports in the WWW-Authenticate header. These
values affect the computation of the request-digest. Note that this values affect the computation of the request-digest. Note that this
is a single token, not a quoted list of alternatives as in WWW- is a single token, not a quoted list of alternatives as in WWW-
Authenticate. This attribute is optional in order to preserve Authenticate. This directive is optional in order to preserve
backward compatibility with a minimal implementation of RFC 2069 [6], backward compatibility with a minimal implementation of RFC 2069 [6],
but SHOULD be used if the server indicated that it is supported by but SHOULD be used if the server indicated that qop is supported by
providing a qop attribute in the WWW-Authenticate header field. providing a qop directive in the WWW-Authenticate header field.
cnonce cnonce
An opaque quoted string value provided by the client and used by both This MUST be specified if a qop directive is sent (see above), and
client and server to avoid chosen plaintext attacks, to provide MUST NOT be specified if the server did not send a qop directive in
mutual authentication, and to provide some message integrity the WWW-Authenticate header field. The cnonce-value is an opaque
protection. See the descriptions below of the calculation of the quoted string value provided by the client and used by both client
response-digest and request-digest values. 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.
nonce-count nonce-count
This MUST be specified if a qop attribute is sent (see above), and 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 attribute in 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 the WWW-Authenticate header field. The nc-value is the hexadecimal
count of the number of requests (including the current request) that count of the number of requests (including the current request) that
the client has sent with the nonce value in this request. For the client has sent with the nonce value in this request. For
example, in the first request sent in response to a given nonce example, in the first request sent in response to a given nonce
value, the client sends "nc=0001". The purpose of this attribute is value, the client sends "nc=00000001". The purpose of this directive
to allow the server to detect request replays by maintaining its own is to allow the server to detect request replays by maintaining its
copy of this count - if the same nc-value is seen twice, then the 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 request is a replay. See the description below of the construction
of the request-digest value. of the request-digest value.
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
If a directive or its value is improper, or required directives
are missing, the proper response is 400 Bad Request.
The definition of request-digest above indicates the encoding for The definition of request-digest above indicates the encoding for
its value. The following definitions show how the value is its value. The following definitions show how the value is
computed. computed.
If the "algorithm" directive is not present, or its value is 3.2.2.1 Request-Digest
"MD5", then response-digest is computed as follows.
If the "qop" directive is not present (this construction is for If the "qop" directive is not present (this construction is for
compatibility with RFC 2069): compatibility with RFC 2069):
request-digest = request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
<"> <">
see below for the defintions for A1 and A2. See below for the definitions for A1 and A2.
If the "qop" value is "auth": If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value) request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value ":" nc-value
":" unq(cnonce-value) ":" unq(cnonce-value)
":" unq(qop-value) ":" unq(qop-value)
":" H(A2) ":" H(A2)
) <"> ) <">
where
passwd = < user's password > 3.2.2.2 A1
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 If the "algorithm" directive's value is "MD5" or is unspecified, then A1
is: is:
A1 = unq(username-value) ":" unq(realm-value) ":" passwd A1 = unq(username-value) ":" unq(realm-value) ":" passwd
where
passwd = < user's password >
If the "algorithm" directive's value is "MD5-sess", then A1 is If the "algorithm" directive's value is "MD5-sess", then A1 is
calculated only once - on the first request by the client calculated only once - on the first request by the client
following receipt of a WWW-Authenticate challenge from the following receipt of a WWW-Authenticate challenge from the
server. It uses the server nonce from that challenge, and the server. It uses the server nonce from that challenge, and the
first client nonce value to construct A1 as follows: first client nonce value to construct A1 as follows:
A1 = H( unq(username-value) ":" unq(realm-value) ":" A1 = H( unq(username-value) ":" unq(realm-value)
passwd ) ":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value) ":" unq(nonce-value) ":" unq(cnonce-value)
This creates a 'session key' for the authentication of subsequent This creates a 'session key' for the authentication of subsequent
requests and responses which is different for each session, thus requests and responses which is different for each session, thus
limiting the amount of material hashed with any one key. Because the limiting the amount of material hashed with any one key. Because the
server need only use the hash of the user credentials in order to create server need only use the hash of the user credentials in order to create
the A1 value, this construction could be used as part of authentication the A1 value, this construction could be used as part of authentication
using a third party service so that the web server would not need the using a third party service so that the web server would not need the
actual password value. The specification of such a protocol is beyond actual password value. The specification of such a protocol is beyond
the scope of this specification. the scope of this specification.
3.2.2.3 A2
If the "qop" directive's value is "auth" or is unspecified, then A2 is: If the "qop" directive's value is "auth" or is unspecified, then A2 is:
A2 = Method ":" digest-uri-value A2 = Method ":" digest-uri-value
If the "qop" value is "auth-int", then A2 is: If the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body) A2 = Method ":" digest-uri-value ":" H(entity-body)
Note that many of the fields, such as the "username-value" field, 3.2.2.4 Directive values and quoted-string
are defined as a "quoted-string". However, the "unq" notation
indicates that surrounding quotation marks are removed in forming Note that the value of many of the directives, such as "username-
the string A1. Thus if the Authorization header includes the value", are defined as a "quoted-string". However, the "unq"
fields notation indicates that surrounding quotation marks are removed
in forming the string A1. Thus if the Authorization header
includes the fields
username="Mufasa", realm=myhost@testrealm.com username="Mufasa", realm=myhost@testrealm.com
and the user Mufasa has password "Circle Of Life" then H(A1) and the user Mufasa has password "Circle Of Life" then H(A1)
would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no
quotation marks in the digested string. quotation marks in the digested string.
No white space is allowed in any of the strings to which the No white space is allowed in any of the strings to which the
digest function H() is applied unless that white space exists in digest function H() is applied unless that white space exists in
the quoted strings or entity body whose contents make up the the quoted strings or entity body whose contents make up the
skipping to change at page 14, line 16 skipping to change at page 14, line 24
Mufasa:myhost@testrealm.com:Circle Of Life Mufasa:myhost@testrealm.com:Circle Of Life
with no white space on either side of the colons, but with the with no white space on either side of the colons, but with the
white space between the words used in the password value. white space between the words used in the password value.
Likewise, the other strings digested by H() must not have white Likewise, the other strings digested by H() must not have white
space on either side of the colons which delimit their fields space on either side of the colons which delimit their fields
unless that white space was in the quoted strings or entity body unless that white space was in the quoted strings or entity body
being digested. being digested.
Also note that if integrity protection is applied (qop=auth-int), Also note that if integrity protection is applied (qop=auth-int), the
the H(entity-body) is the hash of the entity body, not the H(entity-body) is the hash of the entity body, not the message body - it
message body - it is computed before any transfer encoding is is computed before any transfer encoding is applied by the sender and
applied by the sender and after it has been removed by the after it has been removed by the recipient. Note that this includes
recipient. multipart boundaries and embedded headers in each part of any multipart
content-type.
The "method" value is the HTTP request method as specified in 3.2.2.5 Various considerations
section 5.1 of [2]. The "request-uri" value is the Request-URI
from the request line as specified in section 5.1 of [2]. This The "Method" value is the HTTP request method as specified in
section 5.1.1 of [2]. The "request-uri" value is the Request-URI
from the request line as specified in section 5.1.2 of [2]. This
may be "*", an "absoluteURL" or an "abs_path" as specified in may be "*", an "absoluteURL" or an "abs_path" as specified in
section 5.1.2 of [2], but it MUST agree with the Request-URI. In section 5.1.2 of [2], but it MUST agree with the Request-URI. In
particular, it MUST be an "absoluteURL" if the Request-URI is an particular, it MUST be an "absoluteURL" if the Request-URI is an
"absoluteURL". The "cnonce-value" is an optional client-chosen "absoluteURL". The "cnonce-value" is an optional client-chosen
value whose purpose is to foil chosen plaintext attacks. value whose purpose is to foil chosen plaintext attacks.
The authenticating server must assure that the document The authenticating server must assure that the document
designated by the "uri" parameter is the same as the document designated by the "uri" parameter is the same as the document
served. The purpose of duplicating information from the request served. The purpose of duplicating information from the request
URL in this field is to deal with the possibility that an URL in this field is to deal with the possibility that an
intermediate proxy may alter the client's request. This altered intermediate proxy may alter the client's request. This altered
(but presumably semantically equivalent) request would not result (but presumably semantically equivalent) request would not result
in the same digest as that calculated by the client. in the same digest as that calculated by the client.
Implementers should be aware of how authenticated transactions Implementers should be aware of how authenticated transactions
interact with shared caches. The HTTP/1.1 protocol specifies that interact with shared caches. The HTTP/1.1 protocol specifies that
when a shared cache (see section 13.10 of [2]) has received a when a shared cache (see section 13.7 of [2]) has received a
request containing an Authorization header and a response from request containing an Authorization header and a response from
relaying that request, it MUST NOT return that response as a relaying that request, it MUST NOT return that response as a
reply to any other request, unless one of two Cache-Control (see reply to any other request, unless one of two Cache-Control (see
section 14.9 of [2]) directives was present in the response. If section 14.9 of [2]) directives was present in the response. If
the original response included the "must-revalidate" Cache- the original response included the "must-revalidate" Cache-
Control directive, the cache MAY use the entity of that response Control directive, the cache MAY use the entity of that response
in replying to a subsequent request, but MUST first revalidate it in replying to a subsequent request, but MUST first revalidate it
with the origin server, using the request headers from the new with the origin server, using the request headers from the new
request to allow the origin server to authenticate the new request to allow the origin server to authenticate the new
request. Alternatively, if the original response included the request. Alternatively, if the original response included the
skipping to change at page 15, line 31 skipping to change at page 15, line 31
The server may send the Authentication-Info header with a The server may send the Authentication-Info header with a
nextnonce field as a means of implementing one-time or otherwise nextnonce field as a means of implementing one-time or otherwise
changing nonces. If the nextnonce field is present the client changing nonces. If the nextnonce field is present the client
SHOULD use it when constructing the Authorization header for its SHOULD use it when constructing the Authorization header for its
next request. Failure of the client to do so may result in a next request. Failure of the client to do so may result in a
request to re-authenticate from the server with the "stale=TRUE". request to re-authenticate from the server with the "stale=TRUE".
Server implementations should carefully consider the Server implementations should carefully consider the
performance implications of the use of this mechanism; performance implications of the use of this mechanism;
pipelined requests will not be possible if every response pipelined requests will not be possible if every response
includes a nextnonce attribute which must be used on the next includes a nextnonce directive that must be used on the next
request received by the server. Consideration should be given request received by the server. Consideration should be given
to the performance vs. security tradeoffs of allowing an old to the performance vs. security tradeoffs of allowing an old
nonce value to be used for a limited time to permit request nonce value to be used for a limited time to permit request
pipelining. pipelining. Use of
qop message-qop
Indicates the "quality of protection" options applied to the Indicates the "quality of protection" options applied to the
response by the server. The value "auth" indicates authentication; response by the server. The value "auth" indicates authentication;
the value "auth-int" indicates authentication with integrity the value "auth-int" indicates authentication with integrity
protection. The server SHOULD use the same value for the qop protection. The server SHOULD use the same value for the message-qop
directive in the response as was sent by the client in the directive in the response as was sent by the client in the
corresponding request. corresponding request.
The optional response digest in the "rspauth" directive supports The optional response digest in the "response-auth" directive
mutual authentication -- the server proves that it knows the supports mutual authentication -- the server proves that it knows
user's secret, and with qop=auth-int also provides limited the user's secret, and with qop=auth-int also provides limited
integrity protection of the response. The response-digest value integrity protection of the response. The "response-digest" value
is calculated as for the request-digest in the Authorization is calculated as for the "request-digest" in the Authorization
header, except that if "qop=auth" or is not specified in the header, except that if "qop=auth" or is not specified in the
Authorization header for the request, A2 is Authorization header for the request, A2 is
A2 = Status-Code ":" digest-uri-value A2 = ":" digest-uri-value
and if "qop=auth-int", then A2 is and if "qop=auth-int", then A2 is
A2 = Status-Code ":" digest-uri-value ":" H(entity-body) A2 = ":" digest-uri-value ":" H(entity-body)
where "Status-Code" is the status code (e.g., "200") from the where "digest-uri-value" is the value of the "uri" directive on the
"Status-Line" of the response, as defined in section 6.1 of [2], Authorization header in the request. The "cnonce-value" and "nc-value"
and "digest-uri-value" is the value of the "uri" directive on the MUST be the ones for the client request to which this message is the
Authorization header in the request. The "cnonce-value" MUST be response. The "response-auth", "cnonce", and "nonce-count" directives
one for the client request to which this message is the response. MUST BE present if "qop=auth" or "qop=auth-int" is specified.
The Authentication-Info header is allowed in the trailer of an The Authentication-Info header is allowed in the trailer of an
HTTP message transferred via chunked transfer-coding. HTTP message transferred via chunked transfer-coding.
3.3 Digest Operation 3.3 Digest Operation
Upon receiving the Authorization header, the server may check its Upon receiving the Authorization header, the server may check its
validity by looking up its known password which corresponds to validity by looking up its known password which corresponds to
the submitted username. Then, the server must perform the same the submitted username. Then, the server must perform the same
digest operation (e.g., MD5) performed by the client, and compare digest operation (e.g., MD5) performed by the client, and compare
skipping to change at page 17, line 14 skipping to change at page 17, line 8
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 authentication method, even if the server does not know that the
client supports it. A client is encouraged to fail gracefully if client supports it. A client is encouraged to fail gracefully if
the server specifies only authentication schemes it cannot the server specifies only authentication schemes it cannot
handle. handle.
3.5 Example 3.5 Example
The following example assumes that an access-protected document The following example assumes that an access-protected document
is being requested from the server. The URI of the document is is being requested from the server via a GET request. The URI of
"http://www.nowhere.org/dir/index.html". Both client and server the document is "http://www.nowhere.org/dir/index.html". Both
know that the username for this document is "Mufasa", and the client and server know that the username for this document is
password is "Circle Of Life" (with one space between each of the "Mufasa", and the password is "Circle Of Life" (with one space
three words). between each of the three words).
The first time the client requests the document, no Authorization The first time the client requests the document, no Authorization
header is sent, so the server responds with: header is sent, so the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm="testrealm@host.com", realm="testrealm@host.com",
qop="auth,auth-int", qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
The client may prompt the user for the username and password, The client may prompt the user for the username and password,
after which it will respond with a new request, including the after which it will respond with a new request, including the
following Authorization header: following Authorization header:
Authorization: Digest username="Mufasa", Authorization: Digest username="Mufasa",
realm="testrealm@host.com", realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html", uri="/dir/index.html",
qop=auth, qop=auth,
nc=0001, nc=00000001,
cnonce="0a4f113b", cnonce="0a4f113b",
response="96d2de7d9b47e2a6c0eccb6f7ef3548f", response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
3.6 Proxy-Authentication and Proxy-Authorization 3.6 Proxy-Authentication and Proxy-Authorization
The digest authentication scheme may also be used for The digest authentication scheme may also be used for
authenticating users to proxies, proxies to proxies, or proxies authenticating users to proxies, proxies to proxies, or proxies
to origin servers by use of the Proxy-Authenticate and Proxy- to origin servers by use of the Proxy-Authenticate and Proxy-
Authorization headers. These headers are instances of the general Authorization headers. These headers are instances of the Proxy-
Proxy-Authenticate and Proxy-Authorization headers specified in Authenticate and Proxy-Authorization headers specified in
sections 10.30 and 10.31 of the HTTP/1.1 specification [2] and sections 10.33 and 10.34 of the HTTP/1.1 specification [2] and
their behavior is subject to restrictions described there. The their behavior is subject to restrictions described there. The
transactions for proxy authentication are very similar to those transactions for proxy authentication are very similar to those
already described. Upon receiving a request which requires already described. Upon receiving a request which requires
authentication, the proxy/server must issue the "HTTP/1.1 401 authentication, the proxy/server must issue the "407 Proxy
Unauthorized " response with a "Proxy-Authenticate" header. The Authentication Required" response with a "Proxy-Authenticate"
digest-challenge used in the Proxy-Authenticate header is the header. The digest-challenge used in the Proxy-Authenticate
same as that for the WWW-Authenticate header as defined above in header is the same as that for the WWW-Authenticate header as
section 2.1. defined above in section 3.2.1.
The client/proxy must then re-issue the request with a Proxy- The client/proxy must then re-issue the request with a Proxy-
Authorization header, with attributes as specified for the Authorization Authorization header, with directives as specified for the Authorization
header in section TBD above. header in section 3.2.2 above.
On subsequent responses, the server sends Proxy-Authentication-Info with On subsequent responses, the server sends Proxy-Authentication-Info with
attributes the same as those for the Authentication-Info header field. directives the same as those for the Authentication-Info header field.
Note that in principle a client could be asked to authenticate Note that in principle a client could be asked to authenticate
itself to both a proxy and an end-server. It might receive an itself to both a proxy and an end-server, but never in the same
"HTTP/1.1 401 Unauthorized" header followed by both a WWW- response.
Authenticate and a Proxy-Authenticate header. However, it can
never receive more than one Proxy-Authenticate header since such
headers are only for immediate connections and must not be passed
on by proxies. If the client receives both headers, it must
respond with both the Authorization and Proxy-Authorization
headers as described above, which will likely involve different
combinations of username, password, nonce, etc.
4 Security Considerations 4 Security Considerations
4.1 Authentication of Clients using Basic Authentication 4.1 Authentication of Clients using Basic Authentication
The Basic authentication scheme is not a secure method of user The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity, which is authentication, nor does it in any way protect the entity, which is
transmitted in cleartext across the physical network used as the transmitted in cleartext across the physical network used as the
carrier. HTTP does not prevent additional authentication schemes and carrier. HTTP does not prevent additional authentication schemes and
encryption mechanisms from being employed to increase security or the encryption mechanisms from being employed to increase security or the
addition of enhancements (such as schemes to use one-time passwords) to addition of enhancements (such as schemes to use one-time passwords) to
Basic authentication. Basic authentication.
The most serious flaw in Basic authentication is that it results in the The most serious flaw in Basic authentication is that it results in the
essentially cleartext transmission of the user's password over the essentially cleartext transmission of the users password over the
physical network. It is this problem which Digest Authentication physical network. It is this problem which Digest Authentication
attempts to address. attempts to address.
Because Basic authentication involves the cleartext transmission of Because Basic authentication involves the cleartext transmission of
passwords it SHOULD NOT be used (without enhancements) to protect passwords it SHOULD NOT be used (without enhancements) to protect
sensitive or valuable information. sensitive or valuable information.
A common use of Basic authentication is for identification purposes -- A common use of Basic authentication is for identification purposes --
requiring the user to provide a user name and password as a means of requiring the user to provide a user name and password as a means of
identification, for example, for purposes of gathering accurate usage identification, for example, for purposes of gathering accurate usage
skipping to change at page 19, line 31 skipping to change at page 18, line 63
implementers SHOULD guard against the possibility of this sort of implementers SHOULD guard against the possibility of this sort of
counterfeiting by gateways or CGI scripts. In particular it is very counterfeiting by gateways or CGI scripts. In particular it is very
dangerous for a server to simply turn over a connection to a gateway. dangerous for a server to simply turn over a connection to a gateway.
That gateway can then use the persistent connection mechanism to engage That gateway can then use the persistent connection mechanism to engage
in multiple transactions with the client while impersonating the in multiple transactions with the client while impersonating the
original server in a way that is not detectable by the client. original server in a way that is not detectable by the client.
4.2 Authentication of Clients using Digest Authentication 4.2 Authentication of Clients using Digest Authentication
Digest Authentication does not provide a strong authentication Digest Authentication does not provide a strong authentication
mechanism. That is not its intent. It is intended solely to mechanism, when compared to public key based mechanisms, for
replace the much weaker and even more dangerous Basic mechanism. example. However, it is significantly stronger than (e.g.) CRAM-
MD5 which has been proposed for use with LDAP [10], POP and IMAP
(see RFC 2195 [9]). It is intended to replace the much weaker
and even more dangerous Basic mechanism.
Digest Authentication offers no confidentiality protection beyond Digest Authentication offers no confidentiality protection beyond
protecting the actual password. All of the rest of the request protecting the actual password. All of the rest of the request
and response are available to an eavesdropper. and response are available to an eavesdropper.
Digest Authentication offers only limited integrity protection Digest Authentication offers only limited integrity protection
for the messages in either direction. If qop=auth-int mechanism for the messages in either direction. If qop=auth-int mechanism
is used, those parts of the message used in the calculation of is used, those parts of the message used in the calculation of
the WWW-Authenticate and Authorization header field response the WWW-Authenticate and Authorization header field response
attribute values (see section 3.2.2) are protected. Most header directive values (see section 0) are protected. Most header
fields and their values could be modified as a part of a man-in- fields and their values could be modified as a part of a man-in-
the-middle attack. the-middle attack.
Many needs for secure HTTP transactions cannot be met by Digest Many needs for secure HTTP transactions cannot be met by Digest
Authentication. For those needs TLS or SHTTP are more appropriate Authentication. For those needs TLS or SHTTP are more appropriate
protocols. In particular Digest authentication cannot be used for protocols. In particular Digest authentication cannot be used for
any transaction requiring confidentiality protection. any transaction requiring confidentiality protection.
Nevertheless many functions remain for which Digest Nevertheless many functions remain for which Digest
authentication is both useful and appropriate (any service in authentication is both useful and appropriate (any service in
present use that uses Basic should be switched to Digest as soon present use that uses Basic should be switched to Digest as soon
as practical). as practical).
4.3 Limited Use Nonce Values 4.3 Limited Use Nonce Values
The Digest scheme uses a server-specified nonce to seed the generation The Digest scheme uses a server-specified nonce to seed the generation
of the response-digest value (as specified in section 3.2.2). As shown of the response-digest value (as specified in section 0). As shown in
in the example in 3.2.2, the server is free to construct the nonce such the example in 0, the server is free to construct the nonce such that it
that it may only be used from a particular client, for a particular may only be used from a particular client, for a particular resource,
resource, for a limited period of time or number of uses, or any other for a limited period of time or number of uses, or any other
restrictions. Doing so strengthens the protection provided against, for restrictions. Doing so strengthens the protection provided against, for
example, replay attacks (see 4.5). However, it should be noted that the example, replay attacks (see 4.5). However, it should be noted that the
method chosen for generating and checking the nonce also has performance method chosen for generating and checking the nonce also has performance
and resource implications. For example, a server may choose to allow 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 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- or not each recently issued nonce has been returned and sending a next-
nonce attribute in the Authentication-Info header field of every nonce directive in the Authentication-Info header field of every
response. This protects against even an immediate replay attack, but has response. This protects against even an immediate replay attack, but has
a high cost checking nonce values, and perhaps more important will cause a high cost checking nonce values, and perhaps more important will cause
authentication failures for any pipelined requests (presumably returning authentication failures for any pipelined requests (presumably returning
a stale nonce indication). Similarly, incorporating a request-specific a stale nonce indication). Similarly, incorporating a request-specific
element such as the Etag value for a resource limits the use of the 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 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 it may be useful to do so for methods with side effects but have
unacceptable performance for those that do not. unacceptable performance for those that do not.
4.4 Comparison of Digest with Basic Authentication 4.4 Comparison of Digest with Basic Authentication
skipping to change at page 21, line 37 skipping to change at page 20, line 61
attacker could replay valid credentials from a successful request attacker could replay valid credentials from a successful request
with counterfeit form data or other message body. Even with the with counterfeit form data or other message body. Even with the
use of integrity protection most metadata in header fields is use of integrity protection most metadata in header fields is
not protected. Proper nonce generation and checking provides some not protected. Proper nonce generation and checking provides some
protection against replay of previously used valid credentials, protection against replay of previously used valid credentials,
but see 4.8. but see 4.8.
4.6 Weakness Created by Multiple Authentication Schemes 4.6 Weakness Created by Multiple Authentication Schemes
An HTTP/1.1 server may return multiple challenges with a 401 An HTTP/1.1 server may return multiple challenges with a 401
(Authenticate) response, and each challenge may use a different scheme. (Authenticate) response, and each challenge may use a different auth-
The order of the challenges returned to the user agent is the order that scheme. A user agent MUST choose to use the strongest auth-scheme it
the server would prefer they be chosen. The server should order its understands and request credentials from the user based upon that
challenges with the "most secure" authentication scheme first. A user challenge.
agent should choose to use the first challenge it understands and
request credentials from the user based upon that challenge. 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.
When the server offers choices of authentication schemes using the WWW- When the server offers choices of authentication schemes using the WWW-
Authenticate header, the strength of the resulting authentication is Authenticate header, the strength of the resulting authentication is
only as good as that of the of the weakest of the authentication only as good as that of the of the weakest of the authentication
schemes. See section 4.8 below for discussion of particular attack schemes. See section 4.8 below for discussion of particular attack
scenarios which exploit multiple authentication schemes. Thus, the scenarios that exploit multiple authentication schemes.
ordering serves more to protect the user's credentials than the server's
information.
4.7 Online dictionary attacks 4.7 Online dictionary attacks
If the attacker can eavesdrop, then it can test any overheard If the attacker can eavesdrop, then it can test any overheard
nonce/response pairs against a list of common words. Such a list is nonce/response pairs against a list of common words. Such a list is
usually much smaller than the total number of possible passwords. The usually much smaller than the total number of possible passwords. The
cost of computing the response for each password on the list is paid cost of computing the response for each password on the list is paid
once for each challenge. once for each challenge.
This attack can be mitigated by checking the password against a This attack can be mitigated by checking the password against a
skipping to change at page 23, line 33 skipping to change at page 22, line 48
4.11 Batch brute force attacks 4.11 Batch brute force attacks
With Digest authentication, a MITM can execute a chosen plaintext With Digest authentication, a MITM can execute a chosen plaintext
attack, and can gather responses from many users to the same nonce. It 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 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 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 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 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, 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 and even a single machine can search large subsets of the password space
very quickly _ reports exist of searching all passwords with six or very quickly reports exist of searching all passwords with six or
fewer letters in a few hours. fewer letters in a few hours.
The countermeasure against this attack is to for clients to be The countermeasure against this attack is to for clients to be
configured to require the use of the optional "cnonce" directive. configured to require the use of the optional "cnonce" directive.
4.12 Spoofing by Counterfeit Servers 4.12 Spoofing by Counterfeit Servers
Basic Authentication is vulnerable to 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 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 containing information protected by a password she knows, when in fact
skipping to change at page 24, line 49 skipping to change at page 23, line 58
A range of server options is appropriate since, for example, some A range of server options is appropriate since, for example, some
implementations may be willing to accept the server overhead of one-time implementations may be willing to accept the server overhead of one-time
nonces or digests to eliminate the possibility of replay. Others may nonces or digests to eliminate the possibility of replay. Others may
satisfied with a nonce like the one recommended above restricted to a satisfied with a nonce like the one recommended above restricted to a
single IP address and a single ETag or with a limited lifetime. single IP address and a single ETag or with a limited lifetime.
The bottom line is that *any* compliant implementation will be The bottom line is that *any* compliant implementation will be
relatively weak by cryptographic standards, but *any* compliant relatively weak by cryptographic standards, but *any* compliant
implementation will be far superior to Basic Authentication. implementation will be far superior to Basic Authentication.
5 Acknowledgments 5 Sample implementation
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 section 3.5. It uses the MD5 implementation from
RFC 1321.
File "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 */
);
File "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);
};
File "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);
};
6 Acknowledgments
Eric W. Sink, of AbiSource, Inc., was one of the original authors before
the specification underwent substantial revision.
In addition to the authors, valuable discussion instrumental in creating In addition to the authors, valuable discussion instrumental in creating
this document has come from Peter J. Churchyard, Ned Freed, and David M. this document has come from Peter J. Churchyard, Ned Freed, and David M.
Kristol. Kristol.
Jim Gettys and Larry Masinter edited this document for its update. Jim Gettys and Larry Masinter edited this document for update.
6 References 7 References
[1] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer [1] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945, May 1996. Protocol -- HTTP/1.0", RFC 1945, May 1996.
[2] Fielding, R., Gettys, J., Mogul, J. C., Frysyk, H, Berners-Lee, [2] Fielding, R., Gettys, J., Mogul, J. C., Frysyk, H., Masinter, L.,
T., " Hypertext Transfer Protocol -- HTTP/1.1", Work In Progress of Leach, P., Berners-Lee, T., " Hypertext Transfer Protocol --
the HTTP working group, November 1997. HTTP/1.1", Work In Progress of the HTTP working group, July, 1998.
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[4] Freed, N., and N. Borenstein. "Multipurpose Internet Mail [4] Freed, N., and N. Borenstein. "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies." RFC Extensions (MIME) Part One: Format of Internet Message Bodies." RFC
2045, Innosoft, First Virtual, November 1996. 2045, Innosoft, First Virtual, November 1996.
[5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0," Work In [5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0," Work In
Progress of the TLS working group, November, 1997. Progress of the TLS working group, November, 1997.
skipping to change at page 25, line 36 skipping to change at page 27, line 53
Authentication." RFC 2069, January, 1997. Authentication." RFC 2069, January, 1997.
[7] Berners Lee, T, Fielding, R., Masinter, L., "Uniform Resource [7] Berners Lee, T, Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics," Work in Progress, Identifiers (URI): Generic Syntax and Semantics," Work in Progress,
November, 1997. November, 1997.
[8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", [8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
CryptoBytes, Sping 1995, RSA Inc, CryptoBytes, Sping 1995, RSA Inc,
(http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
7 Authors' Addresses [9] Klensin, J.,Catoe, R., Krumviede, P., "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", September 1997.
[10] Morgan, B., Alvestrand, H., Hodges, J., Wahl, M., "Authentication
Methods for LDAP", 07/07/1998. Work in progress, <draft-ietf-ldapext-
authmeth-02.txt>
8 Authors' Addresses
John Franks John Franks
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
EMail: john@math.nwu.edu EMail: john@math.nwu.edu
Phillip M. Hallam-Baker Phillip M. Hallam-Baker
Principal Consultant Principal Consultant
Verisign Inc. Verisign Inc.
One Alewife Center 301 Edgewater Place
Cambridge, MA 02138, USA Suite 210
Wakefield MA 01880, USA
EMail: pbaker@verisign.com EMail: pbaker@verisign.com
Jeffery L. Hostetler Jeffery L. Hostetler
Senior Software Engineer Software Craftsman
Spyglass, Inc. AbiSource, Inc.
3200 Farber Drive 6 Dunlap Court
Champaign, IL 61821, USA Savoy, IL 61874
EMail: jeff@spyglass.com EMail: jeff@AbiSource.com
Scott D. Lawrence
Agranat Systems, Inc.
1345 Main St.
Waltham, MA 02154, USA
EMail: lawrence@agranat.com
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052, USA Redmond, WA 98052, USA
EMail: paulle@microsoft.com EMail: paulle@microsoft.com
Ari Luotonen Ari Luotonen
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
EMail: luotonen@netscape.com EMail: luotonen@netscape.com
Eric W. Sink
Senior Software Engineer
Spyglass, Inc.
3200 Farber Drive
Champaign, IL 61821, USA
EMail: eric@spyglass.com
Lawrence C. Stewart Lawrence C. Stewart
Open Market, Inc. Open Market, Inc.
215 First Street 215 First Street
Cambridge, MA 02142, USA Cambridge, MA 02142, USA
EMail: stewart@OpenMarket.com EMail: stewart@OpenMarket.com
Scott D. Lawrence 9 Full Copyright Statement
Agranat Systems, Inc.
1345 Main St.
Waltham, MA 02154, USA
EMail: stewart@OpenMarket.com Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 95 change blocks. 
191 lines changed or deleted 435 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35