draft-ietf-httpauth-digest-12.txt   draft-ietf-httpauth-digest-13.txt 
HTTPAuth R. Shekh-Yusef, Ed. HTTPAuth R. Shekh-Yusef, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Obsoletes: 2617 (if approved) D. Ahrens Obsoletes: 2617 (if approved) D. Ahrens
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: July 26, 2015 S. Bremer Expires: August 6, 2015 S. Bremer
Netzkonform Netzkonform
January 22, 2015 February 2, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-12 draft-ietf-httpauth-digest-13
Abstract Abstract
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2015. This Internet-Draft will expire on August 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4 2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Digest Access Authentication Scheme . . . . . . . . . . . . . 4 3. Digest Access Authentication Scheme . . . . . . . . . . . . . 4
3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 4 3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 4
3.2. Representation of Digest Values . . . . . . . . . . . . . 4 3.2. Representation of Digest Values . . . . . . . . . . . . . 4
3.3. The WWW-Authenticate Response Header . . . . . . . . . . 5 3.3. The WWW-Authenticate Response Header Field . . . . . . . 5
3.4. The Authorization Request Header Field . . . . . . . . . 8 3.4. The Authorization Request Header Field . . . . . . . . . 8
3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3. A2 . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.3. A2 . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.4. Username Hashing . . . . . . . . . . . . . . . . . . 11 3.4.4. Username Hashing . . . . . . . . . . . . . . . . . . 11
3.4.5. Parameter Values and Quoted-String . . . . . . . . . 11 3.4.5. Parameter Values and Quoted-String . . . . . . . . . 11
3.4.6. Various Considerations . . . . . . . . . . . . . . . 12 3.4.6. Various Considerations . . . . . . . . . . . . . . . 12
3.5. The Authentication-Info and Proxy-Authentication-Info 3.5. The Authentication-Info and Proxy-Authentication-Info
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 13 Header Fields . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Digest Usage of Authentication-Info . . . . . . . . . 13 3.6. Digest Operation . . . . . . . . . . . . . . . . . . . . 14
3.6. Digest Operation . . . . . . . . . . . . . . . . . . . . 15 3.7. Security Protocol Negotiation . . . . . . . . . . . . . . 15
3.7. Security Protocol Negotiation . . . . . . . . . . . . . . 16 3.8. Proxy-Authenticate and Proxy-Authorization . . . . . . . 16
3.8. Proxy-Authenticate and Proxy-Authorization . . . . . . . 17
3.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 3.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
3.9.1. Example with SHA-256 and MD5 . . . . . . . . . . . . 17 3.9.1. Example with SHA-256 and MD5 . . . . . . . . . . . . 17
3.9.2. Example with SHA-512-256, Charset, and Userhash . . . 19 3.9.2. Example with SHA-512-256, Charset, and Userhash . . . 18
4. Internationalization . . . . . . . . . . . . . . . . . . . . 20
4. Internationalization Considerations . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Storing passwords . . . . . . . . . . . . . . . . . . . . 21 5.2. Storing passwords . . . . . . . . . . . . . . . . . . . . 20
5.3. Authentication of Clients using Digest Authentication . . 21 5.3. Authentication of Clients using Digest Authentication . . 21
5.4. Limited Use Nonce Values . . . . . . . . . . . . . . . . 22 5.4. Limited Use Nonce Values . . . . . . . . . . . . . . . . 21
5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23 5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
5.6. Weakness Created by Multiple Authentication Schemes . . . 23 5.6. Weakness Created by Multiple Authentication Schemes . . . 23
5.7. Online dictionary attacks . . . . . . . . . . . . . . . . 24 5.7. Online dictionary attacks . . . . . . . . . . . . . . . . 23
5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24 5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 23
5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25 5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 24
5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25 5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 24
5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25 5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25
5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. HTTP Digest Hash Algorithms Registry . . . . . . . . . . 26 6.1. HTTP Digest Hash Algorithms Registry . . . . . . . . . . 26
6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27 6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 26
6.3. Authentication-Info and Proxy-Authentication-Info Headers 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
Registration . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
The details of the challenge-response authentication mechanism are The details of the challenge-response authentication mechanism are
skipping to change at page 4, line 37 skipping to change at page 4, line 34
HTTP method, and the requested URI. In this way, the password is HTTP method, and the requested URI. In this way, the password is
never sent in the clear, and the username can be hashed, depending on never sent in the clear, and the username can be hashed, depending on
the indication received from the server. The username and password the indication received from the server. The username and password
must be prearranged in some fashion not addressed by this document. must be prearranged in some fashion not addressed by this document.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters, such as client and randomness of the randomly chosen parameters, such as client and
server nonces. These should be generated by a strong random or server nonces. These should be generated by a strong random or
properly seeded pseudorandom source (see [RFC4086]). properly seeded pseudorandom source (see [RFC4086]).
For the following parameters, the value can be encoded using
[RFC5987] encoding: username.
3.2. Representation of Digest Values 3.2. Representation of Digest Values
An optional header field allows the server to specify the algorithm An optional header field allows the server to specify the algorithm
used to create the checksum or digest. This documents adds SHA-256 used to create the checksum or digest. This documents adds SHA-256
and SHA-512/256 algorithms. To maintain backwards compatibility with and SHA-512/256 algorithms. To maintain backwards compatibility with
[RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED. [RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED.
The size of the digest depends on the algorithm used. The bits in The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least the digest are converted from the most significant to the least
significant bit, four bits at a time to the ASCII representation as significant bit, four bits at a time to the ASCII representation as
follows. Each four bits is represented by its familiar hexadecimal follows. Each four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef, that is binary 0000 is notation from the characters 0123456789abcdef, that is binary 0000 is
represented by the character '0', 0001 by '1' and so on up to the represented by the character '0', 0001 by '1' and so on up to the
representation of 1111 as 'f'. If the MD5 algorithm is used to representation of 1111 as 'f'. If the MD5 algorithm is used to
calculate the digest, then the MD5 digest will be represented as 32 calculate the digest, then the MD5 digest will be represented as 32
hexadecimal characters, while SHA-256 and SHA-512/256 are represented hexadecimal characters, while SHA-256 and SHA-512/256 are represented
as 64 hexadecimal characters. as 64 hexadecimal characters.
3.3. The WWW-Authenticate Response Header 3.3. The WWW-Authenticate Response Header Field
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 field is not sent, the server acceptable Authorization header field is not sent, the server
responds with a "401 Unauthorized" status code and a WWW-Authenticate responds with a "401 Unauthorized" status code and a WWW-Authenticate
header field with Digest scheme as per the framework defined above. header field with Digest scheme as per the framework defined above.
The value of the header field can include parameters from the The value of the header field can include parameters from the
following list: following list:
realm realm
skipping to change at page 5, line 31 skipping to change at page 5, line 27
password to use. This string should contain at least the name of password to use. This string should contain at least the name of
the host performing the authentication and might additionally the host performing the authentication and might additionally
indicate the collection of users who might have access. An indicate the collection of users who might have access. An
example might be "registered_users@gotham.news.com". (See example might be "registered_users@gotham.news.com". (See
Section 2.2 of [RFC7235] for more details). Section 2.2 of [RFC7235] for more details).
domain domain
A quoted, space-separated list of URIs, as specified in [RFC3986], A quoted, space-separated list of URIs, as specified in [RFC3986],
that define the protection space. If a URI is an abs_path, it is that define the protection space. If a URI is an abs_path, it is
relative to the canonical root URL (See Section 2.2 of [RFC7235]) relative to the canonical root URL (See Section 2.2 of [RFC7235]).
of the web-origin [RFC6454]. An absolute-URI in this list may An absolute-URI in this list may refer to a different server than
refer to a different server than the web-origin. The client can the web-origin [RFC6454]. The client can use this list to
use this list to determine the set of URIs for which the same determine the set of URIs for which the same authentication
authentication information may be sent: any URI that has a URI in information may be sent: any URI that has a URI in this list as a
this list as a prefix (after both have been made absolute) MAY be prefix (after both have been made absolute) MAY be assumed to be
assumed to be in the same protection space. If this parameter is in the same protection space. If this parameter is omitted or its
omitted or its value is empty, the client SHOULD assume that the value is empty, the client SHOULD assume that the protection space
protection space consists of all URIs on the web-origin. All URIs consists of all URIs on the web-origin.
in this list SHOULD use the same scheme (https or http); mixing
them is a bad idea.
This parameter is not meaningful in Proxy-Authenticate header This parameter is not meaningful in Proxy-Authenticate header
fields, for which the protection space is always the entire proxy; fields, for which the protection space is always the entire proxy;
if present it MUST be ignored. if present it MUST be ignored.
nonce nonce
A server-specified data string which should be uniquely generated A server-specified data string which should be uniquely generated
each time a 401 response is made. It is advised that this string each time a 401 response is made. It is advised that this string
be base64 or hexadecimal data. Specifically, since the string is be base64 or hexadecimal data. Specifically, since the string is
skipping to change at page 8, line 47 skipping to change at page 8, line 40
The request can include parameters from the following list: The request can include parameters from the following list:
response response
A string of the hex digits computed as defined below, which proves A string of the hex digits computed as defined below, which proves
that the user knows a password. that the user knows a password.
username username
The user's name in the specified realm. The user's name in the specified realm. If the username contains
characters not allowed inside the ABNF token or quoted-string
forms, it can be sent in a "username*" parameter instead, using
the encoding defined in [RFC5987]. Sending both "username" and
"username*" MUST be treated as error.
uri uri
The Effective Request URI [RFC7230] from request-target of the
Request-Line; duplicated here because proxies are allowed to The Effective Request URI (Section 5.5 of [RFC7230]) of the HTTP
change the Request-Line in transit. request; duplicated here because proxies are allowed to change the
request target ("request-target", Section 3.1.1 of [RFC7230]) in
transit.
qop qop
Indicates what "quality of protection" the client has applied to Indicates what "quality of protection" the client has applied to
the message. Its value MUST be one of the alternatives the server the message. Its value MUST be one of the alternatives the server
indicated it supports in the WWW-Authenticate header field. These indicated it supports in the WWW-Authenticate header field. These
values affect the computation of the response. Note that this is values affect the computation of the response. Note that this is
a single token, not a quoted list of alternatives as in WWW- a single token, not a quoted list of alternatives as in WWW-
Authenticate. Authenticate.
skipping to change at page 13, line 9 skipping to change at page 13, line 6
Request-Line; if they are not, the server SHOULD return a 400 Bad Request-Line; if they are not, the server SHOULD return a 400 Bad
Request error. (Since this may be a symptom of an attack, server Request error. (Since this may be a symptom of an attack, server
implementers may want to consider logging such errors.) The purpose implementers may want to consider logging such errors.) The purpose
of duplicating information from the request URL in this field is to of duplicating information from the request URL in this field is to
deal with the possibility that an intermediate proxy may alter the deal with the possibility that an intermediate proxy may alter the
client's Request-Line. This altered (but presumably semantically client's Request-Line. This altered (but presumably semantically
equivalent) request would not result in the same digest as that equivalent) request would not result in the same digest as that
calculated by the client. calculated by the client.
Implementers should be aware of how authenticated transactions need Implementers should be aware of how authenticated transactions need
to interact with shared caches. The HTTP protocol specifies that to interact with shared caches (see [RFC7234]).
when a shared cache (see [RFC7234]) has received a request containing
an Authorization header field and a response from relaying that
request, it MUST NOT return that response as a reply to any other
request, unless one of two Cache-Control (see Section 3.2 of
[RFC7234]) directive was present in the response. If the original
response included the "must-revalidate" Cache-Control directive, the
cache MAY use the entity of that response in replying to a subsequent
request, but MUST first revalidate it with the origin server, using
the request header fields from the new request to allow the origin
server to authenticate the new request. Alternatively, if the
original response included the "public" Cache-Control directive, the
response entity MAY be returned in reply to any subsequent request.
3.5. The Authentication-Info and Proxy-Authentication-Info Headers 3.5. The Authentication-Info and Proxy-Authentication-Info Header
Fields
The Authentication-Info header field and the Proxy-Authentication- The Authentication-Info header field and the Proxy-Authentication-
Info header field are generic fields that MAY be used by a server to Info header field [AUTHINFO] are generic fields that MAY be used by a
communicate some information regarding the successful authentication server to communicate some information regarding the successful
of a client response. The following is the syntax of the headers: authentication of a client response.
Authentication-Info = auth-info
auth-info = #auth-param
Proxy-Authentication-Info = proxy-auth-info
proxy-auth-info = #auth-param
The auth-param is defined in [RFC7235].
3.5.1. Digest Usage of Authentication-Info
The Digest authentication scheme MAY add the Authentication-Info The Digest authentication scheme MAY add the Authentication-Info
header field in the confirmation request and include parameters from header field in the confirmation request and include parameters from
the following list: the following list:
nextnonce nextnonce
The value of the nextnonce parameter is the nonce the server The value of the nextnonce parameter is the nonce the server
wishes the client to use for a future authentication response. wishes the client to use for a future authentication response.
The server MAY send the Authentication-Info header field with a The server MAY send the Authentication-Info header field with a
skipping to change at page 16, line 4 skipping to change at page 15, line 28
Because the client is REQUIRED to return the value of the opaque Because the client is REQUIRED to return the value of the opaque
parameter given to it by the server for the duration of a session, parameter given to it by the server for the duration of a session,
the opaque data can be used to transport authentication session state the opaque data can be used to transport authentication session state
information. (Note that any such use can also be accomplished more information. (Note that any such use can also be accomplished more
easily and safely by including the state in the nonce.) For example, easily and safely by including the state in the nonce.) For example,
a server could be responsible for authenticating content that a server could be responsible for authenticating content that
actually sits on another server. It would achieve this by having the actually sits on another server. It would achieve this by having the
first 401 response include a domain parameter whose value includes a first 401 response include a domain parameter whose value includes a
URI on the second server, and an opaque parameter whose value URI on the second server, and an opaque parameter whose value
contains the state information. The client will retry the request, contains the state information. The client will retry the request,
at which time the server might respond with "HTTP Redirection at which time the server might respond with "HTTP Redirection"
(Section 6.4 of [RFC7231]), pointing to the URI on the second server. (Section 6.4 of [RFC7231]), pointing to the URI on the second server.
The client will follow the redirection, and pass an Authorization The client will follow the redirection, and pass an Authorization
header field, including the <opaque> data. header field, including the <opaque> data.
Proxies MUST be completely transparent in the Digest access Proxies MUST be completely transparent in the Digest access
authentication scheme. That is, they MUST forward the WWW- authentication scheme. That is, they MUST forward the WWW-
Authenticate, Authentication-Info and Authorization header fields Authenticate, Authentication-Info and Authorization header fields
untouched. If a proxy wants to authenticate a client before a untouched. If a proxy wants to authenticate a client before a
request is forwarded to the server, it can be done using the Proxy- request is forwarded to the server, it can be done using the Proxy-
Authenticate and Proxy-Authorization header fields described in Authenticate and Proxy-Authorization header fields described in
skipping to change at page 16, line 44 skipping to change at page 16, line 22
algorithm. algorithm.
This specification defines the following algorithms: This specification defines the following algorithms:
o SHA2-256 (mandatory to implement) o SHA2-256 (mandatory to implement)
o SHA2-512/256 (as a backup algorithm) o SHA2-512/256 (as a backup algorithm)
o MD5 (for backward compatibility). o MD5 (for backward compatibility).
When the client receives the first challenge it SHOULD use the When the client receives the first challenge it SHOULD use the first
topmost header field that it supports, unless a local policy dictates challenge it supports, unless a local policy dictates otherwise.
otherwise. The client MUST ignore any challenge it does not
understand.
3.8. Proxy-Authenticate and Proxy-Authorization 3.8. Proxy-Authenticate and Proxy-Authorization
The digest authentication scheme can also be used for authenticating The digest authentication scheme can also be used for authenticating
users to proxies, proxies to proxies, or proxies to origin servers by users to proxies, proxies to proxies, or proxies to origin servers by
use of the Proxy-Authenticate and Proxy-Authorization header fields. use of the Proxy-Authenticate and Proxy-Authorization header fields.
These header fields are instances of the Proxy-Authenticate and These header fields are instances of the Proxy-Authenticate and
Proxy-Authorization header fields specified in Sections 4.2 and 4.3 Proxy-Authorization header fields specified in Sections 4.2 and 4.3
of the HTTP/1.1 specification [RFC7235] and their behavior is subject of the HTTP/1.1 specification [RFC7235] and their behavior is subject
to restrictions described there. The transactions for proxy to restrictions described there. The transactions for proxy
skipping to change at page 19, line 12 skipping to change at page 18, line 24
6794697cf8db5856cb6c1", 6794697cf8db5856cb6c1",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
3.9.2. Example with SHA-512-256, Charset, and Userhash 3.9.2. Example with SHA-512-256, Charset, and Userhash
The following example assumes that an access protected document is The following example assumes that an access protected document is
being requested from the server via a GET request. The URI for the being requested from the server via a GET request. The URI for the
request is "http://api.example.org/doe.json". Both client and server request is "http://api.example.org/doe.json". Both client and server
know the userhash of the username, support the UTF-8 character know the userhash of the username, support the UTF-8 character
encoding scheme, and use the SHA-512-256 algorithm. The username for encoding scheme, and use the SHA-512-256 algorithm. The username for
the request is a variation of "Jason Doe" and has the byte sequence the request is a variation of "Jason Doe", where the the 'a' actually
4A C3 A4 73 C3 B8 6E 20 44 6F 65. The password is "Secret, or not?". is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERES"),
and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O
WITH STROKE"), leading to the octet sequence using the UTF-8 encoding
scheme:
J U+00E4 s U+00F8 n D o e
4A C3A4 73 C3B8 6E 20 44 6F 65
The password is "Secret, or not?".
The first time the client requests the document, no Authorization The first time the client requests the document, no Authorization
header field is sent, so the server responds with: header field is sent, so the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm="api@example.org", realm="api@example.org",
qop=auth, qop=auth,
algorithm=SHA-512-256, algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
skipping to change at page 20, line 19 skipping to change at page 19, line 37
algorithm=SHA-512-256, algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001, nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth, qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6 response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6
c861229025f607a79dd", c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false userhash=false
4. Internationalization 4. Internationalization Considerations
In challenges, servers SHOULD use the "charset" authentication In challenges, servers SHOULD use the "charset" authentication
parameter (case-insensitive) to express the character encoding they parameter (case-insensitive) to express the character encoding they
expect the user agent to use when generating A1 (see Section 3.4.2) expect the user agent to use when generating A1 (see Section 3.4.2)
and username hashing (see Section 3.4.4). and username hashing (see Section 3.4.4).
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3). It indicates that the server expects (see [RFC2978], Section 2.3). It indicates that the server expects
user name and password to be converted to Unicode Normalization Form user name and password to be converted to Unicode Normalization Form
C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
skipping to change at page 20, line 42 skipping to change at page 20, line 11
For the username, recipients MUST support all characters defined in For the username, recipients MUST support all characters defined in
the "UsernameCasePreserved" profile defined in in Section 3.3 of the "UsernameCasePreserved" profile defined in in Section 3.3 of
[PRECIS], with the exception of the colon (":") character. [PRECIS], with the exception of the colon (":") character.
For the password, recipients MUST support all characters defined in For the password, recipients MUST support all characters defined in
the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. the "OpaqueString" profile defined in in Section 4.2 of [PRECIS].
If the user agent does not support the encoding indicated by the If the user agent does not support the encoding indicated by the
server, it can fail the request. server, it can fail the request.
When usernames can not be sent hashed and include non-ASCII
characters, clients can include the "username*" parameter instead
(using the value encoding defined in [RFC5987]).
5. Security Considerations 5. Security Considerations
5.1. Limitations 5.1. Limitations
HTTP Digest authentication, when used with human-memorable passwords, HTTP Digest authentication, when used with human-memorable passwords,
is vulnerable to dictionary attacks. Such attacks are much easier is vulnerable to dictionary attacks. Such attacks are much easier
than cryptographic attacks on any widely used algorithm, including than cryptographic attacks on any widely used algorithm, including
those that are no longer considered secure. In other words, those that are no longer considered secure. In other words,
algorithm agility does not make this usage any more secure. algorithm agility does not make this usage any more secure.
skipping to change at page 27, line 27 skipping to change at page 27, line 5
6.2. Digest Scheme Registration 6.2. Digest Scheme Registration
This specification registers the Digest scheme with the This specification registers the Digest scheme with the
Authentication Scheme Registry. Authentication Scheme Registry.
Authentication Scheme Name: Digest Authentication Scheme Name: Digest
Pointer to specification text: this specification Pointer to specification text: this specification
6.3. Authentication-Info and Proxy-Authentication-Info Headers
Registration
This specification registers the Authentication-Info and the Proxy-
Authentication-Info Header fields with the Message Header Field
Registry.
Header Field Name: Authentication-Info
Protocol: http
Status: standard
Reference: RFCXXXX, Section 3.5
Header Field Name: Proxy-Authentication-Info
Protocol: http
Status: standard
Reference: RFCXXXX, Section 3.5
7. Acknowledgments 7. Acknowledgments
The authors of this document would like to thank the authors of The authors of this document would like to thank the authors of
[RFC2617], as this document heavily borrows text from their document [RFC2617], as this document heavily borrows text from their document
to provide a complete description of the digest scheme and its to provide a complete description of the digest scheme and its
operations. operations.
Special thanks to Julian Reschke for his reviews, comments, Special thanks to Julian Reschke for his many reviews, comments,
suggestions, and text provided to various areas in this document. suggestions, and text provided to various areas in this document.
The authors would like to thank Stephen Farrell, Yoav Nir, Phillip The authors would like to thank Stephen Farrell, Yoav Nir, Phillip
Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner, Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner,
Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter
Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach, Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach,
Ilari Liusvaara, and Gary Mort, Alexey Melnikov, and Benjamin Kaduk Ilari Liusvaara, and Gary Mort, Alexey Melnikov, and Benjamin Kaduk
for their careful review and comments. for their careful review and comments.
The authors would like to thank Jonathan Stoke, Nico Williams, Harry The authors would like to thank Jonathan Stoke, Nico Williams, Harry
Halpin, and Phil Hunt for their comments on the mailing list when Halpin, and Phil Hunt for their comments on the mailing list when
discussing various aspects of this document. discussing various aspects of this document.
The authors would like to thank Paul Kyzivat and Dale Worley for The authors would like to thank Paul Kyzivat and Dale Worley for
their careful review and feedback on some aspects of this document. their careful review and feedback on some aspects of this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[AUTHINFO]
Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy-Authentication-Info Response
Header Fields", draft-ietf-httpbis-auth-info-00 (work in
progress), January 2015.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation, [PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis- Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-12 (work in progress), December 2014. saslprepbis-12 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
 End of changes. 29 change blocks. 
106 lines changed or deleted 77 lines changed or added

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