draft-ietf-httpauth-digest-update-00.txt   draft-ietf-httpauth-digest-update-01.txt 
HTTPAuth Working Group R. Shekh-Yusef HTTPAuth Working Group R. Shekh-Yusef
Internet-Draft D. Ahrens Internet-Draft D. Ahrens
Updates: 2617 (if approved) Avaya Updates: 2617 (if approved) Avaya
Intended Status: Standards Track June 10, 2013 Intended Status: Standards Track June 22, 2013
Expires: December 12, 2013 Expires: December 24, 2013
HTTP Digest Update HTTP Digest Update
draft-ietf-httpauth-digest-update-00 draft-ietf-httpauth-digest-update-01
Abstract Abstract
This documents specifies extensions to the HTTP Digest Authentication This documents specifies extensions to the HTTP Digest Authentication
mechanism to add support for more digest algorithms to the HTTP mechanism to add support for new digest algorithms to the HTTP Digest
Digest Access Authentication scheme. Access Authentication scheme.
This document also specifies an extension to HTTP Digest
Authentication mechanism to allow the server to indicate its
character encoding support.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 29 skipping to change at page 2, line 25
2 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3 2 Digest Access Authentication Scheme . . . . . . . . . . . . . . 3
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Representation of digest values . . . . . . . . . . . . 3 2.1.1 Representation of digest values . . . . . . . . . . . . 3
2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4 2.2 Specification of Digest Headers . . . . . . . . . . . . . . 4
2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4 2.2.1 The WWW-Authenticate Response Header . . . . . . . . . . 4
2.2.2 The Authorization Request Header . . . . . . . . . . . . 5 2.2.2 The Authorization Request Header . . . . . . . . . . . . 5
2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6 2.4 Security Protocol Operation . . . . . . . . . . . . . . . . 6
2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Internationalization . . . . . . . . . . . . . . . . . . . . . 7 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Normative References . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 5.2 Informative References . . . . . . . . . . . . . . . . . . 8
6.2 Informative References . . . . . . . . . . . . . . . . . . 9 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
1 Introduction 1 Introduction
This document updates two aspects of the HTTP Digest mechanism
specified in RFC2617: Algorithm agility, and character set
internationalization.
This document specifies extensions to the HTTP Digest Access This document specifies extensions to the HTTP Digest Access
Authentication scheme by adding support for the SHA1 and SHA2 suite Authentication scheme by adding support for the SHA1 and SHA2 suite
of hash algorithms. RFC 2617 specifies the MD5 algorithm as the of hash algorithms [FIPS186-3]. RFC2617 specifies the MD5 algorithm
default hash algorithm used in the digest access authentication as the default hash algorithm used in the digest access
scheme. Since RFC 2617 was first proposed, the MD5 algorithm has authentication scheme. Since RFC2617 was first proposed, the MD5
been broken. In 2008 the US-CERT issued a note that MD5 "should be algorithm has been broken. In 2008 the US-CERT issued a note that
considered cryptographically broken and unsuitable for further use." MD5 "should be considered cryptographically broken and unsuitable for
further use" [CERT-VU].
RFC2617 does not define how to treat non-ASCII characters with the
"Basic" and "Digest" schemes. This has lead to interoperability
problems between user agents and proxies.
This document specifies an extension to HTTP Digest Authentication
mechanism to allow the server to indicate its character encoding
support.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
2 Digest Access Authentication Scheme 2 Digest Access Authentication Scheme
The Digest Access Authentication scheme is based on a simple The Digest Access Authentication scheme is based on a simple
challenge-response paradigm. The Digest scheme challenges using a challenge-response paradigm. The Digest scheme challenges using a
nonce value. A valid response contains a checksum of the username, nonce value. A valid response contains a checksum of the username,
the password, the given nonce value and the requested URI. In this the password, the given nonce value and the requested URI. In this
way the password is never sent in the clear. way the password is never sent in the clear.
2.1 Introduction 2.1 Introduction
skipping to change at page 6, line 38 skipping to change at page 6, line 29
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. preferred headers.
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.
2.5 Example 2.5 Example
The following example is borrowed from RFC 2617 and assumes that an The following example is borrowed from RFC2617 and assumes that an
access protected document is being requested from the server via a access protected document is being requested from the server via a
GET request. The URI of the document is GET request. The URI of the document is
http://www.nowhere.org/dir/index.html". Both client and server know http://www.nowhere.org/dir/index.html". Both client and server know
that the username for this document is "Mufasa" and the password is that the username for this document is "Mufasa" and the password is
"Circle of Life" ( with one space between each of the three words). "Circle of Life" ( with one space between each of the 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:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
skipping to change at page 7, line 35 skipping to change at page 7, line 26
realm="testrealm@host.com" realm="testrealm@host.com"
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html", uri="/dir/index.html",
qop=auth, qop=auth,
algorithm="MD5" algorithm="MD5"
nc=00000001, nc=00000001,
cnonce="0a4f113b", cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
3 Internationalization 3 Security Considerations
In challenges, servers MAY use the "accept-charset" authentication
parameter (case-insensitive) to express the character encoding they
expect the user agent to use.
If the user agent supports the encoding indicated by the server, it
SHOULD add the "accept-charset" parameter, with the value it received
from the server, to the Proxy-Authenticate or WWW-Authenticate header
fields it sends back to the server.
If the user agent does not support the encoding indicated by the
server, it SHOULD add the "accept-charset" parameter to the Proxy-
Authenticate or WWW-Authenticate header fields it sends back to the
server, but the value in the parameter should be preceded by an
exclamation point (!).
A user agent that does not follow this specification will ignore the
parameter and will not include it in any response to the server.
When the server receives the new request with the Proxy-Authenticate
or WWW-Authenticate header fields, it looks for the "accept-charset"
parameter. If the "accept-charset" parameter is present, and its
value matches the encoding the server sent to the client, the server
will continue with its normal operation using the encoding it sent to
the client. If, on the other hand, the "accept-charset" parameter
value is preceded by an exclamation point (!), the server can
immediately decline the request.
If the new request with the Proxy-Authenticate or WWW-Authenticate
header fields does not have the "accept-charset" parameter, the
server will know that it is dealing with a client that does not
support this specification and should continue to perform its current
operation.
The encoding indicated by the server impacts the way the server and
the user agent concatenate the username-value, realm-value, and
password when they calculate A1, as defined in section 3.2.2.2 of
RFC2617.
4 Security Considerations
This specification updates the Digest Access Authentication scheme This specification updates the Digest Access Authentication scheme
specified in RFC 2617 to add support for the SHA1 and SHA2 algorithm specified in RFC2617 to add support for the SHA1 and SHA2 algorithm
suites. Support for these additional hash algorithms does not alter suites. Support for these additional hash algorithms does not alter
the security properties of the Digest Access Authentication scheme. the security properties of the Digest Access Authentication scheme.
5 Acknowledgments 4 Acknowledgments
The authors would like to thank Geoff Baskwill and Eric Cooper for The authors would like to thank Geoff Baskwill and Eric Cooper for
their careful review and comments. their careful review and comments on the pre published version of
this document.
6 References The authors would also like to thank Stephen Farrell, Yoav Nir,
Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Julian Reschke, and
Sean Turner for their careful review and comments on and off the
mailing list.
6.1 Normative References 5 References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 5.1 Normative References
[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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
6.2 Informative References 5.2 Informative References
7 Authors' Addresses
[FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard, June 2009.
[CERT-VU] Vulnerability Note VU#836068, MD5 vulnerable to collision
attacks, December 2008.
6 Authors' Addresses
Rifaat Shekh-Yusef Rifaat Shekh-Yusef
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: rifatyu@avaya.com Email: rifatyu@avaya.com
 End of changes. 16 change blocks. 
84 lines changed or deleted 41 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/