draft-ietf-httpauth-digest-17.txt   draft-ietf-httpauth-digest-18.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: October 9, 2015 S. Bremer Expires: October 12, 2015 S. Bremer
Netzkonform Netzkonform
April 7, 2015 April 10, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-17 draft-ietf-httpauth-digest-18
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 October 9, 2015. This Internet-Draft will expire on October 12, 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 3, line 18 skipping to change at page 3, line 18
5.2. Storing passwords . . . . . . . . . . . . . . . . . . . . 21 5.2. Storing passwords . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . 22
5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 24
5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24 5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24
5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25 5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25
5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25 5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25
5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25 5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25
5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.12. Parameter Randomness . . . . . . . . . . . . . . . . . . 26
5.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. Hash Algorithms for HTTP Digest Authentication . . . . . 26 6.1. Hash Algorithms for HTTP Digest Authentication . . . . . 26
6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27 6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 30 Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 4, line 26 skipping to change at page 4, line 26
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], and the ABNF List Extension of [RFC7230]. notation of [RFC5234], and the ABNF List Extension of [RFC7230].
3. Digest Access Authentication Scheme 3. Digest Access Authentication Scheme
3.1. Overall Operation 3.1. Overall Operation
The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme is based on a simple challenge-response paradigm.
The Digest scheme challenges using a nonce value, and might indicate The Digest scheme challenges using a nonce value, and might indicate
that username hashing is supported. A valid response contains a that username hashing is supported. A valid response contains a
checksum of the username, the password, the given nonce value, the unkeyed digest of the username, the password, the given nonce value,
HTTP method, and the requested URI. In this way, the password is the 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
randomness of the randomly chosen parameters, such as client and
server nonces. These should be generated by a strong random or
properly seeded pseudorandom source (see [RFC4086]).
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 unkeyed digest or digest. This documents adds
and SHA-512/256 algorithms. To maintain backwards compatibility with SHA-256 and SHA-512/256 algorithms. To maintain backwards
[RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED. compatibility with [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
skipping to change at page 7, line 8 skipping to change at page 7, line 4
the client was rejected because the nonce value was stale. If the client was rejected because the nonce value was stale. If
stale is TRUE, the client may wish to simply retry the request stale is TRUE, the client may wish to simply retry the request
with a new encrypted response, without re-prompting the user for a with a new encrypted response, without re-prompting the user for a
new username and password. The server SHOULD only set stale to new username and password. The server SHOULD only set stale to
TRUE if it receives a request for which the nonce is invalid. If TRUE if it receives a request for which the nonce is invalid. If
stale is FALSE, or anything other than TRUE, or the stale stale is FALSE, or anything other than TRUE, or the stale
parameter is not present, the username and/or password are parameter is not present, the username and/or password are
invalid, and new values MUST be obtained. invalid, and new values MUST be obtained.
algorithm algorithm
A string indicating an algorithm used to produce the digest and a
A string indicating a pair of algorithms used to produce the unkeyed digest. If this is not present it is assumed to be "MD5".
digest and a checksum. If this is not present it is assumed to be If the algorithm is not understood, the challenge SHOULD be
"MD5". If the algorithm is not understood, the challenge SHOULD ignored (and a different one used, if there is more than one).
be ignored (and a different one used, if there is more than one).
When used with the Digest mechanism, each one of the algorithms When used with the Digest mechanism, each one of the algorithms
has two variants: Session variant and non-Session variant. The has two variants: Session variant and non-Session variant. The
non-Session variant is denoted by "<algorithm>", e.g. "SHA-256", non-Session variant is denoted by "<algorithm>", e.g. "SHA-256",
and the Session variant is denoted by "<algorithm>-sess", e.g. and the Session variant is denoted by "<algorithm>-sess", e.g.
"SHA-256-sess". "SHA-256-sess".
In this document the string obtained by applying the digest In this document the string obtained by applying the digest
algorithm to the data "data" with secret "secret" will be denoted algorithm to the data "data" with secret "secret" will be denoted
by KD(secret, data), and the string obtained by applying the by KD(secret, data), and the string obtained by applying the
checksum algorithm to the data "data" will be denoted H(data). unkeyed digest algorithm to the data "data" will be denoted
The notation unq(X) means the value of the quoted-string X without H(data). KD stands for Keyed Digest, and the notation unq(X)
the surrounding quotes and with quoting slashes removed. means the value of the quoted-string X without the surrounding
quotes and with quoting slashes removed.
For "<algorithm>" and "<algorithm>-sess" For "<algorithm>" and "<algorithm>-sess"
H(data) = <algorithm>(data) H(data) = <algorithm>(data)
and and
KD(secret, data) = H(concat(secret, ":", data)) KD(secret, data) = H(concat(secret, ":", data))
For example: For example:
For the "SHA-256" and "SHA-256-sess" algorithms For the "SHA-256" and "SHA-256-sess" algorithms
H(data) = SHA-256(data) H(data) = SHA-256(data)
i.e., the digest is the "<algorithm>" of the secret concatenated i.e., the digest is the "<algorithm>" of the secret concatenated
with a colon concatenated with the data. The "<algorithm>-sess" with a colon concatenated with the data. The "<algorithm>-sess"
algorithm is intended to allow efficient 3rd party authentication is intended to allow efficient 3rd party authentication servers;
servers; for the difference in usage, see the description in for the difference in usage, see the description in Section 3.4.2.
Section 3.4.2.
qop qop
This parameter MUST be used by all implementations. It is a This parameter MUST be used by all implementations. It is a
quoted string of one or more tokens indicating the "quality of quoted string of one or more tokens indicating the "quality of
protection" values supported by the server. The value "auth" protection" values supported by the server. The value "auth"
indicates authentication; the value "auth-int" indicates indicates authentication; the value "auth-int" indicates
authentication with integrity protection; see the descriptions authentication with integrity protection; see the descriptions
below for calculating the response parameter value for the below for calculating the response parameter value for the
application of this choice. Unrecognized options MUST be ignored. application of this choice. Unrecognized options MUST be ignored.
skipping to change at page 11, line 7 skipping to change at page 11, line 4
256", then A1 is: 256", then A1 is:
A1 = unq(username) ":" unq(realm) ":" passwd A1 = unq(username) ":" unq(realm) ":" passwd
where where
passwd = < user's password > passwd = < user's password >
If the "algorithm" parameter's value is "<algorithm>-sess", e.g. If the "algorithm" parameter's value is "<algorithm>-sess", e.g.
"SHA-256-sess", then A1 is calculated using the nonce value provided "SHA-256-sess", then A1 is calculated using the nonce value provided
in the challenge from the server, and cnounce value from the request in the challenge from the server, and cnonce value from the request
by the client following receipt of a WWW-Authenticate challenge from by the client following receipt of a WWW-Authenticate challenge from
the server. It uses the server nonce from that challenge, herein the server. It uses the server nonce from that challenge, herein
called nonce-prime, and the client nonce value from the response, called nonce-prime, and the client nonce value from the response,
herein called cnonce-prime, to construct A1 as follows: herein called cnonce-prime, to construct A1 as follows:
A1 = H( unq(username) ":" unq(realm) A1 = H( unq(username) ":" unq(realm) ":" passwd )
":" passwd )
":" unq(nonce-prime) ":" unq(cnonce-prime) ":" unq(nonce-prime) ":" unq(cnonce-prime)
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 "authentication requests and responses which is different for each "authentication
session", thus limiting the amount of material hashed with any one session", thus limiting the amount of material hashed with any one
key. (Note: see further discussion of the authentication session in key. (Note: see further discussion of the authentication session in
Section 3.6.) Because the server need only use the hash of the user Section 3.6.) Because the server needs only use the hash of the user
credentials in order to create the A1 value, this construction could credentials in order to create the A1 value, this construction could
be used in conjunction with a third party authentication service so be used in conjunction with a third party authentication service so
that the web server would not need the actual password value. The that the web server would not need the actual password value. The
specification of such a protocol is beyond the scope of this specification of such a protocol is beyond the scope of this
specification. specification.
3.4.3. A2 3.4.3. A2
If the "qop" parameter's value is "auth" or is unspecified, then A2 If the "qop" parameter's value is "auth" or is unspecified, then A2
is: is:
skipping to change at page 14, line 5 skipping to change at page 13, line 51
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 parameter that MUST be used on the next includes a nextnonce parameter 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. Use of the "nc" parameter can retain most of the pipelining. Use of the "nc" parameter can retain most of the
security advantages of a new server nonce without the security advantages of a new server nonce without the
deleterious affects on pipelining. deleterious effects on pipelining.
qop 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 response by the server. The value "auth" indicates
authentication; the value "auth-int" indicates authentication with authentication; the value "auth-int" indicates authentication with
integrity protection. The server SHOULD use the same value for integrity protection. The server SHOULD use the same value for
the qop parameter in the response as was sent by the client in the the qop parameter in the response as was sent by the client in the
corresponding request. corresponding request.
skipping to change at page 21, line 17 skipping to change at page 21, line 17
Digest authentication requires that the authenticating agent (usually Digest authentication requires that the authenticating agent (usually
the server) store some data derived from the user's name and password the server) store some data derived from the user's name and password
in a "password file" associated with a given realm. Normally this in a "password file" associated with a given realm. Normally this
might contain pairs consisting of username and H(A1), where H(A1) is might contain pairs consisting of username and H(A1), where H(A1) is
the digested value of the username, realm, and password as described the digested value of the username, realm, and password as described
above. above.
The security implications of this are that if this password file is The security implications of this are that if this password file is
compromised, then an attacker gains immediate access to documents on compromised, then an attacker gains immediate access to documents on
the server using this realm. Unlike, say a standard UNIX password the server using this realm. Unlike, say a standard UNIX password
file, this information need not be decrypted in order to access file, this information needs not be decrypted in order to access
documents in the server realm associated with this file. On the documents in the server realm associated with this file. On the
other hand, decryption, or more likely a brute force attack, would be other hand, decryption, or more likely a brute force attack, would be
necessary to obtain the user's password. This is the reason that the necessary to obtain the user's password. This is the reason that the
realm is part of the digested data stored in the password file. It realm is part of the digested data stored in the password file. It
means that if one Digest authentication password file is compromised, means that if one Digest authentication password file is compromised,
it does not automatically compromise others with the same username it does not automatically compromise others with the same username
and password (though it does expose them to brute force attack). and password (though it does expose them to brute force attack).
There are two important security consequences of this. First the There are two important security consequences of this. First the
password file must be protected as if it contained unencrypted password file must be protected as if it contained unencrypted
skipping to change at page 26, line 5 skipping to change at page 26, line 5
pass over that space. It also reduces the time to find the first pass over that space. It also reduces the time to find the first
password by a factor equal to the number of nonce/response pairs password by a factor equal to the number of nonce/response pairs
gathered. This search of the password space can often be done in gathered. This search of the password space can often be done in
parallel on many machines, and even a single machine can search large parallel on many machines, and even a single machine can search large
subsets of the password space very quickly -- reports exist of subsets of the password space very quickly -- reports exist of
searching all passwords with six or fewer letters in a few hours. searching all passwords with six or fewer letters in a few hours.
The countermeasure against this attack is to for clients to use of The countermeasure against this attack is to for clients to use of
the "cnonce" parameter. the "cnonce" parameter.
5.12. Summary 5.12. Parameter Randomness
The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters, such as client and
server nonces. These should be generated by a strong random or
properly seeded pseudorandom source (see [RFC4086]).
5.13. Summary
By modern cryptographic standards Digest Authentication is weak. But By modern cryptographic standards Digest Authentication is weak. But
for a large range of purposes it is valuable as a replacement for for a large range of purposes it is valuable as a replacement for
Basic Authentication. It remedies some, but not all, weaknesses of Basic Authentication. It remedies some, but not all, weaknesses of
Basic Authentication. Its strength may vary depending on the Basic Authentication. Its strength may vary depending on the
implementation. In particular the structure of the nonce (which is implementation. In particular the structure of the nonce (which is
dependent on the server implementation) may affect the ease of dependent on the server implementation) may affect the ease of
mounting a replay attack. A range of server options is appropriate mounting a replay attack. A range of server options is appropriate
since, for example, some implementations may be willing to accept the since, for example, some implementations may be willing to accept the
server overhead of one-time nonces or digests to eliminate the server overhead of one-time nonces or digests to eliminate the
skipping to change at page 27, line 48 skipping to change at page 28, line 6
operations. operations.
Special thanks to Julian Reschke for his many 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, Gary Mort, Alexey Melnikov, Benjamin Kaduk, Kathleen Ilari Liusvaara, Gary Mort, Alexey Melnikov, Benjamin Kaduk, Kathleen
Moriarty, and Francis Dupont for their careful review and comments. Moriarty, Francis Dupont, and Hilarie Orman 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.
The authors would like to thank Barry Leiba for his help with the The authors would like to thank Barry Leiba for his help with the
registry. registry.
skipping to change at page 30, line 11 skipping to change at page 30, line 11
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms", (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006. RFC 4513, June 2006.
Appendix A. Changes from RFC 2617 Appendix A. Changes from RFC 2617
This document introduces the following changes: This document introduces the following changes:
o Adds support for two new algorithms, SHA2-256 as mandatory and o Adds support for two new algorithms, SHA2-256 as mandatory and
SHA2-512/256 as a backup, and defines the proper algorithm SHA2-512/256 as a backup, and defines the proper algorithm
negotitation. The document keeps the MD5 algorithm support but negotiation. The document keeps the MD5 algorithm support but
only for backward compatibility. only for backward compatibility.
o Introduces the username hashing capability and the parameter o Introduces the username hashing capability and the parameter
associated with that, mainly for privacy reasons. associated with that, mainly for privacy reasons.
o Adds various internationalization considerations that impact the o Adds various internationalization considerations that impact the
A1 calculation and username and password encoding. A1 calculation and username and password encoding.
o Deprecates backward compatibility with RFC2069. o Deprecates backward compatibility with RFC2069.
 End of changes. 19 change blocks. 
35 lines changed or deleted 38 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/