idnits 2.17.1 draft-ietf-httpauth-digest-encoding-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([UNICODE], [RFC20], [RFC3629]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2617, but the abstract doesn't seem to directly say this. It does mention RFC2617 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2617, updated by this document, for RFC5378 checks: 1997-12-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2013) is 3947 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2617' is defined on line 175, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth Working Group R. Shekh-Yusef 3 Internet-Draft Avaya 4 Updates: 2617 (if approved) July 7, 2013 5 Intended status: Experimental 6 Expires: January 8, 2014 8 An Encoding Mechanism for HTTP Digest Authentication 9 draft-ietf-httpauth-digest-encoding-02 11 Abstract 13 RFC2617 does not define how to treat Unicode characters [UNICODE] 14 outside the ASCII range [RFC20] with the "Digest" scheme. This 15 document defines an extension to the "Digest" scheme, and a mechanism 16 that enables the client and server to negotiate their support for the 17 UTF-8 [RFC3629] character encoding scheme. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 The "charset" auth-param . . . . . . . . . . . . . . . . . . . 3 60 3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1 Server Behavior . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2 Client Behavior . . . . . . . . . . . . . . . . . . . . . . 4 63 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1 Normative References . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1 Introduction 72 RFC2617 does not define how to treat Unicode characters [UNICODE] 73 outside the ASCII range [RFC20] with the "Digest" scheme. This 74 document defines an extension to the "Digest" scheme, and a mechanism 75 that enables the client and server to negotiate their support for the 76 UTF-8 [RFC3629] character encoding scheme. 78 The encoding impacts the way the server and the user agent 79 concatenate the username-value, realm-value, and password when they 80 calculate A1, as defined in section 3.2.2.2 of RFC2617. 82 1.1 Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 Several terms used in this document are defined in [RFC6365] and 89 [UNICODE]. 91 2 The "charset" auth-param 93 The "Digest" mechanism allows for new parameters to be defined and 94 used with Authenticate and Authorization headers. This document 95 defines a new optional "charset" auth-param that could be used by the 96 client and the server to indicate the encoding scheme they support. 98 The only allowed value is "UTF-8", to be matched case-insensitively. 100 3 Mechanism 102 When a user agent attempts to access a resource and get challenged by 103 the server, the server will indicate it supported encoding scheme, 104 and in response the user agent will indicate whether it supports that 105 encoding scheme or not in the subsequent request it sends to the 106 server. 108 3.1 Server Behavior 110 In challenges, servers MAY use the "charset" authentication parameter 111 (case-insensitive) to express the character encoding they expect the 112 user agent to use. 114 When the server receives the subsequent request with the Proxy- 115 Authenticate or WWW-Authenticate header fields, it looks for the 116 "charset" parameter. If the "charset" parameter is present, and its 117 value matches the encoding the server sent to the client, the server 118 will continue with its normal operation using the encoding it sent to 119 the client. If, on the other hand, the "charset" parameter value is 120 preceded by an exclamation point (!), the server can immediately 121 decline the request. 123 If the new request with the Proxy-Authenticate or WWW-Authenticate 124 header fields does not have the "charset" parameter, the server will 125 know that it is dealing with a client that does not support this 126 specification and should continue to perform its current operation. 128 3.2 Client Behavior 130 A user agent that follows this specifications MUST NOT include the 131 "charset" parameter in any subsequent request if it did not receive 132 it from the server in a challenge. 134 If the user agent supports the encoding indicated by the server, it 135 SHOULD add the "charset" parameter, with the value it received from 136 the server, to the Proxy-Authenticate or WWW-Authenticate header 137 fields it sends back to the server. 139 If the user agent does not support the encoding indicated by the 140 server, it SHOULD add the "charset" parameter to the Proxy- 141 Authenticate or WWW-Authenticate header fields it sends back to the 142 server, but the value in the parameter should be preceded by an 143 exclamation point (!). 145 A user agent that does not follow this specification will ignore the 146 parameter and will not include it in any subsequent request. 148 4 Security Considerations 150 152 5 IANA Considerations 154 156 6 Acknowledgments 158 The author would like to thank Julian Reschke for his help and 159 comments on and off the list, and for the idea of using the "auth- 160 param" to indicate the supported encoding, as described in his 161 document that deals with the encoding for the Basic scheme. 163 The author would also like to thank Bjoern Hoehrmann, Paul Hoffman, 164 and Martin Durst for their comments on the mailing list, and Peter 165 Saint-Andre for his comments and text that clarified the scope of the 166 document. 168 7 References 170 7.1 Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 176 Leach, P., Luotonen, A., and L. Stewart, "HTTP 177 Authentication: Basic and Digest Access Authentication", 178 RFC 2617, June 1999. 180 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 181 10646", STD 63, RFC 3629, November 2003. 183 [RFC6365] Hoffman, P., Klensin, J., "Terminology Used in 184 Internationalization in the IETF", BCP: 166, RFC 6365, 185 September 2011. 187 [UNICODE] The Unicode Consortium, "The Unicode Standard, 188 Version 6.0". 189 . 191 [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, 192 October 1969. 194 Authors' Addresses 196 Rifaat Shekh-Yusef 197 Avaya 198 250 Sydney Street 199 Belleville, Ontario 200 Canada 202 Phone: +1-613-967-5267 203 Email: rifaat.ietf@gmail.com