Network Working Group J. Franks
Request for Comments: 2617 Northwestern University
Obsoletes: 2069 P. Hallam-Baker
Category: Standards Track Verisign, Inc.
J. Hostetler
AbiSource, Inc.
S. Lawrence
Agranat Systems, Inc.
P. Leach
Microsoft Corporation
A. Luotonen
Netscape Communications Corporation
L. Stewart
Open Market, Inc.
June 1999
HTTP Authentication: Basic and Digest Access Authentication
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
"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 [5]), as the user name and
password are passed over the network as cleartext.
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 [6]. 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.
Franks, et al. Standards Track [Page 1]
RFC 2617 HTTP Authentication June 1999
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.
Table of Contents
1 Access Authentication................................ 3
1.1 Reliance on the HTTP/1.1 Specification............ 3
1.2 Access Authentication Framework................... 3
2 Basic Authentication Scheme.......................... 5
3 Digest Access Authentication Scheme.................. 6
3.1 Introduction...................................... 6
3.1.1 Purpose......................................... 6
3.1.2 Overall Operation............................... 6
3.1.3 Representation of digest values................. 7
3.1.4 Limitations..................................... 7
3.2 Specification of Digest Headers................... 7
3.2.1 The WWW-Authenticate Response Header............ 8
3.2.2 The Authorization Request Header................ 11
3.2.3 The Authentication-Info Header.................. 15
3.3 Digest Operation.................................. 17
3.4 Security Protocol Negotiation..................... 18
3.5 Example........................................... 18
3.6 Proxy-Authentication and Proxy-Authorization...... 19
4 Security Considerations.............................. 19
4.1 Authentication of Clients using Basic
Authentication.................................... 19
4.2 Authentication of Clients using Digest
Authentication.................................... 20
4.3 Limited Use Nonce Values.......................... 21
4.4 Comparison of Digest with Basic Authentication.... 22
4.5 Replay Attacks.................................... 22
4.6 Weakness Created by Multiple Authentication
Schemes........................................... 23
4.7 Online dictionary attacks......................... 23
4.8 Man in the Middle................................. 24
4.9 Chosen plaintext attacks.......................... 24
4.10 Precomputed dictionary attacks.................... 25
4.11 Batch brute force attacks......................... 25
4.12 Spoofing by Counterfeit Servers................... 25
4.13 Storing passwords................................. 26
4.14 Summary........................................... 26
5 Sample implementation................................ 27
6 Acknowledgments...................................... 31
Franks, et al. Standards Track [Page 2]
RFC 2617 HTTP Authentication June 1999
7 References........................................... 31
8 Authors' Addresses................................... 32
9 Full Copyright Statement............................. 34
1 Access Authentication
1.1 Reliance on the HTTP/1.1 Specification
This specification is a companion to the HTTP/1.1 specification [2].
It uses the augmented BNF section 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.
1.2 Access Authentication Framework
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.
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
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.
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
schemes:
realm = "realm" "=" realm-value
realm-value = quoted-string
Franks, et al. Standards Track [Page 3]
RFC 2617 HTTP Authentication June 1999
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 5.1.2
of [2]) 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.
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.
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 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.
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
Franks, et al. Standards Track [Page 4]
RFC 2617 HTTP Authentication June 1999
(possibly new) challenge applicable to the proxy for the requested
resource.
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.
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 14.8 of [2]. Both the Proxy-Authenticate and
the Proxy-Authorization header fields are hop-by-hop headers (see
section 13.5.1 of [2]).
2 Basic Authentication Scheme
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.
For Basic, the framework above is utilized as follows:
challenge = "Basic" realm
credentials = "Basic" basic-credentials
Upon receipt of an unauthorized request for a URI within the
protection space, the origin server MAY respond with a challenge like
the following:
WWW-Authenticate: Basic realm="WallyWorld"
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.
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7]
encoded string in the credentials.
basic-credentials = base64-user-pass
base64-user-pass =