An Encoding Mechanism for HTTP Digest Authentication
draft-ietf-httpauth-digest-encoding-00

HTTPAuth Working Group                                    R. Shekh-Yusef
Internet-Draft                                                     Avaya
Updates: 2617 (if approved)                                 July 4, 2013
Intended status: Experimental                                           
Expires: January 5, 2014                                                

         An Encoding Mechanism for HTTP Digest Authentication 
                 draft-ietf-httpauth-digest-encoding-00

Abstract

   RFC2617 does not define how to treat non-ASCII characters with the
   "Digest" scheme. This document defines an extension to the "Digest"
   scheme, and two possible mechanisms that would allow the client and
   server to negotiate the proper character encoding support.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
 

Shekh-Yusef             Expires January 5, 2014                 [Page 1]
INTERNET DRAFT              <Document Title>                July 4, 2013

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 The "charset" auth-param . . . . . . . . . . . . . . . . . . . .  3
   3  Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1  Server Indicated Encoding Mechanism . . . . . . . . . . . .  3
     3.2  Negotiated Encoding Mechanism . . . . . . . . . . . . . . .  4
       3.2.1  Server Behavior . . . . . . . . . . . . . . . . . . . .  4
       3.2.2  Client Behavior . . . . . . . . . . . . . . . . . . . .  4
   4  Security Considerations . . . . . . . . . . . . . . . . . . . .  5
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  5
     6.2  Informative References  . . . . . . . . . . . . . . . . . .  5
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  5

 

Shekh-Yusef             Expires January 5, 2014                 [Page 2]
INTERNET DRAFT              <Document Title>                July 4, 2013

1  Introduction

   RFC2617 does not define how to treat non-ASCII characters with the
   "Digest" scheme. This document defines an extension to the "Digest"
   scheme, and two possible mechanisms that would allow the client and
   server to negotiate the proper character encoding support.

   The encoding 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.

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2 The "charset" auth-param

   The "Digest" mechanism allows for new parameters to be defined and
   used with Authenticate and Authorization requests. This document
   defines a new optional "charset" auth-param that could be used by the
   client and the server to indicate the encoding scheme they support.

3  Mechanisms

   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.

 

Shekh-Yusef             Expires January 5, 2014                 [Page 3]
INTERNET DRAFT              <Document Title>                July 4, 2013

3.2  Negotiated Encoding Mechanism

   When a user agent attempts to access a resource and get challenged by
   the server, the server will indicate it supported encoding scheme,
   and in response the user agent will indicate whether it supports that
   encoding scheme or not in the subsequent request it sends to the
   server.

3.2.1  Server Behavior

   In challenges, servers MAY use the "charset" authentication parameter
   (case-insensitive) to express the character encoding they expect the
   user agent to use.

   When the server receives the subsequent request with the Proxy-
   Authenticate or WWW-Authenticate header fields, it looks for the
   "charset" parameter. If the "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 "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 "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.

3.2.2  Client Behavior

   A user agent that follows this specifications MUST NOT include the
   "charset" parameter in any subsequent request if it did not receive
   it from the server in a challenge.

   If the user agent supports the encoding indicated by the server, it
   SHOULD add the "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 "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 subsequent request.
 

Shekh-Yusef             Expires January 5, 2014                 [Page 4]
INTERNET DRAFT              <Document Title>                July 4, 2013

4  Security Considerations

   <Security considerations text>

5  IANA Considerations

   <IANA considerations text>

6  References

6.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

6.2  Informative References

Authors' Addresses

   Rifaat Shekh-Yusef
   Avaya
   250 Sydney Street
   Belleville, Ontario
   Canada

   Phone: +1-613-967-5267
   Email: rifaat.ietf@gmail.com

Shekh-Yusef             Expires January 5, 2014                 [Page 5]