idnits 2.17.1 draft-johansson-http-tls-cb-02.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 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 18, 2007) is 5966 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4234' is defined on line 301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2910 (Obsoleted by RFC 8010) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Johansson 3 Internet-Draft SU 4 Intended status: Standards Track November 18, 2007 5 Expires: May 21, 2008 7 Channel bindings for HTTP+TLS transport 8 draft-johansson-http-tls-cb-02 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/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies a channel concept for HTTP with TLS and a 42 representation of that channel which can be used by protocols which 43 use channel bindings to delegate session protection to lower layers. 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction and motivation . . . . . . . . . . . . . . . . . 4 49 3. The HTTP+TLS Channel . . . . . . . . . . . . . . . . . . . . . 5 50 4. Discovery of the channel-bindings-proxy . . . . . . . . . . . 6 51 5. The Channel-Bindings-Proxy header . . . . . . . . . . . . . . 7 52 6. The Channel-Identifier header . . . . . . . . . . . . . . . . 8 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 54 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 56 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 10.1. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 13 58 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 59 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 60 11.2. Informative References . . . . . . . . . . . . . . . . . 14 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 Intellectual Property and Copyright Statements . . . . . . . . . . 16 64 1. Terminology 66 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" 67 and "MAY" that appear in this document are to be interpreted as 68 described in [RFC2119] 70 2. Introduction and motivation 72 For good or bad, several protocols use HTTP (or close approximations 73 as in the case of [RFC2910]) as a transport mechanisms and often rely 74 on [RFC2817] or [RFC2818] to provide security. Common security 75 requirements include authentication of the service, of the client and 76 protection of the session. It is not always appropriate to meet 77 these requirements using the same technology. For instance, the use 78 of certificates to authenticate users may be inefficient in an 79 enviroment where [RFC4120] is widely deployed while at the same time 80 certificates may be suitable for authenticating the service. 82 Channel bindings described in [RFC5056] provide a mechanism for 83 delegating session protection to a secure channel at a lower layer. 84 In this case the lower layer is HTTP with TLS either using [RFC2817] 85 or [RFC2818]. This document specifies this channel concept in a form 86 which makes it usable to upper layer protocols which can consume 87 channel bindings. 89 3. The HTTP+TLS Channel 91 In general an HTTP connection consists of a series of (non-proxied) 92 HTTP connections between a client, through a series of client-proxies 93 with a server. The server may also use proxies (for instance 94 concentrators) but that fact does not affect this specification. 96 Each client/proxy in the chain either knows that the next hop is 97 another proxy (by virtue of configuration or discovery) or has no 98 knowledge of another proxy in which case the next hop in the chain by 99 definition is the target endpoint or an imposter impersonating the 100 target endpoint. 102 The following figure illustrates the general case: 104 C --> P0 --> P1 ===> SP --> S 106 Here C is the client and S is the server. In between, P0 and P1 107 represents client proxies and SP represents a server SSL concentrator 108 (i.e. a server proxy). Both protected (TLS) and unprotected 109 connections may occur. In this figure the connection between P1 and 110 SP has been emphasized for reasons which will be explained below. 112 An HTTP+TLS channel is defined as an HTTP connection where at least 113 the connection from the last client proxy to the target endpoint uses 114 TLS either through [RFC2818] or [RFC2817]. The last client proxy is 115 called the channel-binding-proxy and is given a special role in this 116 specification. Note that in the non-proxied case an HTTP+TLS channel 117 is just a normal TLS-protected HTTP connection. This document 118 specifies a way to identify such channels for the purpouse of channel 119 bindings. 121 In the example case the connection representing the channel to be 122 identified is the one illustrated by the second (===>) arrow from the 123 left.. This is the link which leaves the client proxy chain and 124 hence leaves the client trust domain. The channel-binding-proxy in 125 this case would be P1. 127 In order to be used by protocols consuming channel bindings, an HTTP+ 128 TLS channel must be identified by a value which can be observed by 129 the client or the channel-binding-proxy on behalf of the client. 131 The identifier for the channel is defined to be the hash of the 132 endpoint certificate using the digest algorithm from the certificate, 133 also known as a certificate fingerprint. In the non-proxied case the 134 client has direct access to the endpoint certificate and can compute 135 the fingerprint. In the general case the channel-binding-proxy has 136 access to the certifiate and is able to communicate it to the client. 138 4. Discovery of the channel-bindings-proxy 140 It is desirable for a client to be able to discover the existence of 141 a channel-bindings-proxy somewhere in its proxy-chain. In order to 142 accomplish this the client needs a method to inquire the the first 143 proxy in the chain if it knows if there is a channel-binding-proxy in 144 the chain. By either forwarding the request or (if the proxy is a 145 channel-bindings-proxy or has no knowledge about an upstream proxy) 146 answering it the proxy can inform the client about the existence or 147 absense of a channel-bindings-proxy in the chain. 149 Unfortunately this client-request cannot be implemented using a 150 request-header since there are no widely implemented request-headers 151 which are handled by proxies except for the Proxy-Authentication and 152 Proxy-Authorization headers which are not possible to reuse for this 153 application. 155 Instead the OPTIONS verb is used in the following way: The client 156 sends an OPTIONS request for the Request-URI "*" as per [RFC2616] 157 section 9.2 with Max-Forwards set to "0". As specified in [RFC2616] 158 a proxy is required to respond to this message itself rather than 159 forward it upstream. A proxy implementing this specification that is 160 configured as a channel-bindings-proxy MUST include a Channel- 161 Bindings-Proxy header (cf below) in the response. Each proxy sitting 162 between the client and the channel-bindings-proxy MUST re-issue any 163 OPTIONS request received this awy and include any Channel-Identifier 164 header received in the response-message to the client/proxy. Upon 165 receipt of the (final) response-message the client may (if the 166 message contains a Channel-Bindings-Proxy header) assume that the 167 proxy-chain contains a channel-bindings-proxy implementing this 168 specification. 170 Note well that this mechanism does not violate the intent of the 171 treatment of the Max-Forwards since the semantics of the Channel- 172 Bindings-Proxy is that the proxy has knowledge about a channel- 173 bindings-proxy somewhere in the proxy-chain (including the proxy 174 itself). 176 5. The Channel-Bindings-Proxy header 178 Information about the channel-bindings-proxy used in the discovery 179 process described above is represented by new the HTTP/1.1 header 180 'Channel-Bindings-Proxy' which contains the hostname of the channel- 181 bindings-proxy. 183 6. The Channel-Identifier header 185 An HTTP+TLS channel is represented as a new HTTP/1.1 header 'Channel- 186 Identifier' which contains the representation of the HTTP+TLS 187 channel. The 'Channel-Identifier' header has the following syntax in 188 Augmented BNF defined in [RFC2616]: 190 channel-identifier = hash-function *(SP channel-value) 191 hash-function = token 192 channel-value = 2HEX *(":" 2HEX) 193 ; a hex-encoded sequence of bytes 194 ; separated by colons of length > 0 196 The definitions of HEX, token and SP are taken from [RFC2616]. 198 An HTTP proxy implementing this specification MUST NOT modify the 199 Channel-Identifier header unless explicitly configured to act as a 200 channel-bindings-proxy. A proxy configured as a channel-bindings- 201 proxy MUST for each TLS-protected HTTP connection add the Channel- 202 Identifier header to each received response-message. 204 A client implementing this specification MUST NOT accept or use the 205 Channel-Identifier header unless it has established that the proxy- 206 chain ends in a channel-bindings-proxy. Clients MUST support manual 207 configuration for the existence of a channel-bindings-proxy and 208 SHOULD support discovery as specified in the previous section. Other 209 mechanisms for discovering the existance of a channel-bindings-proxiy 210 may be specified in the future. 212 The client MUST NOT assume knowledge about which proxy is acting as 213 the channel-bindings-proxy. If the client does not have a proxy the 214 client may compute the Channel-Identifier header value given direct 215 access to the endpoint certificate. The client MUST NOT compute or 216 use the Channel-Identifier header value if it has a known proxy-chain 217 which does not include a channel-bindings-proxy. 219 When a client receives a reply message with a Channel-Identifier 220 header the client may use this as input to an upper-layer 221 authentication protocol which consumes channel-bindings. This means 222 that if the Channel-Identifier header changes the upper-layer 223 protocol will detect this change as a man-in-the middle attack and 224 the client MUST terminate the connection to the server. Clients MAY 225 cache channel-identifier/endpoint pairs. 227 The first time a client communicates with a target endpoint it has no 228 channel-identifier to bind authentication protocols to. In several 229 situations the first communication between a client and a server 230 results in an authentication mechanism negotiation challange from the 231 server at which point the channel-binding-proxy (or the client 232 itself) will have a channel-identifier to use for the first 233 authentication mechanism challenge. 235 If the client has a cached channel-identifier for an endpoint the 236 client SHOULD include the Channel-Identifier header in each outgoing 237 request. This gives the channel-binding-proxy the oportunity to 238 determine if response packets contain a forged channel-identifier and 239 may decide to terminate such connections at the proxy. 241 7. Security Considerations 243 There are several situations when the client has no knowledge of 244 proxies intercepting traffic. Such proxies are essentially man-in- 245 the-middle attacks but are also in many cases implicitly part of the 246 trust-domain of the client. In the case when the hidden proxy sits 247 between the client and the channel-bindings-proxy and does not alter 248 the Channel-Identifier header it does not matter. In deployments 249 where the last client proxy does not support the channel-bindings- 250 proxy feature it may be necessary to add another proxy outside this 251 proxy which can act as the channel-bindings-proxy. 253 The basic principle of the Channel-Bindings header is that it 254 contains data which is either observed and verified or computed by a 255 trusted proxy between the client and server. By replacing this 256 header value another proxy effectively moves the endpoint of the 257 channel. By using the header value as channel binding data for upper 258 layer authentication protocols the client effectively trusts the 259 proxy setting the value. 261 It is very imporant that a proxy configured to act as a channel- 262 bindings-proxy actually sets the Channel-Identifier header. A rogue 263 or non-functional channel-bindings-proxy which announces the channel- 264 bindings-feature but fails to provide or even filter-out the header 265 will make the client vulnerable to attack. Clients mayll wish to use 266 proxy authentication to identify trusted proxies. 268 8. Notes 270 What about TLS mechs besides X.509? This "only" requires finding 271 something which corresponds to the certificate fingerprint: i.e 272 something which can be computed by the client and the server together 273 or observed independently by the client. 275 9. IANA Considerations 277 Allocating the Channel-Identifier header. 279 10. Changes 281 10.1. 01 to 02 283 Changed from ABNF to Augmented BNF to align with [RFC2616]. 285 11. References 287 11.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 293 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 294 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 296 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 297 HTTP/1.1", RFC 2817, May 2000. 299 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 301 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 302 Specifications: ABNF", RFC 4234, October 2005. 304 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 305 Channels", RFC 5056, November 2007. 307 11.2. Informative References 309 [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. 310 Wenn, "Internet Printing Protocol/1.1: Encoding and 311 Transport", RFC 2910, September 2000. 313 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 314 Kerberos Network Authentication Service (V5)", RFC 4120, 315 July 2005. 317 Author's Address 319 Leif Johansson 320 Stockholm university 322 Email: leifj@it.su.se 323 URI: http://www.su.se/ 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2007). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).