draft-ietf-httpauth-digest-11.txt   draft-ietf-httpauth-digest-12.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 24, 2015 S. Bremer Expires: July 26, 2015 S. Bremer
Netzkonform Netzkonform
January 20, 2015 January 22, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-11 draft-ietf-httpauth-digest-12
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 24, 2015. This Internet-Draft will expire on July 26, 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 45 skipping to change at page 2, line 45
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 . . . . . . . . . . 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 Header . . . . . . . . . . . . . 13 3.5. The Authentication-Info and Proxy-Authentication-Info
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Digest Usage of Authentication-Info . . . . . . . . . 13 3.5.1. Digest Usage of Authentication-Info . . . . . . . . . 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 . . . . . . . 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 . . . 19
4. Internationalization . . . . . . . . . . . . . . . . . . . . 20 4. Internationalization . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 23 5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23
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
skipping to change at page 3, line 22 skipping to change at page 3, line 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. 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 . . . . . . . . . . . . . . . 27 6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27
6.3. Authentication-Info Header Registration . . . . . . . . . 27 6.3. Authentication-Info and Proxy-Authentication-Info Headers
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 Registration . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
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
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
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 algorithm is intended to allow efficient 3rd party authentication
servers; for the difference in usage, see the description in servers; 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 9 skipping to change at page 11, line 9
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 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
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 12, line 36 skipping to change at page 12, line 36
Also note that if integrity protection is applied (qop=auth-int), the Also note that if integrity protection is applied (qop=auth-int), the
H(entity-body) is the hash of the entity body, not the message body - H(entity-body) is the hash of the entity body, not the message body -
it is computed before any transfer encoding is applied by the sender it is computed before any transfer encoding is applied by the sender
and after it has been removed by the recipient. Note that this and after it has been removed by the recipient. Note that this
includes multipart boundaries and embedded header fields in each part includes multipart boundaries and embedded header fields in each part
of any multipart content-type. of any multipart content-type.
3.4.6. Various Considerations 3.4.6. Various Considerations
The "Method" value is the HTTP request method, in US-ASCII letters, The "Method" value is the HTTP request method, in US-ASCII letters,
as specified in section 3.1.1 of [RFC7230]. The "request-target" as specified in Section 3.1.1 of [RFC7230]. The "request-target"
value is the request-target from the request line as specified in value is the request-target from the request line as specified in
section 3.1.1 of [RFC7230]. This MAY be "*", an "absolute-URI" or an Section 3.1.1 of [RFC7230]. This MAY be "*", an "absolute-URI" or an
"absolute-path" as specified in section 2.7 of [RFC7230], but it MUST "absolute-path" as specified in Section 2.7 of [RFC7230], but it MUST
agree with the request-target. In particular, it MUST be an agree with the request-target. In particular, it MUST be an
"absolute-URI" if the request-target is an "absolute-URI". The "absolute-URI" if the request-target is an "absolute-URI". The
"cnonce" value is a client-chosen value whose purpose is to foil "cnonce" value is a client-chosen value whose purpose is to foil
chosen plaintext attacks. chosen plaintext attacks.
The authenticating server MUST assure that the resource designated by The authenticating server MUST assure that the resource designated by
the "uri" parameter is the same as the resource specified in the the "uri" parameter is the same as the resource specified in the
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
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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. The HTTP protocol specifies that
when a shared cache (see [RFC7234]) has received a request containing when a shared cache (see [RFC7234]) has received a request containing
an Authorization header field and a response from relaying that an Authorization header field and a response from relaying that
request, it MUST NOT return that response as a reply to any other 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 request, unless one of two Cache-Control (see Section 3.2 of
[RFC7234]) directive was present in the response. If the original [RFC7234]) directive was present in the response. If the original
response included the "must-revalidate" Cache-Control directive, the response included the "must-revalidate" Cache-Control directive, the
cache MAY use the entity of that response in replying to a subsequent cache MAY use the entity of that response in replying to a subsequent
request, but MUST first revalidate it with the origin server, using request, but MUST first revalidate it with the origin server, using
the request header fields from the new request to allow the origin the request header fields from the new request to allow the origin
server to authenticate the new request. Alternatively, if the server to authenticate the new request. Alternatively, if the
original response included the "public" Cache-Control directive, the original response included the "public" Cache-Control directive, the
response entity MAY be returned in reply to any subsequent request. response entity MAY be returned in reply to any subsequent request.
3.5. The Authentication-Info Header 3.5. The Authentication-Info and Proxy-Authentication-Info Headers
The Authentication-Info header field is a generic field that MAY be The Authentication-Info header field and the Proxy-Authentication-
used by a server to communicate some information regarding the Info header field are generic fields that MAY be used by a server to
successful authentication of a client response. The following is the communicate some information regarding the successful authentication
syntax of the header: of a client response. The following is the syntax of the headers:
Authentication-Info = auth-info Authentication-Info = auth-info
auth-info = #auth-param auth-info = #auth-param
Proxy-Authentication-Info = proxy-auth-info
proxy-auth-info = #auth-param
The auth-param is defined in [RFC7235]. The auth-param is defined in [RFC7235].
3.5.1. Digest Usage of Authentication-Info 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
skipping to change at page 16, line 4 skipping to change at page 16, line 6
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
section 3.8 below. Section 3.8 below.
3.7. Security Protocol Negotiation 3.7. Security Protocol Negotiation
It is useful for a server to be able to know which security schemes a It is useful for a server to be able to know which security schemes a
client is capable of handling. client is capable of handling.
It is possible that a server wants to require Digest as its It is possible that a server wants to require Digest as its
authentication method, even if the server does not know that the authentication method, even if the server does not know that the
client supports it. A client is encouraged to fail gracefully if the client supports it. A client is encouraged to fail gracefully if the
server specifies only authentication schemes it cannot handle. server specifies only authentication schemes it cannot handle.
skipping to change at page 17, line 4 skipping to change at page 17, line 10
When the client receives the first challenge it SHOULD use the When the client receives the first challenge it SHOULD use the
topmost header field that it supports, unless a local policy dictates topmost header field that it supports, unless a local policy dictates
otherwise. The client MUST ignore any challenge it does not otherwise. The client MUST ignore any challenge it does not
understand. 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
authentication are very similar to those already described. Upon authentication are very similar to those already described. Upon
receiving a request which requires authentication, the proxy/server receiving a request which requires authentication, the proxy/server
MUST issue the "407 Proxy Authentication Required" response with a MUST issue the "407 Proxy Authentication Required" response with a
"Proxy-Authenticate" header field. The digest-challenge used in the "Proxy-Authenticate" header field. The digest-challenge used in the
Proxy-Authenticate header field is the same as that for the WWW- Proxy-Authenticate header field is the same as that for the WWW-
Authenticate header field as defined above in Section 3.3. Authenticate header field as defined above in Section 3.3.
The client/proxy MUST then re-issue the request with a Proxy- The client/proxy MUST then re-issue the request with a Proxy-
Authorization header field, with parameters as specified for the Authorization header field, with parameters as specified for the
Authorization header field in section 3.4 above. Authorization header field in Section 3.4 above.
On subsequent responses, the server sends Proxy-Authenticate-Info On subsequent responses, the server sends Proxy-Authentication-Info
with parameters the same as those for the Authentication-Info header with parameters the same as those for the Authentication-Info header
field. field.
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
skipping to change at page 18, line 11 skipping to change at page 18, line 11
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",
qop="auth, auth-int", qop="auth, auth-int",
algorithm=SHA-256, algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm="http-auth@example.org", realm="http-auth@example.org",
qop="auth, auth-int", qop="auth, auth-int",
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:
skipping to change at page 20, line 23 skipping to change at page 20, line 23
qop=auth, qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6 response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6
c861229025f607a79dd", c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false userhash=false
4. Internationalization 4. Internationalization
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
using the UTF-8 character encoding scheme [RFC3629]. using the UTF-8 character encoding scheme [RFC3629].
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.
skipping to change at page 22, line 16 skipping to change at page 22, line 16
dangerous Basic mechanism. dangerous Basic mechanism.
Digest Authentication offers no confidentiality protection beyond Digest Authentication offers no confidentiality protection beyond
protecting the actual username and password. All of the rest of the protecting the actual username and password. All of the rest of the
request and response are available to an eavesdropper. request and response are available to an eavesdropper.
Digest Authentication offers only limited integrity protection for Digest Authentication offers only limited integrity protection for
the messages in either direction. If qop=auth-int mechanism is used, the messages in either direction. If qop=auth-int mechanism is used,
those parts of the message used in the calculation of the WWW- those parts of the message used in the calculation of the WWW-
Authenticate and Authorization header field response parameter values Authenticate and Authorization header field response parameter values
(see section 3.2 above) are protected. Most header fields and their (see Section 3.2 above) are protected. Most header fields and their
values could be modified as a part of a man-in-the-middle attack. values could be modified as a part of a man-in-the-middle attack.
Many needs for secure HTTP transactions cannot be met by Digest Many needs for secure HTTP transactions cannot be met by Digest
Authentication. For those needs TLS is more appropriate protocol. Authentication. For those needs TLS is more appropriate protocol.
In particular Digest authentication cannot be used for any In particular Digest authentication cannot be used for any
transaction requiring confidentiality protection. Nevertheless many transaction requiring confidentiality protection. Nevertheless many
functions remain for which Digest authentication is both useful and functions remain for which Digest authentication is both useful and
appropriate. appropriate.
5.4. Limited Use Nonce Values 5.4. Limited Use Nonce Values
The Digest scheme uses a server-specified nonce to seed the The Digest scheme uses a server-specified nonce to seed the
generation of the response value (as specified in section 3.4.1 generation of the response value (as specified in Section 3.4.1
above). As shown in the example nonce in section 3.3, the server is above). As shown in the example nonce in Section 3.3, the server is
free to construct the nonce such that it MAY only be used from a free to construct the nonce such that it MAY only be used from a
particular client, for a particular resource, for a limited period of particular client, for a particular resource, for a limited period of
time or number of uses, or any other restrictions. Doing so time or number of uses, or any other restrictions. Doing so
strengthens the protection provided against, for example, replay strengthens the protection provided against, for example, replay
attacks (see 4.5). However, it should be noted that the method attacks (see 4.5). However, it should be noted that the method
chosen for generating and checking the nonce also has performance and chosen for generating and checking the nonce also has performance and
resource implications. For example, a server MAY choose to allow resource implications. For example, a server MAY choose to allow
each nonce value to be used only once by maintaining a record of each nonce value to be used only once by maintaining a record of
whether or not each recently issued nonce has been returned and whether or not each recently issued nonce has been returned and
sending a next-nonce parameter in the Authentication-Info header sending a next-nonce parameter in the Authentication-Info header
skipping to change at page 27, line 27 skipping to change at page 27, line 27
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 Header Registration 6.3. Authentication-Info and Proxy-Authentication-Info Headers
Registration
This specification registers the Authentication-Info Header field This specification registers the Authentication-Info and the Proxy-
with the Message Header Field Registry. Authentication-Info Header fields with the Message Header Field
Registry.
Header Field Name: Authentication-Info Header Field Name: Authentication-Info
Protocol: http Protocol: http
Status: standard Status: standard
Reference: RFCXXXX, Section 3.5 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 reviews, comments,
suggestions, and text provided to various areas in this document. suggestions, and text provided to various areas in this document.
 End of changes. 30 change blocks. 
36 lines changed or deleted 47 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/