draft-ietf-httpauth-digest-03.txt   draft-ietf-httpauth-digest-04.txt 
HTTPAuth Working Group R. Shekh-Yusef, Ed. HTTPAuth Working Group R. Shekh-Yusef, Ed.
Internet-Draft D. Ahrens Internet-Draft D. Ahrens
Obsoletes: 2617 (if approved) Avaya Obsoletes: 2617 (if approved) Avaya
Intended Status: Standards Track S. Bremer Intended Status: Standards Track S. Bremer
Expires: July 23, 2014 Netzkonform Expires: July 23, 2014 Netzkonform
January 19, 2014 January 19, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-03 draft-ietf-httpauth-digest-04
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 33 skipping to change at page 2, line 33
3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5
3.4 The Authorization Request Header . . . . . . . . . . . . . . 8 3.4 The Authorization Request Header . . . . . . . . . . . . . . 8
3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 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 Directive Values and Quoted-String . . . . . . . . . . . 11 3.4.5 Directive 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 . . . . . . . . . . . . . . . . . . . . . . 14 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 16 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 15
3.8 Proxy-Authenticate and Proxy-Authorization . . . . . . . . . 16 3.8 Proxy-Authenticate and Proxy-Authorization . . . . . . . . . 16
3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.9.1 Example with SHA2-256 and MD5 . . . . . . . . . . . . . 17
3.9.2 Example with SHA-512-256, Charset, and Userhash . . . . 18
4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 19 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 19
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Authentication of Clients using Digest Authentication . . . 19 5.2 Authentication of Clients using Digest Authentication . . . 20
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 20 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 21 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Weakness Created by Multiple Authentication Schemes . . . . 21 5.5 Weakness Created by Multiple Authentication Schemes . . . . 22
5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 22 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23
5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 22 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23
5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 23 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24
5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 23 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24
5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 24 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 24
5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 24 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25
5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 24 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Digest . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 28
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 8.2 Informative References . . . . . . . . . . . . . . . . . . . 29
8.2 Informative References . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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 may be used with the the HTTP Digest Authentication scheme that may be used with the
authentication mechanism. authentication mechanism.
The details of the challenge-response authentication mechanism are The details of the challenge-response authentication mechanism are
skipping to change at page 5, line 16 skipping to change at page 5, line 16
represented by the character '0', 0001 by '1' and so on up to the represented by the character '0', 0001 by '1' and so on up to the
representation of 1111 as 'f'. If the MD5 algorithm is used to representation of 1111 as 'f'. If the MD5 algorithm is used to
calculate the digest, then the digest will be represented as 32 calculate the digest, then the digest will be represented as 32
hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal
characters. characters.
3.3 The WWW-Authenticate Response Header 3.3 The WWW-Authenticate Response Header
If a server receives a request for an access-protected object, and an If a server receives a request for an access-protected object, and an
acceptable Authorization header is not sent, the server responds with acceptable Authorization header is not sent, the server responds with
a "401 Unauthorized" status code, and a WWW-Authenticate header as a "401 Unauthorized" status code, and a WWW-Authenticate header with
per the framework defined above, and include some or all of the Digest scheme as per the framework defined above, and include some or
following parameters: all of the following parameters:
realm realm
A string to be displayed to users so they know which username and A string to be displayed to users so they know which username and
password to use. This string should contain at least the name of password to use. This string should contain at least the name of
the host performing the authentication and might additionally the host performing the authentication and might additionally
indicate the collection of users who might have access. An example indicate the collection of users who might have access. An example
might be "registered_users@gotham.news.com". might be "registered_users@gotham.news.com". (See section 2.2 of
[HTTP-P7] for more details).
domain domain
A quoted, space-separated list of URIs, as specified in RFC XURI A quoted, space-separated list of URIs, as specified in RFC 3986
[RFC2396], that define the protection space. If a URI is an [RFC3986], that define the protection space. If a URI is an
abs_path, it is relative to the canonical root URL of the server abs_path, it is relative to the canonical root URL of the server
being accessed. An absolute-URI in this list may refer to a being accessed. An absolute-URI in this list may refer to a
different server than the one being accessed. The client can use different server than the one being accessed. The client can use
this list to determine the set of URIs for which the same this list to determine the set of URIs for which the same
authentication information may be sent: any URI that has a URI in authentication information may be sent: any URI that has a URI in
this list as a prefix (after both have been made absolute) may be this list as a prefix (after both have been made absolute) may be
assumed to be in the same protection space. If this directive is assumed to be in the same protection space. If this directive is
omitted or its value is empty, the client should assume that the omitted or its value is empty, the client should assume that the
protection space consists of all URIs on the responding server. protection space consists of all URIs on the responding server.
skipping to change at page 6, line 6 skipping to change at page 6, line 7
present it should be ignored. present it should be ignored.
nonce nonce
A server-specified data string which should be uniquely generated A server-specified data string which should be uniquely generated
each time a 401 response is made. It is recommended that this each time a 401 response is made. It is recommended that this
string be base64 or hexadecimal data. Specifically, since the string be base64 or hexadecimal data. Specifically, since the
string is passed in the header lines as a quoted string, the string is passed in the header lines as a quoted string, the
double-quote character is not allowed. double-quote character is not allowed.
The contents of the nonce are implementation dependent. The The contents of the nonce are implementation dependent. The
quality of the implementation depends on a good choice. A nonce quality of the implementation depends on a good choice. A nonce
might, for example, be constructed as the base 64 encoding of might, for example, be constructed as the base 64 encoding of
time-stamp H(time-stamp ":" ETag ":" private-key) time-stamp H(time-stamp ":" ETag ":" private-key)
where time-stamp is a server-generated time or other non-repeating where time-stamp is a server-generated time or other non-repeating
value, ETag is the value of the HTTP ETag header associated with value, ETag is the value of the HTTP ETag header associated with
the requested entity, and private-key is data known only to the the requested entity, and private-key is data known only to the
server. With a nonce of this form a server would recalculate the server. With a nonce of this form a server would recalculate the
hash portion after receiving the client authentication header and hash portion after receiving the client authentication header and
reject the request if it did not match the nonce from that header reject the request if it did not match the nonce from that header
skipping to change at page 6, line 38 skipping to change at page 6, line 39
nonce or a previously used digest, in order to protect against a nonce or a previously used digest, in order to protect against a
replay attack. Or, an implementation might choose to use one-time replay attack. Or, an implementation might choose to use one-time
nonces or digests for POST or PUT requests and a time-stamp for nonces or digests for POST or PUT requests and a time-stamp for
GET requests. For more details on the issues involved see section GET requests. For more details on the issues involved see section
5 of this document. 5 of this document.
The nonce is opaque to the client. The nonce is opaque to the client.
opaque opaque
A string of data, specified by the server, which should be A string of data, specified by the server, which should be
returned by the client unchanged in the Authorization header of returned by the client unchanged in the Authorization header of
subsequent requests with URIs in the same protection space. It is subsequent requests with URIs in the same protection space. It is
recommended that this string be base64 or hexadecimal data. recommended that this string be base64 or hexadecimal data.
stale stale
A case-insensitive flag, indicating that the previous request from A case-insensitive flag, indicating that the previous request from
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 reprompting the user for a with a new encrypted response, without reprompting 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 but TRUE if it receives a request for which the nonce is invalid but
skipping to change at page 8, line 11 skipping to change at page 8, line 13
descriptions below for calculating the response directive value descriptions below for calculating the response directive value
for the application of this choice. Unrecognized options MUST be for the application of this choice. Unrecognized options MUST be
ignored. ignored.
charset charset
This is an OPTIONAL parameter that is used by the server to This is an OPTIONAL parameter that is used by the server to
indicate the encoding scheme it supports. indicate the encoding scheme it supports.
userhash userhash
This is an OPTIONAL parameter that is used by the server to This is an OPTIONAL parameter that is used by the server to
indicate that it supports username hashing. indicate that it supports username hashing. Valid value are:
"true" or "false".
3.4 The Authorization Request Header 3.4 The Authorization Request Header
The client is expected to retry the request, passing an The client is expected to retry the request, passing an
Authorization header line, which is defined according to the Authorization header line with Digest scheme, which is defined
framework above. The values of the opaque and algorithm fields according to the framework above. The values of the opaque and
must be those supplied in the WWW-Authenticate response header for algorithm fields must be those supplied in the WWW-Authenticate
the entity being requested. response header for the entity being requested.
The request includes some or all of the following parameters: The request includes some or all of the following parameters:
response response
A string of the hex digits computed as defined below, which proves A string of the hex digits computed as a request-digest defined
that the user knows a password below, which proves that the user knows a password
username username
The user's name in the specified realm. The user's name in the specified realm.
digest-uri digest-uri
The URI from request-target of the Request-Line; duplicated here The URI from request-target of the Request-Line; duplicated here
because proxies are allowed to change the Request-Line in transit. because proxies are allowed to change the Request-Line in transit.
qop qop
Indicates what "quality of protection" the client has applied to Indicates what "quality of protection" the client has applied to
skipping to change at page 9, line 27 skipping to change at page 9, line 31
maintaining its own copy of this count - if the same nc-value is maintaining its own copy of this count - if the same nc-value is
seen twice, then the request is a replay. See the description seen twice, then the request is a replay. See the description
below of the construction of the request-digest value. below of the construction of the request-digest value.
charset charset
This OPTIONAL parameter is used by the client to indicate the This OPTIONAL parameter is used by the client to indicate the
character encoding used for the username and password. character encoding used for the username and password.
userhash userhash
This OPTIONAL parameter is used by the client to indicate that the This OPTIONAL parameter is used by the client to indicate that the
username has been hashed. username has been hashed. Valid value are: "true" or "false".
If a directive or its value is improper, or required directives are If a directive or its value is improper, or required directives are
missing, the proper response is 400 Bad Request. If the request- missing, the proper response is 400 Bad Request. If the request-
digest is invalid, then a login failure should be logged, since digest is invalid, then a login failure should be logged, since
repeated login failures from a single client may indicate an attacker repeated login failures from a single client may indicate an attacker
attempting to guess passwords. attempting to guess passwords.
The definition of request-digest above indicates the encoding for its The definition of request-digest above indicates the encoding for its
value. The following definitions show how the value is computed. value. The following definitions show how the value is computed.
skipping to change at page 13, line 37 skipping to change at page 13, line 37
auth-info = 1#(nextnonce | [ message-qop ] auth-info = 1#(nextnonce | [ message-qop ]
| [ response-auth ] | [ cnonce ] | [ response-auth ] | [ cnonce ]
| [nonce-count] ) | [nonce-count] )
nextnonce = "nextnonce" "=" nonce-value nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <"> response-digest = <"> *LHEX <">
The value of the nextnonce directive is the nonce the server wishes The value of the nextnonce directive is the nonce the server wishes
the client to use for a future authentication response. The server the client to use for a future authentication response. The server
may send the Authentication-Info header with a nextnonce field as a may send the Authentication-Info header with a nextnonce field as a
means of implementing one-time or otherwise changing nonces. If the means of implementing one-time or otherwise changing nonces. If the
nextnonce field is present the client SHOULD use it when constructing nextnonce field is present the client SHOULD use it when constructing
the Authorization header for its next request. Failure of the client the Authorization header for its next request. Failure of the client
to do so may result in a request to re-authenticate from the server to do so may result in a request to re-authenticate from the server
with the "stale=TRUE". with the "stale=TRUE".
Server implementations should carefully consider the performance Server implementations should carefully consider the performance
implications of the use of this mechanism; pipelined requests will implications of the use of this mechanism; pipelined requests will
not be possible if every response includes a nextnonce directive not be possible if every response includes a nextnonce directive
that must be used on the next request received by the server. that must be used on the next request received by the server.
Consideration should be given to the performance vs. security Consideration should be given to the performance vs. security
skipping to change at page 17, line 17 skipping to change at page 17, line 6
Authorization header, with directives as specified for the Authorization header, with directives as specified for the
Authorization header in section 3.4 above. Authorization header in section 3.4 above.
On subsequent responses, the server sends Proxy-Authenticate-Info On subsequent responses, the server sends Proxy-Authenticate-Info
with directives the same as those for the Authentication-Info header with directives 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 Example 3.9 Examples
3.9.1 Example with SHA2-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.nowhere.org/dir/index.html". Both client and document is http://www.nowhere.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 is sent, so the server responds with: header is sent, so the server responds with:
skipping to change at page 19, line 5 skipping to change at page 18, line 21
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html", uri="/dir/index.html",
qop="auth", qop="auth",
algorithm="SHA2-256", algorithm="SHA2-256",
nc=00000001, nc=00000001,
cnonce="0a4f113b", cnonce="0a4f113b",
response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93
a59b630c13dfe0a5dc6e38b", a59b630c13dfe0a5dc6e38b",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
3.9.2 Example with SHA-512-256, Charset, and Userhash
The following example assumes that an access protected document is
being requested from the server via a GET request. The URI for the
request is "http://api.example.org/doe.json". Both client and server
know the userhash of the username, support the UTF-8 charset, and use
the SHA-512-256 algorithm. The username for the request is "Jason
Doe" and the password is "Secret, or not?".
The first time the client requests the document, no Authorization
header is sent, so the server responds with:
HTTP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="api@example.org",
qop=auth,
algorithm=SHA-512-256,
nonce="e145a96d70d40739596e60c6340f13be03290bd73c676d
3f25c01271af522eb2",
opaque="192cbcf2a2576846522c1a367c1dfdf0359a87719c5cc1
839e4f3d2ffeb82517",
charset=UTF-8,
userhash=true
The client may prompt the user for the required credentials and send
a new request with following Authorization header:
Authorization: Digest
username="298bc3decec198ec5e7ecc1d69f059ca33044dd15baf45
a1f87bbd7adb3784fd",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="e145a96d70d40739596e60c6340f13be03290bd73c676d
3f25c01271af522eb2",
nc=00000001,
cnonce="cde966df34a49d5d842a263604159141c81db8d468e1bf
657230429424fc337a",
qop=auth,
response="ec180fc03b7a0dcd43c414f66f2335399bbe5f4d4ad469
f8233106ba453213c8",
opaque="192cbcf2a2576846522c1a367c1dfdf0359a87719c5cc1
839e4f3d2ffeb82517",
charset=UTF-8,
userhash=true
If the client can not provide a hashed username for any reason, the
client may try a request with this Authorization header:
Authorization: Digest
username="Jason Doe",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="e145a96d70d40739596e60c6340f13be03290bd73c676d
3f25c01271af522eb2",
nc=00000001,
cnonce="cde966df34a49d5d842a263604159141c81db8d468e1bf
657230429424fc337a",
qop=auth,
response="ec180fc03b7a0dcd43c414f66f2335399bbe5f4d4ad469
f8233106ba453213c8",
opaque="192cbcf2a2576846522c1a367c1dfdf0359a87719c5cc1
839e4f3d2ffeb82517",
charset=UTF-8,
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. expect the user agent to use.
The only allowed value is "UTF-8", to be matched case-insensitively, The only allowed value is "UTF-8", to be matched case-insensitively,
indicating that the server expects the UTF-8 character encoding to be indicating that the server expects the UTF-8 character encoding to be
used ([RFC3629]). used ([RFC3629]).
skipping to change at page 19, line 47 skipping to change at page 20, line 41
Digest authentication SHOULD be used over a secure channel like HTTPS Digest authentication SHOULD be used over a secure channel like HTTPS
[RFC2818]. [RFC2818].
5.2 Authentication of Clients using Digest Authentication 5.2 Authentication of Clients using Digest Authentication
Digest Authentication does not provide a strong authentication Digest Authentication does not provide a strong authentication
mechanism, when compared to public key based mechanisms, for example. mechanism, when compared to public key based mechanisms, for example.
However, it is significantly stronger than (e.g.) CRAM-MD5, which has However, it is significantly stronger than (e.g.) CRAM-MD5, which has
been proposed for use with LDAP [RFC2829], POP and IMAP (see RFC been proposed for use with LDAP [RFC4513], POP and IMAP (see
2195). It is intended to replace the much weaker and even more [RFC2195]). It is intended to replace the much weaker and even more
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 directive values Authenticate and Authorization header field response directive 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 or SHTTP are more appropriate Authentication. For those needs TLS or SHTTP are more appropriate
protocols. In particular Digest authentication cannot be used for any protocols. 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.3 Limited Use Nonce Values 5.3 Limited Use Nonce Values
skipping to change at page 27, line 13 skipping to change at page 28, line 13
Pointer to specification text: RFCXXX Pointer to specification text: RFCXXX
7 Acknowledgments 7 Acknowledgments
TODO TODO
8 References 8 References
8.1 Normative References 8.1 Normative References
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "An Extension to
HTTP : Digest Access Authentication", RFC 2069, January
1997.
[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.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[HTTP-P1] Fielding, R., Reschke, J., "Hypertext Transfer Protocol [HTTP-P1] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", Work in Progress, (HTTP/1.1): Message Syntax and Routing", Work in Progress,
November 2013. November 2013.
[HTTP-P6] Fielding, R., Nottingham, M., Reschke, J., "Hypertext [HTTP-P6] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", Work in Progress, Transfer Protocol (HTTP/1.1): Caching", Work in Progress,
November 2013. November 2013.
[HTTP-P7] Fielding, R., Reschke, J., "Hypertext Transfer Protocol [HTTP-P7] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", Work in Progress, November (HTTP/1.1): Authentication", Work in Progress, November
2013. 2013.
8.2 Informative References 8.2 Informative References
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "An Extension to
HTTP : Digest Access Authentication", RFC 2069, January
1997.
[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.
[SHA3] "SHA-3 STANDARDIZATION"
http://csrc.nist.gov/groups/ST/hash/sha-3/sha-3_standardization.html
Authors' Addresses Authors' Addresses
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
 End of changes. 25 change blocks. 
64 lines changed or deleted 135 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/