draft-ietf-httpauth-digest-encoding-00.txt   draft-ietf-httpauth-digest-encoding-01.txt 
HTTPAuth Working Group R. Shekh-Yusef HTTPAuth Working Group R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 2617 (if approved) July 4, 2013 Updates: 2617 (if approved) July 5, 2013
Intended status: Experimental Intended status: Experimental
Expires: January 5, 2014 Expires: January 6, 2014
An Encoding Mechanism for HTTP Digest Authentication An Encoding Mechanism for HTTP Digest Authentication
draft-ietf-httpauth-digest-encoding-00 draft-ietf-httpauth-digest-encoding-01
Abstract Abstract
RFC2617 does not define how to treat non-ASCII characters with the RFC2617 does not define how to treat non-ASCII characters with the
"Digest" scheme. This document defines an extension to the "Digest" "Digest" scheme. This document defines an extension to the "Digest"
scheme, and two possible mechanisms that would allow the client and scheme, and a mechanism that would allow the client and server to
server to negotiate the proper character encoding support. negotiate the proper 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 17 skipping to change at page 2, line 17
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Server Indicated Encoding Mechanism . . . . . . . . . . . . 3
3.2 Negotiated Encoding Mechanism . . . . . . . . . . . . . . . 4
3.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 3.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . . 4
3.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . . 4 3.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . . 4
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1 Normative References . . . . . . . . . . . . . . . . . . . 5 6.1 Normative References . . . . . . . . . . . . . . . . . . . 5
6.2 Informative References . . . . . . . . . . . . . . . . . . 5 6.2 Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Introduction 1 Introduction
RFC2617 does not define how to treat non-ASCII characters with the RFC2617 does not define how to treat non-ASCII characters with the
"Digest" scheme. This document defines an extension to the "Digest" "Digest" scheme. This document defines an extension to the "Digest"
scheme, and two possible mechanisms that would allow the client and scheme, and a mechanism that would allow the client and server to
server to negotiate the proper character encoding support. negotiate the proper character encoding support.
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].
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 requests. 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.
3 Mechanisms The only allowed value is "UTF-8", to be matched case-insensitively.
This section describes two possible mechanisms that could be used to
address this limitation.
3.1 Server Indicated Encoding Mechanism
NOTE: This is the same mechanism defined in draft-ietf-httpauth-
basicauth-enc draft.
In challenges, servers MAY use the "charset" authentication parameter
(case-insensitive) to express the character encoding they expect the
user agent to use.
The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3), indicating that the server expects the
UTF-8 character encoding to be used ([RFC3629]).
Other values are reserved for future use.
3.2 Negotiated Encoding 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.2.1 Server Behavior
In challenges, servers MAY use the "charset" authentication parameter In challenges, servers MAY use the "charset" authentication parameter
 End of changes. 9 change blocks. 
32 lines changed or deleted 12 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/