draft-ietf-httpauth-digest-encoding-01.txt   draft-ietf-httpauth-digest-encoding-02.txt 
HTTPAuth Working Group R. Shekh-Yusef HTTPAuth Working Group R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 2617 (if approved) July 5, 2013 Updates: 2617 (if approved) July 7, 2013
Intended status: Experimental Intended status: Experimental
Expires: January 6, 2014 Expires: January 8, 2014
An Encoding Mechanism for HTTP Digest Authentication An Encoding Mechanism for HTTP Digest Authentication
draft-ietf-httpauth-digest-encoding-01 draft-ietf-httpauth-digest-encoding-02
Abstract Abstract
RFC2617 does not define how to treat non-ASCII characters with the RFC2617 does not define how to treat Unicode characters [UNICODE]
"Digest" scheme. This document defines an extension to the "Digest" outside the ASCII range [RFC20] with the "Digest" scheme. This
scheme, and a mechanism that would allow the client and server to document defines an extension to the "Digest" scheme, and a mechanism
negotiate the proper character encoding support. that enables the client and server to negotiate their support for the
UTF-8 [RFC3629] character encoding scheme.
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 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 The "charset" auth-param . . . . . . . . . . . . . . . . . . . 3 2 The "charset" auth-param . . . . . . . . . . . . . . . . . . . 3
3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 3.1 Server Behavior . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . . 4 3.2 Client Behavior . . . . . . . . . . . . . . . . . . . . . . 4
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1 Normative References . . . . . . . . . . . . . . . . . . . 5 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2 Informative References . . . . . . . . . . . . . . . . . . 5 7.1 Normative References . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1 Introduction 1 Introduction
RFC2617 does not define how to treat non-ASCII characters with the RFC2617 does not define how to treat Unicode characters [UNICODE]
"Digest" scheme. This document defines an extension to the "Digest" outside the ASCII range [RFC20] with the "Digest" scheme. This
scheme, and a mechanism that would allow the client and server to document defines an extension to the "Digest" scheme, and a mechanism
negotiate the proper character encoding support. that enables the client and server to negotiate their support for the
UTF-8 [RFC3629] character encoding scheme.
The encoding impacts the way the server and the user agent The encoding impacts the way the server and the user agent
concatenate the username-value, realm-value, and password when they concatenate the username-value, realm-value, and password when they
calculate A1, as defined in section 3.2.2.2 of RFC2617. calculate A1, as defined in section 3.2.2.2 of RFC2617.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Several terms used in this document are defined in [RFC6365] and
[UNICODE].
2 The "charset" auth-param 2 The "charset" auth-param
The "Digest" mechanism allows for new parameters to be defined and The "Digest" mechanism allows for new parameters to be defined and
used with Authenticate and Authorization requests. This document used with Authenticate and Authorization headers. This document
defines a new optional "charset" auth-param that could be used by the defines a new optional "charset" auth-param that could be used by the
client and the server to indicate the encoding scheme they support. client and the server to indicate the encoding scheme they support.
The only allowed value is "UTF-8", to be matched case-insensitively. The only allowed value is "UTF-8", to be matched case-insensitively.
3 Mechanism 3 Mechanism
When a user agent attempts to access a resource and get challenged by When a user agent attempts to access a resource and get challenged by
the server, the server will indicate it supported encoding scheme, the server, the server will indicate it supported encoding scheme,
and in response the user agent will indicate whether it supports that and in response the user agent will indicate whether it supports that
encoding scheme or not in the subsequent request it sends to the encoding scheme or not in the subsequent request it sends to the
server. server.
3.2.1 Server Behavior 3.1 Server Behavior
In challenges, servers MAY use the "charset" authentication parameter In challenges, servers MAY use the "charset" authentication parameter
(case-insensitive) to express the character encoding they expect the (case-insensitive) to express the character encoding they expect the
user agent to use. user agent to use.
When the server receives the subsequent request with the Proxy- When the server receives the subsequent request with the Proxy-
Authenticate or WWW-Authenticate header fields, it looks for the Authenticate or WWW-Authenticate header fields, it looks for the
"charset" parameter. If the "charset" parameter is present, and its "charset" parameter. If the "charset" parameter is present, and its
value matches the encoding the server sent to the client, the server value matches the encoding the server sent to the client, the server
will continue with its normal operation using the encoding it sent to will continue with its normal operation using the encoding it sent to
the client. If, on the other hand, the "charset" parameter value is the client. If, on the other hand, the "charset" parameter value is
preceded by an exclamation point (!), the server can immediately preceded by an exclamation point (!), the server can immediately
decline the request. decline the request.
If the new request with the Proxy-Authenticate or WWW-Authenticate If the new request with the Proxy-Authenticate or WWW-Authenticate
header fields does not have the "charset" parameter, the server will header fields does not have the "charset" parameter, the server will
know that it is dealing with a client that does not support this know that it is dealing with a client that does not support this
specification and should continue to perform its current operation. specification and should continue to perform its current operation.
3.2.2 Client Behavior 3.2 Client Behavior
A user agent that follows this specifications MUST NOT include the A user agent that follows this specifications MUST NOT include the
"charset" parameter in any subsequent request if it did not receive "charset" parameter in any subsequent request if it did not receive
it from the server in a challenge. it from the server in a challenge.
If the user agent supports the encoding indicated by the server, it If the user agent supports the encoding indicated by the server, it
SHOULD add the "charset" parameter, with the value it received from SHOULD add the "charset" parameter, with the value it received from
the server, to the Proxy-Authenticate or WWW-Authenticate header the server, to the Proxy-Authenticate or WWW-Authenticate header
fields it sends back to the server. fields it sends back to the server.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
parameter and will not include it in any subsequent request. parameter and will not include it in any subsequent request.
4 Security Considerations 4 Security Considerations
<Security considerations text> <Security considerations text>
5 IANA Considerations 5 IANA Considerations
<IANA considerations text> <IANA considerations text>
6 References 6 Acknowledgments
6.1 Normative References The author would like to thank Julian Reschke for his help and
comments on and off the list, and for the idea of using the "auth-
param" to indicate the supported encoding, as described in his
document that deals with the encoding for the Basic scheme.
The author would also like to thank Bjoern Hoehrmann, Paul Hoffman,
and Martin Durst for their comments on the mailing list, and Peter
Saint-Andre for his comments and text that clarified the scope of the
document.
7 References
7.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.
[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 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC6365] Hoffman, P., Klensin, J., "Terminology Used in
Internationalization in the IETF", BCP: 166, RFC 6365,
September 2011.
[UNICODE] The Unicode Consortium, "The Unicode Standard,
Version 6.0".
<http://www.unicode.org/versions/Unicode6.0.0/>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
October 1969.
Authors' Addresses 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
 End of changes. 14 change blocks. 
23 lines changed or deleted 52 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/