draft-ietf-httpauth-digest-07.txt   draft-ietf-httpauth-digest-08.txt 
HTTPAuth Working Group R. Shekh-Yusef, Ed. HTTPAuth Working Group R. Shekh-Yusef, Ed.
Internet-Draft D. Ahrens Internet-Draft Avaya
Obsoletes: 2617 (if approved) Avaya Obsoletes: 2617 (if approved) D. Ahrens
Intended Status: Standards Track S. Bremer Intended Status: Standards Track Independent
Expires: October 28, 2014 Netzkonform Expires: February 24, 2015 S. Bremer
April 26, 2014 Netzkonform
August 23, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-07 draft-ietf-httpauth-digest-08
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 may be used with the the HTTP Digest Authentication scheme that may be used with the
authentication mechanism. authentication mechanism.
Status of this Memo Status of this Memo
skipping to change at page 2, line 37 skipping to change at page 2, line 38
3.4 The Authorization Request Header . . . . . . . . . . . . . . 8 3.4 The Authorization Request Header . . . . . . . . . . . . . . 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 Header . . . . . . . . . . . . . . . 13 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 13
3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 15 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 15
3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 16 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 16
3.8 Proxy-Authenticate and Proxy-Authorization . . . . . . . . . 17 3.8 Proxy-Authenticate and Proxy-Authorization . . . . . . . . . 16
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 . . . . 18 3.9.2 Example with SHA-512-256, Charset, and Userhash . . . . 18
4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 20 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 20
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Authentication of Clients using Digest Authentication . . . 21 5.2 Authentication of Clients using Digest Authentication . . . 20
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Weakness Created by Multiple Authentication Schemes . . . . 23 5.5 Weakness Created by Multiple Authentication Schemes . . . . 22
5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23
5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23
5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24
5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24
5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 24
5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25
5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
6.1 HTTP Digest Hash Algorithms Registry . . . . . . . . . . . 27 6.1 HTTP Digest Hash Algorithms Registry . . . . . . . . . . . 26
6.2 Digest Scheme Registration . . . . . . . . . . . . . . . . 27 6.2 Digest Scheme Registration . . . . . . . . . . . . . . . . 27
6.3 Authentication-Info Header Registration . . . . . . . . . . 27 6.3 Authentication-Info Header Registration . . . . . . . . . . 27
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
8.2 Informative References . . . . . . . . . . . . . . . . . . . 30 8.2 Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1 Introduction 1 Introduction
skipping to change at page 10, line 35 skipping to change at page 10, line 35
If the "algorithm" parameter's value is "<algorithm>", e.g. "SHA- If the "algorithm" parameter's value is "<algorithm>", e.g. "SHA-
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 only once - on the first "SHA-256-sess", then A1 is calculated using the initial nonce and
request by the client following receipt of a WWW-Authenticate cnounce value from the first request by the client following receipt
challenge from the server. It uses the server nonce from that of a WWW-Authenticate challenge from the server. It uses the server
challenge, and the first client nonce value to construct A1 as nonce from that challenge, herin called nonce-prime, and the first
client nonce value to construct A1, herin called cnonce-prime as
follows: follows:
A1 = H( unq(username) ":" unq(realm) A1 = H( unq(username) ":" unq(realm)
":" passwd ) ":" passwd )
":" unq(nonce) ":" unq(cnonce) ":" 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 need 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
skipping to change at page 13, line 30 skipping to change at page 13, line 31
3.5 The Authentication-Info Header 3.5 The Authentication-Info Header
The Authentication-Info header is used by the server to communicate The Authentication-Info header is used by the server to communicate
some information regarding the successful authentication in the some information regarding the successful authentication in the
response. response.
Authentication-Info = auth-info Authentication-Info = auth-info
auth-info = *auth-param auth-info = *auth-param
The auth-param is defined in [RFC7235].
The request includes some or all of the following parameters: The request includes some or all of the following parameters:
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 with a The server may send the Authentication-Info header with a
nextnonce field as a means of implementing one-time or otherwise nextnonce field as a means of implementing one-time or otherwise
changing nonces. If the nextnonce field is present the client changing nonces. If the nextnonce field is present the client
SHOULD use it when constructing the Authorization header for its SHOULD use it when constructing the Authorization header for its
skipping to change at page 28, line 25 skipping to change at page 28, line 16
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 to RFC2617, as this document heavily borrows text from their document to
provide a complete description of the digest scheme and its provide a complete description of the digest scheme and its
operations. operations.
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, Julian Reschke, Yaron Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, Yaron
Sheffer, Sean Turner, Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Sheffer, Sean Turner, Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann,
Martin Durst, Peter Saint-Andre, Michael Sweet, Daniel Stenberg, Martin Durst, Peter Saint-Andre, Michael Sweet, Daniel Stenberg,
Brett Tate, Paul Leach, and Ilari Liusvaara for their careful review Brett Tate, Paul Leach, Ilari Liusvaara, and Gary Mort for their
and comments. 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
skipping to change at page 29, line 33 skipping to change at page 29, line 33
(LDAP): Authentication Methods and Security Mechanisms", (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006. RFC 4513, June 2006.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008. 2008.
[HTTP-P1] Fielding, R., Reschke, J., "Hypertext Transfer Protocol [RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", draft-ietf- (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
httpbis-p1-messaging (Work in Progress), November 2013. 2014.
[HTTP-P6] Fielding, R., Nottingham, M., Reschke, J., "Hypertext [RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", draft-ietf- Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
httpbis-p6-cache (Work in Progress), November 2013. 2014.
[HTTP-P7] Fielding, R., Reschke, J., "Hypertext Transfer Protocol [RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth (HTTP/1.1): Authentication", RFC 7235, June 2014.
(Work in Progress), November 2013.
[BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
draft-ietf-httpauth-basicauth-enc (Work in Progress), draft-ietf-httpauth-basicauth-update (Work in Progress),
September 2013. September 2013.
8.2 Informative References 8.2 Informative References
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997. RFC 2195, September 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 30, line 25 skipping to change at page 30, line 25
Rifaat Shekh-Yusef (Editor) Rifaat Shekh-Yusef (Editor)
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: rifaat.ietf@gmail.com Email: rifaat.ietf@gmail.com
David Ahrens David Ahrens
Avaya Independent
California California
USA USA
EMail: ahrensdc@gmail.com EMail: ahrensdc@gmail.com
Sophie Bremer Sophie Bremer
Netzkonform Netzkonform
Germany Germany
Email: sophie.bremer@netzkonform.de Email: sophie.bremer@netzkonform.de
 End of changes. 16 change blocks. 
31 lines changed or deleted 34 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/