draft-ietf-httpauth-digest-update-01.txt   draft-ietf-httpauth-digest-update-02.txt 
HTTPAuth Working Group R. Shekh-Yusef HTTPAuth Working Group R. Shekh-Yusef
Internet-Draft D. Ahrens Internet-Draft D. Ahrens
Updates: 2617 (if approved) Avaya Updates: 2617 (if approved) Avaya
Intended Status: Standards Track June 22, 2013 Intended Status: Standards Track June 30, 2013
Expires: December 24, 2013 Expires: January 1, 2014
HTTP Digest Update HTTP Digest Update
draft-ietf-httpauth-digest-update-01 draft-ietf-httpauth-digest-update-02
Abstract Abstract
This documents specifies extensions to the HTTP Digest Authentication This documents specifies extensions to the HTTP Digest Authentication
mechanism to add support for new digest algorithms to the HTTP Digest mechanism to add support for new digest algorithms to the HTTP Digest
Access Authentication scheme. Access Authentication scheme.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 15 skipping to change at page 2, line 15
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3
2.1.1 Representation of digest values . . . . . . . . . . . . 3 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Representation of digest values . . . . . . . . . . . . 3
2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 3.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 3.2 Specification of Digest Headers . . . . . . . . . . . . . . 4
2.2.2 The Authorization Request Header . . . . . . . . . . . . 5 3.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4
2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 The Authorization Request Header . . . . . . . . . . . . 5
2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 3.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Informative References . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
1 Introduction 1 Introduction
This document specifies extensions to the HTTP Digest Access This document specifies extensions to the HTTP Digest Access
Authentication scheme by adding support for the SHA1 and SHA2 suite Authentication scheme by adding support for SHA2-256 [FIPS 186-3] and
of hash algorithms [FIPS186-3]. RFC2617 specifies the MD5 algorithm SHA3-256 hash algorithms. RFC2617 specifies the MD5 algorithm as the
as the default hash algorithm used in the digest access default hash algorithm used in the digest access authentication
authentication scheme. Since RFC2617 was first proposed, the MD5 scheme. Since RFC2617 was first proposed, the MD5 algorithm has been
algorithm has been broken. In 2008 the US-CERT issued a note that broken. In 2008 the US-CERT issued a note that MD5 "should be
MD5 "should be considered cryptographically broken and unsuitable for considered cryptographically broken and unsuitable for further use"
further use" [CERT-VU]. [CERT-VU].
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
2 Digest Access Authentication Scheme 2 Syntax Convention
In the interest of clarity and readability, the extended parameters,
and the headers and parameters in the examples in this document might
be broken into multiple lines. Any line that is indented in this
document is a continuation of the preceding line.
3 Digest Access Authentication Scheme
The Digest Access Authentication scheme is based on a simple The Digest Access Authentication scheme is based on a simple
challenge-response paradigm. The Digest scheme challenges using a challenge-response paradigm. The Digest scheme challenges using a
nonce value. A valid response contains a checksum of the username, nonce value. A valid response contains a checksum of the username,
the password, the given nonce value and the requested URI. In this the password, the given nonce value and the requested URI. In this
way the password is never sent in the clear. way the password is never sent in the clear.
2.1 Introduction 3.1 Introduction
2.1.1 Representation of digest values 3.1.1 Representation of digest values
An optional header allows the server to specify the algorithm used to An optional header allows the server to specify the algorithm used to
create the checksum or digest. By default and to maintain backwards create the checksum or digest. By default the SHA2-256 algorithm is
compatibility, the MD5 algorithm is used. used, with SHA3-256 being used as a backup algorithm. To maintain
backwards compatibility, 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 digest will be represented as 32 calculate the digest, then the digest will be represented as 32
hexadecimal characters, SHA1 by 40 hexadecimal characters, SHA2-224 hexadecimal characters, SHA2-256 and SHA3-256 by 64 hexadecimal
by 56 hexadecimal characters, SHA2-256 by 64 hexadecimal characters, characters.
SHA2-384 by 96 hexadecimal characters, and SHA2-512 by 128
hexadecimal characters.
2.1.2 Limitations 3.1.2 Limitations
The Digest authentication scheme suffers from many known limitations The Digest authentication scheme suffers from many known limitations
as specified in RFC2617, section 3.1.4. The update in this document as specified in RFC2617, section 3.1.4. The update in this document
does not address those limitations. does not address those limitations.
2.2 Specification of Digest Headers HTTP Digest authentication, when used with human-memorable passwords,
is vulnerable to dictionary attacks. Such attacks are much easier
than cryptographic attacks on any widely used algorithm, including
those that are no longer considered secure. In other words, algorithm
agility does not make this usage any more secure.
As a result, Digest authentication SHOULD be used only with passwords
that have a reasonable amount of entropy, e.g. 128-bit or more. Such
passwords typically cannot be memorized by humans but can be used for
automated web services.
It is recommended that Digest authentication be used over a secure
channel like HTTPS.
3.2 Specification of Digest Headers
The modifications to the formats of the WWW-Authenticate Header line The modifications to the formats of the WWW-Authenticate Header line
and the Authorization header line are specified below. and the Authorization header line are specified below.
2.2.1 The WWW-Authenticate Response Header 3.2.1 The WWW-Authenticate Response Header
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 acceptable Authorization header is not sent, the server responds with
a "401 Unauthorized" status code, and a WWW-Authenticate header. The a "401 Unauthorized" status code, and a WWW-Authenticate header. The
server MAY include multiple WWW-Authenticate headers to allow the server MAY include multiple WWW-Authenticate headers to allow the
server to utilize the best available algorithm supported by the server to utilize the best available algorithm supported by the
client. client.
The algorithm directive is extended as follows: The algorithm directive is extended as follows:
algorithm = "algorithm" "=" ("MD5" | "MD5-sess" | algorithm = "algorithm" "=" ("MD5" | "MD5-sess" |
"SHA1" | "SHA1-sess" | "SHA2" | "SHA2-sess" |
"SHA224" | "SHA224-sess" | "SHA3" | "SHA3-sess" |
"SHA256" | "SHA256-sess" |
"SHA384" | "SHA384-sess" |
"SHA512" | "SHA512-sess" |
token) token)
Algorithm Algorithm
A string indicating a pair of algorithms used to produce the A string indicating a pair of algorithms used to produce the
digest and a checksum. If the algorithm parameter is not present digest and a checksum. If the algorithm parameter is not present
it is assumed to be "MD5" to maintain backwards compatibility it is assumed to be "MD5" to maintain backwards compatibility
with existing implementations. If the algorithm is not with existing implementations. If the algorithm is not
understood, the challenge should be ignored and a different understood, the challenge should be ignored and a different
challenge used if there is more than one. challenge used if there is more than one.
The string obtained by applying the digest algorithm to the data The string obtained by applying the digest algorithm to the data
"data" with "secret" will be denoted KD(secret, data) and the "data" with "secret" will be denoted KD(secret, data) and the
string obtained by applying the checksum algorithm to the data string obtained by applying the checksum algorithm to the data
"data" will be denoted H(data). The notation unq(x) means the "data" will be denoted H(data). The notation unq(x) means the
value of the quoted string X without the surrounding quotes. 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)
For the "SHA1" and "SHA1-sess" algorithms For the "SHA2" and "SHA2-sess" algorithms
H(data) = SHA1(data) H(data) = SHA2-256(data)
For the "SHA224" and "SHA224-sess" algorithms
H(data) = SHA224(data)
For the "SHA256" and "SHA256-sess" algorithms
H(data) = SHA256(data)
For the "SHA384" and "SHA384-sess" algorithms
H(data) = SHA384(data)
For the "SHA512" and "SHA512-sess" algorithms For the "SHA3" and "SHA3-sess" algorithms
H(data) = SHA512(data) H(data) = SHA3-256(data)
and and
KD(secret, data) = H(concat(secret, ":", data)) KD(secret, data) = H(concat(secret, ":", data))
i.e the digest is the hash of the secret concatenated with a i.e the digest is the hash of the secret concatenated with a
colon concatenated with the data. The " -sess" algorithm is colon concatenated with the data. The " -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 in section for the difference in usage see the description in section
RFC2617, Section 3.2.2.2. RFC2617, Section 3.2.2.2.
2.2.2 The Authorization Request Header 3.2.2 The Authorization Request Header
The client is expected to retry the request, passing an Authorization The client is expected to retry the request, passing an Authorization
Request Header line. The Authorization Request Header line is Request Header line. The Authorization Request Header line is
modified as follows: modified as follows:
request-digest = <"> digest-size LHEX <"> request-digest = <"> digest-size LHEX <">
digest-size = "32" | "40" | "56" | "64" | "96" | "128" digest-size = "32" | "64"
The values of the opaque and algorithm fields must match those The values of the opaque and algorithm fields must match those
supplied in the WWW-Authenticate response header for the entity being supplied in the WWW-Authenticate response header for the entity being
requested. requested.
response response
A string of hex digits as defined in RFC2617 which proves A string of hex digits as defined in RFC2617 which proves
that the user knows a password. that the user knows a password.
2.3 Digest Operation 3.3 Digest Operation
The modifications specified in this document does not introduce any The modifications specified in this document does not introduce any
change to the digest operation specified in RFC2617. change to the digest operation specified in RFC2617.
2.4 Security Protocol Operation 3.4 Security Protocol Operation
When a server receives a request to access a resource, the server When a server receives a request to access a resource, the server
might challenge the client by responding with "401 Unauthorized" might challenge the client by responding with "401 Unauthorized"
status code, and include one or more WWW-Authenticate headers. If the status code, and include one or more WWW-Authenticate headers. If the
server challenges with multiple Digest headers, then each one of server challenges with multiple Digest headers, then each one of
these headers MUST use a different digest algorithm. The server MUST these headers MUST use a different digest algorithm. The server MUST
add these Digest headers to the response in order of preference, add these Digest headers to the response in order of preference,
starting with the most preferred header, followed by the less starting with the most preferred header, followed by the less
preferred headers. preferred headers.
This specification defines the following preference list, starting
with the most preferred algorithm:
* SHA2-256 as the default algorithm.
* SHA3-256 as a backup algorithm.
* MD5 for backward compatibility.
When the client receives the response it SHOULD use the topmost When the client receives the response it SHOULD use the topmost
header that it supports, unless a local policy dictates otherwise. header that it supports, unless a local policy dictates otherwise.
The client should ignore any challenge it does not understand. The client should ignore any challenge it does not understand.
2.5 Example 3.5 Example
The following example is borrowed from RFC2617 and assumes that an The following example is borrowed from RFC2617 and assumes that an
access protected document is being requested from the server via a access protected document is being requested from the server via a
GET request. The URI of the document is GET request. The URI of the document is
http://www.nowhere.org/dir/index.html". Both client and server know http://www.nowhere.org/dir/index.html". Both client and server know
that the username for this document is "Mufasa" and the password is that the username for this document is "Mufasa" and the password is
"Circle of Life" ( with one space between each of the three words). "Circle of Life" ( with one space 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"
qop="auth, auth-int",
algorithm="SHA2"
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
WWW-Authenticate: Digest
realm = "testrealm@host.com", realm = "testrealm@host.com",
qop="auth, auth-int", qop="auth, auth-int",
algorithm="SHA1", algorithm="SHA3",
nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque=5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm="testrealm@host.com", realm="testrealm@host.com",
qop="auth, auth-int", qop="auth, auth-int",
algorithm="MD5", algorithm="MD5",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40ef41" opaque="5ccc069c403ebaf9f0171e9517f40ef41"
The client may prompt the user for their username and password, after The client may prompt the user for their username and password, after
which it will respond with a new request, including the following which it will respond with a new request, including the following
Authorization header: Authorization header if the client chooses MD5 digest:
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",
algorithm="MD5" algorithm="MD5"
nc=00000001, nc=00000001,
cnonce="0a4f113b", cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
3 Security Considerations If the client chooses to use the SHA2-256 algorithm for calculating
the response, the client responds with a new request including the
following Authorization header:
Authorization:Digest username="Mufasa",
realm="testrealm@host.com"
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop="auth"
algorithm="SHA2"
nc=00000001
cnonce="0a4f113b",
response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93
a59b630c13dfe0a5dc6e38b",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
4 Security Considerations
This specification updates the Digest Access Authentication scheme This specification updates the Digest Access Authentication scheme
specified in RFC2617 to add support for the SHA1 and SHA2 algorithm specified in RFC2617 to add support for the SHA2-256 and SHA3-256
suites. Support for these additional hash algorithms does not alter hash algorithms. Support for these additional hash algorithms does
the security properties of the Digest Access Authentication scheme. not alter the security properties of the Digest Access Authentication
scheme.
4 Acknowledgments 5 Acknowledgments
The authors would like to thank Geoff Baskwill and Eric Cooper for The authors would like to thank Geoff Baskwill and Eric Cooper for
their careful review and comments on the pre published version of their careful review and comments on the pre published version of
this document. this document.
The authors would also like to thank Stephen Farrell, Yoav Nir, The authors would also like to thank Stephen Farrell, Yoav Nir,
Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and
Sean Turner for their careful review and comments on and off the Sean Turner for their careful review and comments on and off the
mailing list. mailing list.
5 References Special thanks to Yaron Sheffer for his thorough review, comments on
and off the list, and for the text he provided for the limitation
section.
5.1 Normative References 6 References
6.1 Normative References
[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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
5.2 Informative References 6.2 Informative References
[FIPS186-3] National Institute of Standards and Technology (NIST), [FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard, June 2009. FIPS Publication 186-3: Digital Signature Standard, June 2009.
[CERT-VU] Vulnerability Note VU#836068, MD5 vulnerable to collision [CERT-VU] Vulnerability Note VU#836068, MD5 vulnerable to collision
attacks, December 2008. attacks, December 2008.
6 Authors' Addresses 7 Authors' Addresses
Rifaat Shekh-Yusef Rifaat Shekh-Yusef
Avaya Avaya
250 Sydney Street 250 Sydney Street
Belleville, Ontario Belleville, Ontario
Canada Canada
Phone: +1-613-967-5267 Phone: +1-613-967-5267
Email: rifatyu@avaya.com Email: rifatyu@avaya.com
 End of changes. 32 change blocks. 
85 lines changed or deleted 129 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/