idnits 2.17.1 draft-balfanz-tls-channelid-01.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2013) is 3954 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) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 241, but not defined -- Looks like a reference, but probably isn't: '32' on line 259 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Balfanz 3 Internet-Draft R. Hamilton 4 Expires: December 31, 2013 Google Inc 5 June 29, 2013 7 Transport Layer Security (TLS) Channel IDs 8 draft-balfanz-tls-channelid-01 10 Abstract 12 This document describes a Transport Layer Security (TLS) extension 13 for identifying client machines at the TLS layer without using bearer 14 tokens. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 31, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Why not client certificates . . . . . . . . . . . . . . . . . 4 52 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 53 4. Channel ID Client Keys . . . . . . . . . . . . . . . . . . . . 7 54 5. Channel ID Extension . . . . . . . . . . . . . . . . . . . . . 8 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 56 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 7.1. Channel-Bound Cookies . . . . . . . . . . . . . . . . . . 12 58 7.2. Channel-Bound OAuth Tokens . . . . . . . . . . . . . . . . 12 59 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 65 Appendix B. History of Changes . . . . . . . . . . . . . . . . . 17 66 B.1. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 69 1. Introduction 71 Many applications on the Internet use _bearer tokens_ to authenticate 72 clients to servers. The most prominent example is the HTTP-based 73 World Wide Web, which overwhelmingly uses HTTP cookies to 74 authenticate client requests. Other examples include OpenID or SAML 75 assertions, and OAuth tokens. All these have in common that the 76 _bearer_ of the HTTP cookie or authentication token is granted access 77 to a protected resource, regardless of the channel over which the 78 token is presented, or who presented it. 80 As a result, an adversary that manages to steal a bearer token from a 81 client can impersonate that client to services that require the 82 token. 84 This document describes a light-weight mechanism for establishing a 85 _cryptographic channel_ between client and server. A server can 86 choose to bind authentication tokens to this channel, thus rendering 87 the theft of authentication tokens fruitless - tokens must be sent 88 over the channel to which they are bound (i.e., by the client to 89 which they were issued) or else they will be ignored. 91 This document does not prescribe _how_ authentication tokens are 92 bound to the underlying channel. Rather, it prescribes how a client 93 can establish a long-lived channel with a server. Such a channel 94 persists across HTTP requests, TLS connections, and even multiple TLS 95 sessions, as long as the same client communicates with the same 96 server. 98 The basic idea is that the client proves, during the TLS handshake, 99 possession of a private key. The corresponding public key becomes 100 the "Channel ID" that identifies this TLS connection. Clients should 101 re-use the same private/public key pair across subsequent TLS 102 connections to the same server, thus creating TLS connections that 103 share the same Channel ID. 105 Using private/public key pairs to define a channel (as opposed to, 106 say, an HTTP session cookie) has several advantages: One, the 107 credential establishing the channel (the private key) is never sent 108 from client to server, thus removing it from the reach of 109 eavesdroppers in the network. Two, clients can choose to implement 110 cryptographic operations in a secure hardware module, which further 111 removes the private key from the reach of eavesdroppers residing on 112 the client itself. 114 2. Why not client certificates 116 TLS already supports a means of identifying clients without using 117 bearer tokens: client certificates. However, a number of problems 118 with using client certificates motivated the development of an 119 alternative. 121 Most importantly, it's not acceptable for a client identifier to be 122 transmitted in the clear, because eavesdroppers in the network could 123 use these identifiers to deanonymize TLS connections. Client 124 certificates in TLS, however, are sent unencrypted. Although we 125 could also define a change to the TLS state machine to move the 126 client certificates under encryption, such changes eliminate most of 127 the benefits of reusing something that's already defined. 129 TLS client certificates are also defined to be part of the session 130 state. Even though the key material used for TLS client 131 authentication might be protected from theft from compromised clients 132 (for example, by employing hardware secure elements on the client), 133 TLS session resumption information rarely is. Because client 134 certificates are part of the session state, stolen session resumption 135 information gives the attacker something equivalent to a stolen 136 client private key. Our objective, however, is that attackers should 137 not be able to give the impression that they can wield a private key 138 unless they are actually in control of that private key. 140 Client-certificates typically identify a user, while we seek to 141 identify machines. Since they are not, conceptually, mutually 142 exclusive and as only a single client certificate can be provided in 143 TLS, we don't want to consume that single slot and eliminate the 144 possibility of also using existing client certificates. 146 Client certificates are implemented in TLS as X.509 certificates and 147 we don't wish to require servers to parse arbitrary ASN.1. ASN.1 is 148 a complex encoding that has been the source of several security 149 vulnerabilities in the past and typical TLS servers can currently 150 avoid doing ASN.1 parsing. 152 X.509 certificates always include a signature, which would be a self- 153 signature in this case. Calculating and transmitting the self- 154 signature is a waste of computation and network traffic in our use. 155 Although we could define a null signature algorithm with an empty 156 signature, such deviations from X.509 eliminate many of the benefits 157 of reusing something that is already implemented. 159 Finally, client certificates trigger significant server-side 160 processing by default and often need to be stored in their entirety 161 for the duration of the connection. Since this design is intended to 162 be widely used, it allows servers to retain only a cryptographic hash 163 of the client's public key after the handshake completes. 165 3. Requirements Notation 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 4. Channel ID Client Keys 173 For the purpose of this specification, a public key is a point "Q = 174 dG" on the P-256 curve [DSS] (where "d" is the ECC private key, and 175 "G" is the curve base point). Clients SHOULD use a separate key pair 176 "(d, Q)" for each server they connect to, and generate a new key pair 177 if necessary according to appendix B.4 in FIPS-186-3 [DSS]. 179 A public key "Q" has two affine coordinates "x, y": "Q = (x,y)". The 180 public key "Q" - or, in other words, the pair "x, y" - that a client 181 uses for a specific server is that client's Channel ID for that 182 server. 184 5. Channel ID Extension 186 A new extension type ("channel_id(TBD)") is defined and MAY be 187 included by the client in its "ClientHello" message. If, and only 188 if, the server sees this extension in the "ClientHello", it MAY 189 choose to echo the extension in its "ServerHello". In both cases, 190 the "extension_data" field MUST be empty. 192 enum { 193 channel_id(TBD), (65535) 194 } ExtensionType; 196 A new handshake message type ("encrypted_extensions(TBD)") is 197 defined. If the server included a "channel_id" extension in its 198 "ServerHello" message, the client MUST verify that the selected 199 cipher suite is sufficiently strong. If the cipher suite provides < 200 80-bits of security, the client MUST abort the handshake with a fatal 201 "illegal_parameter" alert. Otherwise, the client MUST send an 202 "EncryptedExtensions" message after its "ChangeCipherSpec" and before 203 its "Finished" message. 205 enum { 206 encrypted_extensions(TBD), (65535) 207 } HandshakeType; 209 Therefore a full handshake with "EncryptedExtensions" has the 210 following flow (contrast with section 7.3 of RFC 5246 [RFC5246]): 212 Client Server 214 ClientHello (ChannelID extension) --------> 215 ServerHello 216 (ChannelID extension) 217 Certificate* 218 ServerKeyExchange* 219 CertificateRequest* 220 <-------- ServerHelloDone 221 Certificate* 222 ClientKeyExchange 223 CertificateVerify* 224 [ChangeCipherSpec] 225 EncryptedExtensions 226 Finished --------> 227 [ChangeCipherSpec] 228 <-------- Finished 229 Application Data <-------> Application Data 231 An abbreviated handshake with "EncryptedExtensions" has the following 232 flow: 234 Client Server 236 ClientHello (ChannelID extension) --------> 237 ServerHello 238 (ChannelID extension) 239 [ChangeCipherSpec] 240 <-------- Finished 241 [ChangeCipherSpec] 242 EncryptedExtensions 243 Finished --------> 244 Application Data <-------> Application Data 246 The "EncryptedExtensions" message contains a series of "Extension" 247 structures (see section 7.4.1.4 of RFC 5246 [RFC5246] 249 If the server included a "channel_id" extension in its "ServerHello" 250 message, the client MUST include, within an EncryptedExtensions 251 message, an "Extension" with "extension_type" equal to 252 "channel_id(TBD)". The "extension_data" of which has the following 253 format: 255 struct { 256 opaque x[32]; 257 opaque y[32]; 258 opaque r[32]; 259 opaque s[32]; 260 } ChannelIDExtension; 262 The contents of each of "x", "y", "r" and "s" is a 32-byte, big- 263 endian number. The "x" and "y" fields contain the affine coordinates 264 of the client's Channel ID Q (i.e., a P-256 [DSS] curve point). The 265 "r" and "s" fields contain an ECDSA [DSS] signature by the 266 corresponding private key over this US-ASCII strong (not including 267 quotes, and where "\x00" represents an octet containing all zero 268 bits): 270 "TLS Channel ID signature\x00" 272 followed by hashes of both the client-sent and server-sent handshake 273 messages, as seen by the client, prior to the "EncryptedExtensions" 274 message. 276 Unlike many other TLS extensions, this extension does not establish 277 properties of the session, only of the connection. When session 278 resumption or session tickets [RFC5077] are used, the previous 279 contents of this extension are irrelevant and only the values in the 280 new handshake messages are considered. 282 6. Security Considerations 284 There are four classes of attackers against which we consider our 285 security guarantees: passive network attackers, active network 286 attackers, active network attackers with misissued certificates and 287 attackers in possession of the legitimate server's private key. 289 First, we wish to guarantee that we don't disclose the Channel ID to 290 passive or active network attackers. We do this by sending a 291 constant-length Channel ID under encryption. However, since the 292 Channel ID may be transmitted before the server's Finished message is 293 received, it's possible that the server isn't in possession of the 294 corresponding private key to the certificate that it presented. In 295 this situation, an active attacker could cause a Channel ID to be 296 transmitted under a random key in a cipher suite of their choosing. 297 Therefore we limit the permissible cipher suites to those where 298 decrypting the message is infeasible. 300 Even with this limit, an active attacker can cause the Channel ID to 301 be transmitted in a non-forward-secure manner. Subsequent disclosure 302 of the server's private key would allow previously recorded Channel 303 IDs to be decrypted. 305 Second, we wish to guarantee that none of the first three attackers 306 can terminate/hijack a TLS connection and impersonate a Channel ID 307 from that connection when connecting to the legitimate server. We 308 assume that TLS provides sufficient security to prevent these 309 attackers from being able to hijack the TLS connection. An active 310 attacker illegitimately in possession of a certificate for a server 311 can successfully terminate a TLS connection destined for that server 312 and decrypt the Channel ID. However, as the signature covers the 313 handshake hashes, and therefore the server's certificate, it wouldn't 314 be accepted by the true server. 316 Against an attacker with the legitimate server's private key we can 317 provide the second guarantee only if the legitimate server uses a 318 forward-secret cipher suite, otherwise the attacker can hijack the 319 connection. 321 7. Use Cases 323 7.1. Channel-Bound Cookies 325 An HTTP application on the server can _channel-bind_ its cookies by 326 associating them with the Channel ID of the user-agent that the 327 cookies are being set on. The server MAY then choose to consider 328 cookies sent from the user-agent invalid if the Channel ID associated 329 with the cookie does not match the Channel ID used by the user-agent 330 when it sends the cookie back to the server. 332 Such a mismatch could occur when the cookie has been obtained from 333 the legitimate user-agent and is now being sent by a client not in 334 possession of the legitimate user-agent's Channel ID private key. 335 The mismatch can also occur if the legitimate user-agent has changed 336 the Channel ID it is using for the server, presumably due to the user 337 requesting a Channel ID reset through the user-agent's user interface 338 (see Section 8). Such a user intervention is analogous to the user's 339 removal of cookies from the user-agent, but instead of removing 340 cookies, the cookies are being rendered invalid (in the eyes of the 341 server). 343 7.2. Channel-Bound OAuth Tokens 345 Similarly to cookies, a server may choose to channel-bind OAuth 346 tokens (or any other kind of authorization tokens) to the clients to 347 which they are issued. The mechanism on the server remains the same 348 (it associates the OAuth token with the client's Channel ID either by 349 storing this information in a database, or by suitably encoding the 350 information in the OAuth token itself), but the application-level 351 protocol may be different: In addition to HTTP, OAuth tokens are used 352 in protocols such as IMAP and XMPP. 354 8. Privacy Considerations 356 The TLS layer does its part in protecting user privacy by 357 transmitting the Channel ID public key under encryption. Higher 358 levels of the stack must ensure that the same Channel ID is not used 359 with different servers in such a way as to provide a linkable 360 identifier. For example, a user-agent must use different Channel IDs 361 for communicating with different servers. Because channel-bound 362 cookies are an important use case for TLS Channel ID, and cookies can 363 be set on top-level domains, it is RECOMMENDED that user-agents use 364 the same Channel ID for servers within the same top-level domain, and 365 different Channel IDs for different top-level domains. User-agents 366 must also ensure that Channel ID state can be reset by the user in 367 the same way as other identifiers, i.e. cookies. 369 However, there are some security concerns that could result in the 370 disclosure of a client's Channel ID to a network attacker. This is 371 covered in the Security Considerations section. 373 Clients that share an IP address can be disambiguated through their 374 Channel IDs. This is analogous to protocols that use cookies (e.g., 375 HTTP), which also allow disambiguation of user-agents behind proxies. 377 Channel ID has been designed to provide privacy equivalent to that of 378 cookies. User-agents SHOULD continue to meet this design goal at 379 higher layers of the protocol stack. For example, if a user 380 indicates that they would like to block third-party cookies (or if 381 the user-agent has some sort of policy around when it blocks third- 382 party cookies by default), then the user agent SHOULD NOT use Channel 383 ID on third-party connections (or other connections through which the 384 user-agent would refuse to send or accept cookies). 386 9. IANA Considerations 388 This document requires IANA to update its registry of TLS extensions 389 to assign an entry referred to here as "channel_id". 391 This document also requires IANA to update its registry of TLS 392 handshake types to assign an entry referred to here as 393 "encrypted_extensions". 395 10. References 397 10.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 403 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 405 [DSS] National Institute of Standards and Technology, "FIPS 406 186-3: Digital Signature Standard". 408 10.2. Informative References 410 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 411 "Transport Layer Security (TLS) Session Resumption without 412 Server-Side State", RFC 5077, January 2008. 414 Appendix A. Acknowledgements 416 The following individuals contributed to this specification: 418 Dirk Balfanz, Wan-Teh Chang, Ryan Hamilton, Adam Langley, and Mayank 419 Upadhyay. 421 Appendix B. History of Changes 423 B.1. Version 01 425 o Some clarifications, mostly around the Channel ID and session 426 state. 428 o Added a section on Use Cases. 430 o Expanded the Privacy Considerations sections to include discussion 431 of third-party connections in HTTP user-agents. 433 o Fixed some typos. 435 Authors' Addresses 437 Dirk Balfanz 438 Google Inc 440 Email: balfanz@google.com 442 Ryan Hamilton 443 Google Inc 445 Email: rch@google.com