idnits 2.17.1 draft-santesson-digestbind-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 288. 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 ([2617]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 2008) is 5762 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Stefan Santesson (Microsoft) 3 Intended Status: Informational Kevin Damour (Microsoft) 4 Phil Hallin (Microsoft) 5 Expires January 2009 July 2008 7 Channel binding for HTTP Digest Authentication 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies a method implemented by Microsoft to add 36 channel binding capabilities to the http digest protocol defined in 37 RFC 2617 [2617] 39 1. Introduction 41 This specification document Microsoft's existing implementation of 42 TLS endpoint channel binding and service binding for http digest 43 Authentication. 45 The primary purpose of this feature is to safeguard resources against 46 authentication forwarding attacks. 48 Authentication forwarding is possible when http digest authentication 49 takes place inside an outer secure channel (e.g. TLS). In this case, 50 there is no binding between the inner channel session key and the 51 outer channel session key. This specification defines a way to 52 exchange necessary channel binding data for the outer channel within 53 http digest authentication. 55 This specification expands the defined set of authentication 56 parameters defined in RFC 2617 [2617] for the Authorization request 57 header, when used with digest authentication. The semantics of server 58 and client nonce are expanded to facilitate negotiation of channel 59 binding. 61 1.1 Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [2119]. 67 2. Protocol syntax 69 Channel binding is provided through amendments to the WWW- 70 Authenticate Response Header sent by the server and the Authorization 71 Request Header returned by the client, both defined in RFC 2616 72 [2616]. 74 Authentication parameters (directives) defined in this specification, 75 are defined within the auth-param syntax defined in RFC 2617 [2617]: 77 auth-param = token "=" ( token | quoted-string ) 79 2.1 WWW-Authenticate Response Header 81 The WWW-Authenticate Response Header sent by the server MUST be 82 formed according to RFC 2617 [2617] section 3.2.1, with the 83 amendments specified in this section. 85 nonce 86 A server signals that it supports channel binding according to 87 this specification by invoking the following 12 characters in the 88 server nonce: 90 "+UpGrAdEd+v1" 92 As the nonce directive is present, the qop-options directive MUST be 93 present according to RFC 2617 [2617]. 95 This specification only supports channel binding when the outer 96 channel is TLS. 98 2.2 Authorization Request Header 100 The Authorization Request header sent by the client MUST be formed 101 according to RFC 2617 [2617] section 3.2.2, with the amendments 102 specified in this section. 104 digest-response is expanded with the following directives: 106 hashed-directives = "hashed-dirs" "=" <"> 1#token <"> 107 service-name = "service-name" "=" service-name-value 108 charset = "charset" "=" "utf-8" 109 channel-binding = <"> 32LHEX <"> 111 service-name-value is further defined as: 113 service-name-value = serv-type "/" host [ "/" serv-name ] 114 serv-type = 1*ALPHA 115 host = 1*( ALPHA | DIGIT | "-" | "." ) 116 serv-name = host 118 Definition of directive values: 120 cnonce 121 On the client side, an upgraded client recognizes the leading 122 "+UpGrAdEd+v1" string in the server nonce and interprets it to 123 mean that the server understands channel bindings according to 124 this specification. This extends the semantics from RFC 2617 125 [2617] where the nonce is defined to be opaque to the client, but 126 now conveys information from the server. If the client decides to 127 send channel binding information, it includes the same 128 "+UpGrAdEd+v1" prefix string at the beginning of the cnonce it 129 generates. The MD5 ASCII hex of the unquoted service-name and 130 channel-bindings directive values follows the upgraded prefix. 132 NOTE: Many existing client implementations ignores the "v1" part 133 of the "+UpGrAdEd+v1" string and would not notice the difference 134 if the string ended with "v2". This should be taken into 135 consideration if a version 2 of this protocol is defined. 137 hashed-directives 138 The names of the directives, which values are hashed and included 139 in the cnonce, provided as a quoted coma separated list. For 140 version 1 (v1) of this specification, this directive MUST contain 141 the following value: 143 hashed-dirs = "service-name,channel-binding" 145 service-name 146 The service-name directive is defined identically as the digest- 147 uri directive of RFC 2831 [2831]. All conventions defined for the 148 digest-uri directive in RFC 2831 apply also to this directive. 150 charset 151 This directive, if present, specifies that the server supports 152 UTF-8 encoding for the username and password. This directive and 153 conventions for its use are defined in RFC 2831 [2831]. 155 channel-binding 156 This directive carries the octets of a channel binding token as 157 defined in the IANA registry for Channel Binding Types, defined 158 under RFC 5056 [5056]. The selected channel binding type for 159 implementations of this specification MUST be "tls-server-end- 160 point" 162 3 IANA Considerations 164 TBD 166 4 Security Considerations 168 TBD 170 5 References 172 5.1 Normative References 174 [2119] S. Bradner, "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, 178 L. Masinter, P. Leach, T. Berners-Lee, "Hypertext 179 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 181 [2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, 182 P. Leach, A. Luotonen, L. Stewart, "HTTP Authentication: 183 Basic and Digest Access Authentication", RFC 2617, 184 June 1999. 186 [2831] P. Leach, C. Newman, "Using Digest Authentication as a 187 SASL Mechanism", RFC 2831, May 2000. 189 [5056] N. Williams, "On the Use of Channel Bindings to Secure 190 Channels", RFC 5056, November 2007. 192 5.2 Informative References 194 No informative references are listed. 196 Appendix A - Example 198 This is an example of a valid Authorization request header according 199 to this specification: 201 Authorization : Digest 202 username="administrator", 203 realm="jeremyv-dom2.nttest.example.com", 204 nonce="+UpGrAdEd+v137576ac1877be8fe5993f505e48dc801d89a9e0a3e430 205 9b4dd10177754546bf5db46ee3b77fcb6317f569396da0b53fa", 206 uri="/dir/index.html", 207 cnonce="+UpGrAdEd+v19f74f856d6b97542776f92fa6d6f3429eb5ffa78b385 208 313f954e9f2226246bd9", 209 nc=00000001, 210 algorithm=MD5-sess, 211 response="5da37a37d5b3867366f22133182f1ef4", 212 qop="auth", 213 charset=utf-8, 214 hashed-dirs="service-name,channel-binding", 215 service-name="TestServiceName/example.com", 216 channel-binding="8674d6ce56be991be9c7549735f179f4" 218 Editorial note: This example will be updated. It is syntactically 219 correct, but some hash values are not reflecting the actual values in 220 the example. 222 Authors' Addresses 224 Stefan Santesson 225 Microsoft 226 One Microsoft Way 227 Redmond, WA 98052 228 USA 230 EMail: stefans(at)microsoft.com 232 Kevin Damour 233 Microsoft 234 One Microsoft Way 235 Redmond, WA 98052 236 USA 238 EMail: kdamour(at)microsoft.com 240 Phil Hallin 241 Microsoft 242 One Microsoft Way 243 Redmond, WA 98052 244 USA 246 EMail: philh(at)microsoft.com 248 Copyright (C) The IETF Trust (2008). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 257 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 258 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 259 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 This document may not be modified, and derivative works of it may not 263 be created, except to publish it as an RFC and to translate it into 264 languages other than English. 266 Intellectual Property 268 The IETF takes no position regarding the validity or scope of any 269 Intellectual Property Rights or other rights that might be claimed to 270 pertain to the implementation or use of the technology described in 271 this document or the extent to which any license under such rights 272 might or might not be available; nor does it represent that it has 273 made any independent effort to identify any such rights. Information 274 on the procedures with respect to rights in RFC documents can be 275 found in BCP 78 and BCP 79. 277 Copies of IPR disclosures made to the IETF Secretariat and any 278 assurances of licenses to be made available, or the result of an 279 attempt made to obtain a general license or permission for the use of 280 such proprietary rights by implementers or users of this 281 specification can be obtained from the IETF on-line IPR repository at 282 http://www.ietf.org/ipr. 284 The IETF invites any interested party to bring to its attention any 285 copyrights, patents or patent applications, or other proprietary 286 rights that may cover technology that may be required to implement 287 this standard. Please address the information to the IETF at ietf- 288 ipr@ietf.org. 290 Expires January 2009