draft-ietf-httpauth-digest-13.txt   draft-ietf-httpauth-digest-14.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: August 6, 2015 S. Bremer Expires: August 22, 2015 S. Bremer
Netzkonform Netzkonform
February 2, 2015 February 18, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-13 draft-ietf-httpauth-digest-14
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 August 6, 2015. This Internet-Draft will expire on August 22, 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 . . . . . . . . . . . . . . . . . . . . . . 3 2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4
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 Field . . . . . . . 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 . . . . . . . . . 12
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
Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 Header Fields . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 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 Considerations . . . . . . . . . . . . . 19 4. Internationalization Considerations . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Storing passwords . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . 23 5.7. Online dictionary attacks . . . . . . . . . . . . . . . . 24
5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 23 5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24
5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 24 5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25
5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 24 5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25
5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25 5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25
5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . 26 6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative 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
specified in the "Hypertext Transfer Protocol (HTTP/1.1): specified in the "Hypertext Transfer Protocol (HTTP/1.1):
Authentication" [RFC7235]. Authentication" [RFC7235].
The combination of this document with the definition of the "Basic" The combination of this document with the definition of the "Basic"
authentication scheme [BASIC] and [RFC7235] obsolete [RFC2617]. authentication scheme [BASIC], "The Hypertext Transfer Protocol
(HTTP) Authentication-Info and Proxy-Authentication-Info Response
Header Fields" [AUTHINFO], and [RFC7235] obsolete [RFC2617].
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]. document are to be interpreted as described in [RFC2119].
2. Syntax Convention 2. Syntax Convention
2.1. Examples 2.1. Examples
In the interest of clarity and readability, the extended parameters In the interest of clarity and readability, the extended parameters
or the header fields and parameters in the examples in this document or the header fields and parameters in the examples in this document
might be broken into multiple lines. Any line that is indented in might be broken into multiple lines. Any line that is indented in
this document is a continuation of the preceding line. this document is a continuation of the preceding line.
2.2. ABNF 2.2. ABNF
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
skipping to change at page 8, line 40 skipping to change at page 8, line 44
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. If the username contains The user's name in the specified realm. The quoted string
characters not allowed inside the ABNF token or quoted-string contains the name in plain text or the hash code in hexadecimal
forms, it can be sent in a "username*" parameter instead, using notation. If the username contains characters not allowed inside
the encoding defined in [RFC5987]. Sending both "username" and the ABNF quoted-string production, the "username*" parameter can
"username*" MUST be treated as error. be used. Sending both "username" and "username*" in the same
header option MUST be treated as error.
username*
If the "userhash" parameter value is set "false" and the username
contains characters not allowed inside the ABNF quoted-string
production, the user's name can be sent with this parameter, using
the extended notation defined in [RFC5987].
uri uri
The Effective Request URI (Section 5.5 of [RFC7230]) of the HTTP The Effective Request URI (Section 5.5 of [RFC7230]) of the HTTP
request; duplicated here because proxies are allowed to change the request; duplicated here because proxies are allowed to change the
request target ("request-target", Section 3.1.1 of [RFC7230]) in request target ("request-target", Section 3.1.1 of [RFC7230]) in
transit. transit.
qop qop
skipping to change at page 11, line 49 skipping to change at page 12, line 18
username = H( unq(username) ":" unq(realm) ) username = H( unq(username) ":" unq(realm) )
3.4.5. Parameter Values and Quoted-String 3.4.5. Parameter Values and Quoted-String
Note that the value of many of the parameters, such as "username" Note that the value of many of the parameters, such as "username"
value, are defined as a "quoted-string". However, the "unq" notation value, are defined as a "quoted-string". However, the "unq" notation
indicates that surrounding quotation marks are removed in forming the indicates that surrounding quotation marks are removed in forming the
string A1. Thus if the Authorization header field includes the string A1. Thus if the Authorization header field includes the
fields fields
username="Mufasa", realm=myhost@testrealm.com username="Mufasa", realm="myhost@testrealm.com"
and the user Mufasa has password "Circle Of Life" then H(A1) would be and the user Mufasa has password "Circle Of Life" then H(A1) would be
H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks
in the digested string. in the digested string.
No white space is allowed in any of the strings to which the digest No white space is allowed in any of the strings to which the digest
function H() is applied unless that white space exists in the quoted function H() is applied unless that white space exists in the quoted
strings or entity body whose contents make up the string to be strings or entity body whose contents make up the string to be
digested. For example, the string A1 illustrated above must be digested. For example, the string A1 illustrated above must be
skipping to change at page 17, line 11 skipping to change at page 17, line 24
Note that in principle a client could be asked to authenticate itself Note that in principle a client could be asked to authenticate itself
to both a proxy and an end-server, but never in the same response. to both a proxy and an end-server, but never in the same response.
3.9. Examples 3.9. Examples
3.9.1. Example with SHA-256 and MD5 3.9.1. Example with SHA-256 and MD5
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 of the being requested from the server via a GET request. The URI of the
document is http://www.example.org/dir/index.html". Both client and document is "http://www.example.org/dir/index.html". Both client and
server know that the username for this document is "Mufasa" and the server know that the username for this document is "Mufasa" and the
password is "Circle of Life" ( with one space between each of the password is "Circle of Life" ( with one space between each of the
three words). three words).
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="http-auth@example.org", realm="http-auth@example.org",
skipping to change at page 17, line 39 skipping to change at page 18, line 7
algorithm=MD5, algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
The client can prompt the user for their username and password, after The client can 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 field if the client chooses MD5 digest: Authorization header field if the client chooses MD5 digest:
Authorization: Digest username="Mufasa", Authorization: Digest username="Mufasa",
realm="http-auth@example.org", realm="http-auth@example.org",
uri=/dir/index.html, uri="/dir/index.html",
algorithm=MD5, algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001, nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth, qop=auth,
response="8ca523f5e9506fed4657c9700eebdbec", response="8ca523f5e9506fed4657c9700eebdbec",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
If the client chooses to use the SHA-256 algorithm for calculating If the client chooses to use the SHA-256 algorithm for calculating
the response, the client responds with a new request including the the response, the client responds with a new request including the
skipping to change at page 18, line 41 skipping to change at page 19, line 8
4A C3A4 73 C3B8 6E 20 44 6F 65 4A C3A4 73 C3B8 6E 20 44 6F 65
The password is "Secret, or not?". 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",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
charset=UTF-8, charset=UTF-8,
userhash=true userhash=true
The client can prompt the user for the required credentials and send The client can prompt the user for the required credentials and send
a new request with following Authorization header field: a new request with following Authorization header field:
Authorization: Digest Authorization: Digest
skipping to change at page 27, line 36 skipping to change at page 28, line 12
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] [AUTHINFO]
Reschke, J., "The Hypertext Transfer Protocol (HTTP) Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy-Authentication-Info Response Authentication-Info and Proxy-Authentication-Info Response
Header Fields", draft-ietf-httpbis-auth-info-00 (work in Header Fields", draft-ietf-httpbis-auth-info-02 (work in
progress), January 2015. progress), February 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
 End of changes. 22 change blocks. 
32 lines changed or deleted 43 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/