draft-ietf-httpauth-digest-05.txt   draft-ietf-httpauth-digest-06.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: August 16, 2014 Netzkonform Expires: October 11, 2014 Netzkonform
February 12, 2014 April 9, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-05 draft-ietf-httpauth-digest-06
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 32 skipping to change at page 2, line 32
2.3 ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 5 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 5
3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 5 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 5
3.2 Representation of Digest Values . . . . . . . . . . . . . . 5 3.2 Representation of Digest Values . . . . . . . . . . . . . . 5
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 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 . . . . . . . . . . . 12 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 . . . . . . . . . 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 . . . . 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 . . . 21
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Weakness Created by Multiple Authentication Schemes . . . . 23 5.5 Weakness Created by Multiple Authentication Schemes . . . . 23
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 . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . . 26 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
6.1 HTTP Digest Hash Algorithms Registry . . . . . . . . . . . 26 6.1 HTTP Digest Hash Algorithms Registry . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . 29 8.2 Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
and and
KD(secret, data) = H(concat(secret, ":", data)) KD(secret, data) = H(concat(secret, ":", data))
For example: For example:
For the "SHA-256" and "SHA-256-sess" algorithms For the "SHA-256" and "SHA-256-sess" algorithms
H(data) = SHA-256(data) H(data) = SHA-256(data)
i.e., the digest is the MD5 of the secret concatenated with a i.e., the digest is the SHA-256 of the secret concatenated with
colon concatenated with the data. The "MD5-sess" algorithm is a colon concatenated with the data. The "SHA-256-sess"
intended to allow efficient 3rd party authentication servers; algorithm is intended to allow efficient 3rd party
for the difference in usage, see the description in section authentication servers; for the difference in usage, see the
3.4.2. description in section 3.4.2.
qop qop
This parameter is optional, but is made so only for backward This parameter MUST be used by all implementations compliant with
compatibility with RFC 2069 [RFC2069]; it SHOULD be used by all this version of the Digest scheme. It is a quoted string of one or
implementations compliant with this version of the Digest scheme. more tokens indicating the "quality of protection" values
If present, it is a quoted string of one or more tokens indicating supported by the server. The value "auth" indicates
the "quality of protection" values supported by the server. The authentication; the value "auth-int" indicates authentication with
value "auth" indicates authentication; the value "auth-int" integrity protection; see the descriptions below for calculating
indicates authentication with integrity protection; see the the response parameter value for the application of this choice.
descriptions below for calculating the response parameter value Unrecognized options MUST be ignored.
for the application of this choice. Unrecognized options MUST be
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. Valid value are: indicate that it supports username hashing. Valid value are:
"true" or "false". "true" or "false".
skipping to change at page 9, line 15 skipping to change at page 9, line 14
username username
The user's name in the specified realm. The user's name in the specified realm.
uri 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
the message. If present, its value MUST be one of the alternatives the message. Its value MUST be one of the alternatives the server
the server indicated it supports in the WWW-Authenticate header. indicated it supports in the WWW-Authenticate header. These values
These values affect the computation of the response. Note that affect the computation of the response. Note that this is a single
this is a single token, not a quoted list of alternatives as in token, not a quoted list of alternatives as in WWW-Authenticate.
WWW-Authenticate. This parameter is optional in order to preserve .in 3
backward compatibility with a minimal implementation of RFC 2069
[RFC2069], but SHOULD be used if the server indicated that qop is
supported by providing a qop parameter in the WWW-Authenticate
header field.
cnonce cnonce
This MUST be specified if a qop parameter is sent (see above), and This MUST be specified if a qop parameter is sent (see above), and
MUST NOT be specified if the server did not send a qop parameter MUST NOT be specified if the server did not send a qop parameter
in the WWW-Authenticate header field. The cnonce value is an in the WWW-Authenticate header field. The cnonce value is an
opaque quoted string value provided by the client and used by both opaque quoted string value provided by the client and used by both
client and server to avoid chosen plaintext attacks, to provide client and server to avoid chosen plaintext attacks, to provide
mutual authentication, and to provide some message integrity mutual authentication, and to provide some message integrity
protection. See the descriptions below of the calculation of the protection. See the descriptions below of the calculation of the
rspauth and response values. rspauth and response values.
nc nc
skipping to change at page 10, line 26 skipping to change at page 10, line 21
If the "qop" value is "auth" or "auth-int": If the "qop" value is "auth" or "auth-int":
response = <"> < KD ( H(A1), unq(nonce) response = <"> < KD ( H(A1), unq(nonce)
":" nc ":" nc
":" unq(cnonce) ":" unq(cnonce)
":" unq(qop) ":" unq(qop)
":" H(A2) ":" H(A2)
) <"> ) <">
If the "qop" parameter is not present (this construction is for
compatibility with RFC 2069):
response =
<"> < KD ( H(A1), unq(nonce) ":" H(A2) ) > <">
See below for the definitions for A1 and A2. See below for the definitions for A1 and A2.
3.4.2 A1 3.4.2 A1
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
skipping to change at page 11, line 47 skipping to change at page 11, line 36
of "true" in the WWW-Authentication header. of "true" in the WWW-Authentication header.
If the client supports the "userhash" parameter, and the "userhash" If the client supports the "userhash" parameter, and the "userhash"
parameter value in the WWW-Authentication header is set to "true", parameter value in the WWW-Authentication header is set to "true",
then the client MUST calculate a hash of the username after any other then the client MUST calculate a hash of the username after any other
hash calculation and include the "userhash" parameter with the value hash calculation and include the "userhash" parameter with the value
of "true" in the Authorization Request Header. If the client does not of "true" in the Authorization Request Header. If the client does not
provide the "username" as a hash value or the "userhash" parameter provide the "username" as a hash value or the "userhash" parameter
with the value of "true", the server MAY reject the request. with the value of "true", the server MAY reject the request.
The server may change the nonce value, so the client should be ready
to recalculate the hashed username.
The following is the operation that the client will take to hash the The following is the operation that the client will take to hash the
username: username:
username = H( H( unq(username) ":" unq(realm) ) ":" unq(nonce) ) 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 includes the fields string A1. Thus if the Authorization header includes the fields
username="Mufasa", realm=myhost@testrealm.com username="Mufasa", realm=myhost@testrealm.com
skipping to change at page 16, line 38 skipping to change at page 16, line 38
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.
When a server receives a request to access a resource, the server When a server receives a request to access a resource, the server
might challenge the client by responding with "401 Unauthorized" might challenge the client by responding with "401 Unauthorized"
status code, and include one or more WWW-Authenticate headers. If the status code, and include one or more WWW-Authenticate headers. If the
server challenges with multiple Digest headers, then each one of server challenges with multiple Digest headers, then each one of
these headers MUST use a different digest algorithm. The server MUST these headers MUST use a different digest algorithm. The server MUST
add these Digest headers to the response in order of preference, add these Digest headers to the response in order of preference,
starting with the most preferred header, followed by the less starting with the most preferred header, followed by the less
preferred headers. The preference of the algorithms is defined in the preferred headers.
IANA registry of the various algorithms as defined in section 6.1.
This specification defines the following preference list, starting
with the most preferred algorithm:
* SHA2-256
* SHA2-512/256
* MD5 (for backward compatibility).
When the client receives the response it SHOULD use the topmost When the client receives the response it SHOULD use the topmost
header that it supports, unless a local policy dictates otherwise. header that it supports, unless a local policy dictates otherwise.
The client should ignore any challenge it does not understand. The client should ignore any challenge it does not understand.
3.8 Proxy-Authenticate and Proxy-Authorization 3.8 Proxy-Authenticate and Proxy-Authorization
The digest authentication scheme may also be used for authenticating The digest authentication scheme may 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 headers. These use of the Proxy-Authenticate and Proxy-Authorization headers. These
skipping to change at page 20, line 24 skipping to change at page 20, line 29
839e4f3d2ffeb82517", 839e4f3d2ffeb82517",
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
indicating that the server expects the UTF-8 character encoding to be (see [RFC2978], Section 2.3). It indicates that the server expects
used ([RFC3629]). user name and password to be converted to Unicode Normalization Form
C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
using the UTF-8 character encoding scheme ([RFC3629]).
If the user agent does not support the encoding indicated by the If the user agent does not support the encoding indicated by the
server, it MUST fail the request. server, it MUST fail the request.
5 Security Considerations 5 Security Considerations
5.1 Limitations 5.1 Limitations
HTTP Digest authentication, when used with human-memorable passwords, HTTP Digest authentication, when used with human-memorable passwords,
is vulnerable to dictionary attacks. Such attacks are much easier is vulnerable to dictionary attacks. Such attacks are much easier
skipping to change at page 27, line 12 skipping to change at page 27, line 20
This specification creates a new IANA registry named "HTTP Digest This specification creates a new IANA registry named "HTTP Digest
Hash Algorithms". When registering a new hash algorithm, the Hash Algorithms". When registering a new hash algorithm, the
following information MUST be provided: following information MUST be provided:
o Hash Algorithm o Hash Algorithm
The textual name of the hash algorithm. The textual name of the hash algorithm.
o Digest Size o Digest Size
The size of the algorithm's output in hexadecimal characters. The size of the algorithm's output in hexadecimal characters.
o Preference
The preference of the algorithm, with 1.0 being the least
preferred. This is a real number to allow for future algorithms
to be added anywhere in the table.
o Reference o Reference
A reference to the specification that describes the new algorithm. A reference to the specification that describes the new algorithm.
The update policy for this registry shall be Specification Required. The update policy for this registry shall be Specification Required.
The initial registry will contain the following entries: The initial registry will contain the following entries:
Hash Algorithm Digest Size Preference Reference Hash Algorithm Digest Size Reference
-------------- ----------- ---------- --------- -------------- ----------- ---------
"MD5" 32 1.0 RFC XXXX "MD5" 32 RFC XXXX
"SHA-512-256" 64 2.0 RFC XXXX "SHA-512-256" 64 RFC XXXX
"SHA-256" 64 3.0 RFC XXXX "SHA-256" 64 RFC XXXX
Each one of the algorithms defined in the registry might have a -sess Each one of the algorithms defined in the registry might have a -sess
variant, e.g. MD5-sess, SHA-256-sess, etc. variant, e.g. MD5-sess, SHA-256-sess, etc.
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
skipping to change at page 28, line 20 skipping to change at page 28, line 24
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 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, and Martin Durst, Peter Saint-Andre, Michael Sweet, Daniel Stenberg,
Brett Tate for their careful review and comments. Brett Tate, Paul Leach, and Ilari Liusvaara for their careful review
and comments.
The authors would like to thank Jonathan Stoke, Nico Williams, Harry The authors would like to thank Jonathan Stoke, Nico Williams, Harry
Halpin, and Phil Hunt for their comments on the mailing list when Halpin, and Phil Hunt for their comments on the mailing list when
discussing various aspects of this document. discussing various aspects of this document.
The authors would like to thank Paul Kyzivat and Dale Worley for The authors would like to thank Paul Kyzivat and Dale Worley for
their careful review and feedback on some aspects of this document. their careful review and feedback on some aspects of this document.
8 References 8 References
8.1 Normative References 8.1 Normative References
[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
Procedures", BCP 19, RFC 2978, October 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 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
(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
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 [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", draft-ietf-
November 2013. httpbis-p1-messaging (Work in Progress), 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", draft-ietf-
November 2013. httpbis-p6-cache (Work in Progress), 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", draft-ietf-httpbis-p7-auth
2013. (Work in Progress), November 2013.
[BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
Work in Progress, September 2013. draft-ietf-httpauth-basicauth-enc (Work in Progress),
September 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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Authors' Addresses Authors' Addresses
Rifaat Shekh-Yusef (Editor) Rifaat Shekh-Yusef (Editor)
Avaya Avaya
 End of changes. 25 change blocks. 
72 lines changed or deleted 63 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/