idnits 2.17.1 draft-ietf-tokbind-protocol-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2015) is 3247 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTPSTB' ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Possible downref: Non-RFC (?) normative reference: ref. 'TBNEGO' == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-05 Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov, Ed. 3 Internet-Draft M. Nystroem 4 Intended status: Standards Track Microsoft Corp. 5 Expires: November 30, 2015 D. Balfanz 6 A. Langley 7 Google Inc. 8 May 29, 2015 10 The Token Binding Protocol Version 1.0 11 draft-ietf-tokbind-protocol-01 13 Abstract 15 This document specifies Version 1.0 of the Token Binding protocol. 16 The Token Binding protocol allows client/server applications to 17 create long-lived, uniquely identifiable TLS [RFC5246] bindings 18 spanning multiple TLS sessions and connections. Applications are 19 then enabled to cryptographically bind security tokens to the TLS 20 layer, preventing token export and replay attacks. To protect 21 privacy, the TLS Token Binding identifiers are only transmitted 22 encrypted and can be reset by the user at any time. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 30, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 3 61 3. Token Binding Protocol Message . . . . . . . . . . . . . . . 4 62 4. Establishing a TLS Token Binding . . . . . . . . . . . . . . 6 63 5. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 7 64 6. Security Token Validation . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8.1. Security Token Replay . . . . . . . . . . . . . . . . . . 9 68 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 9 69 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 9 70 8.4. Token Binding Key Sharing Between Applications . . . . . 10 71 8.5. Triple Handshake Vulnerability in TLS . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Web services generate various security tokens (e.g. HTTP cookies, 80 OAuth tokens) for web applications to access protected resources. 81 Any party in possession of such token gains access to the protected 82 resource. Attackers export bearer tokens from the user's machine, 83 present them to web services, and impersonate authenticated users. 84 The idea of Token Binding is to prevent such attacks by 85 cryptographically binding security tokens to the TLS layer. 87 A TLS Token Binding is established by the user agent generating a 88 private-public key pair (possibly within a secure hardware module, 89 such as TPM) per target server, and proving possession of the private 90 key on every TLS connection to the target server. The proof of 91 possession involves signing the tls_unique value [RFC5929] for the 92 TLS connection with the private key. Such TLS Token Binding is 93 identified by the corresponding public key. TLS Token Bindings are 94 long-lived, i.e. they encompass multiple TLS connections and TLS 95 sessions between a given client and server. To protect privacy, TLS 96 Token Binding identifiers are never transmitted in clear text and can 97 be reset by the user at any time, e.g. when clearing browser cookies. 99 When issuing a security token to a client that supports TLS Token 100 Binding, a server includes the client's TLS Token Binding ID in the 101 token. Later on, when a client presents a security token containing 102 a TLS Token Binding ID, the server makes sure the ID in the token 103 matches the ID of the TLS Token Binding established with the client. 104 In the case of a mismatch, the server discards the token. 106 In order to successfully export and replay a bound security token, 107 the attacker needs to also be able to export the client's private 108 key, which is hard to do in the case of the key generated in a secure 109 hardware module. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Token Binding Protocol Overview 119 The client and server use the Token Binding Negotiation TLS Extension 120 [TBNEGO] to negotiate the Token Binding protocol version and the 121 parameters (signature and hash algorithm, length) of the Token 122 Binding key. This negotiation does not require additional round- 123 trips. 125 The Token Binding protocol consists of one message sent by the client 126 to the server, proving possession of one or more client-generated 127 asymmetric keys. This message is only sent if the client and server 128 agree on the use of the Token Binding protocol and the key 129 parameters. The Token Binding message is sent with the application 130 protocol data in TLS application_data records. 132 A server receiving the Token Binding message verifies that the key 133 parameters in the message match the Token Binding parameters 134 negotiated via [TBNEGO], and then validates the signatures contained 135 in the Token Binding message. If either of these checks fails, the 136 server terminates the connection, otherwise the TLS Token Binding is 137 successfully established with the ID contained in the Token Binding 138 message. 140 When a server supporting the Token Binding protocol receives a bound 141 token, the server compares the TLS Token Binding ID in the security 142 token with the TLS Token Binding ID established with the client. If 143 the bound token came from a TLS connection without a Token Binding, 144 or if the IDs don't match, the token is discarded. 146 This document defines the format of the Token Binding protocol 147 message, the process of establishing a TLS Token Binding, the format 148 of the Token Binding ID, and the process of validating a security 149 token. Token Binding Negotiation TLS Extension [TBNEGO] describes 150 the negotiation of the Token Binding protocol and key parameters. 151 Token Binding over HTTP [HTTPSTB] explains how the Token Binding 152 message is encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] 153 messages. [HTTPSTB] also describes Token Binding between multiple 154 communicating parties: User Agent, Identity Provider and Relying 155 Party. 157 3. Token Binding Protocol Message 159 The Token Binding message is sent by the client and proves possession 160 of one or more private keys held by the client. This message MUST be 161 sent if the client and server successfully negotiated the use of the 162 Token Binding protocol via [TBNEGO], and MUST NOT be sent otherwise. 163 This message MUST be sent in the client's first application protocol 164 message. This message MAY also be sent in subsequent application 165 protocol messages, proving possession of other keys by the same 166 client, to facilitate token binding between more than two 167 communicating parties. Token Binding over HTTP [HTTPSTB] specifies 168 the encapsulation of the Token Binding message in the application 169 protocol messages, and the scenarios involving more than two 170 communicating parties. The Token Binding message format is defined 171 using TLS specification language, and reuses existing TLS structures 172 and IANA registrations where possible: 174 enum { 175 sha256(4), (255) 176 } HashAlgorithm; 178 enum { 179 rsa(1), ecdsap256(3), (255) 180 } SignatureAlgorithm; 182 struct { 183 HashAlgorithm hash; 184 SignatureAlgorithm signature; 185 } SignatureAndHashAlgorithm; 187 struct { 188 opaque modulus<1..2^16-1>; 189 opaque publicexponent<1..2^8-1>; 191 } RSAPublicKey; 193 enum { 194 secp256r1 (23), (0xFFFF) 195 } NamedCurve; 197 struct { 198 opaque point <1..2^8-1>; 199 } ECPoint; 201 struct { 202 NamedCurve namedcurve; 203 ECPoint point; // Uncompressed format 204 } ECDSAParams; 206 enum { 207 provided_token_binding(0), referred_token_binding(1), (255) 208 } TokenBindingType; 210 struct { 211 TokenBindingType tokenbinding_type; 212 SignatureAndHashAlgorithm algorithm; 213 select (algorithm.signature) { 214 case rsa: RSAPublicKey rsapubkey; 215 case ecdsa: ECDSAParams ecdsaparams; 216 } 217 } TokenBindingID; 219 enum { 220 (255) // No initial ExtensionType registrations 221 } ExtensionType; 223 struct { 224 ExtensionType extension_type; 225 opaque extension_data<0..2^16-1>; 226 } Extension; 228 struct { 229 TokenBindingID tokenbindingid; 230 opaque signature<0..2^16-1>;// Signature over hashed ("token binding", tls_unique) 231 Extension extensions<0..2^16-1>; 232 } TokenBinding; 234 struct { 235 TokenBinding tokenbindings<0..2^16-1>; 236 } TokenBindingMessage; 237 The Token Binding message consists of a series of TokenBinding 238 structures containing the TokenBindingID, a signature over the hash 239 of the NUL-terminated, ASCII label ("token binding") and the 240 tls_unique, optionally followed by Extension structures. An 241 implementation MUST ignore any unknown extensions. Initially, no 242 extension types are defined. At least one TokenBinding MUST be 243 included in the Token Binding message. The signature and hash 244 algorithm and key length used in the TokenBinding MUST match the 245 parameters negotiated via [TBNEGO]. The client SHOULD generate and 246 store Token Binding keys in a secure manner that prevents key export. 247 In order to prevent cooperating servers from linking user identities, 248 different keys SHOULD be used by the client for connections to 249 different servers, according to the token scoping rules of the 250 application protocol. 252 4. Establishing a TLS Token Binding 254 The triple handshake vulnerability in the TLS protocol affects the 255 security of the Token Binding protocol, as described in the "Security 256 Considerations" section below. Therefore, the server MUST NOT 257 negotiate the use of the Token Binding protocol unless the server 258 also negotiates Extended Master Secret TLS extension 259 [I-D.ietf-tls-session-hash]. 261 The server MUST terminate the connection if the use of the Token 262 Binding protocol has been successfully negotiated via [TBNEGO] within 263 the TLS handshake, but the client's first application message does 264 not contain the Token Binding message. The server MUST terminate the 265 connection if the use of the Token Binding protocol was not 266 negotiated, but the client sends the Token Binding message. 268 If the Token Binding type is "provided_token_binding", the server 269 MUST verify that the signature algorithm (including elliptic curve in 270 the case of ECDSA) and key length in the Token Binding message match 271 those negotiated via [TBNEGO]. In the case of a mismatch, the server 272 MUST terminate the connection. As described in [HTTPSTB], Token 273 Bindings of type "referred_token_binding" may have different key 274 parameters than those negotiated via [TBNEGO]. 276 If the Token Binding message does not contain at least one 277 TokenBinding structure, or the signature contained in a TokenBinding 278 structure is invalid, the server MUST terminate the connection. 279 Otherwise, the TLS Token Binding is successfully established and its 280 ID can be provided to the application for security token validation. 282 5. TLS Token Binding ID Format 284 The ID of the TLS Token Binding established as a result of Token 285 Binding message processing is a binary representation of the 286 following structure: 288 struct { 289 TokenBindingType tokenbinding_type; 290 SignatureAndHashAlgorithm algorithm; 291 select (algorithm.signature) { 292 case rsa: RSAPublicKey rsapubkey; 293 case ecdsa: ECDSAParams ecdsaparams; 294 } 295 } TokenBindingID; 297 TokenBindingID includes the type of the token binding and the key 298 parameters negotiated via [TBNEGO]. This document defines two token 299 binding types: provided_token_binding used to establish a Token 300 Binding when connecting to a server, and referred_token_binding used 301 when requesting tokens to be presented to a different server. Token 302 Binding over HTTP [HTTPSTB] describes Token Binding between multiple 303 communicating parties: User Agent, Identity Provider and Relying 304 Party. TLS Token Binding ID can be obtained from the TokenBinding 305 structure described in the "Token Binding Protocol Message" section 306 of this document by discarding the signature and extensions. TLS 307 Token Binding ID will be available at the application layer and used 308 by the server to generate and verify bound tokens. 310 6. Security Token Validation 312 Security tokens can be bound to the TLS layer either by embedding the 313 Token Binding ID in the token, or by maintaining a database mapping 314 tokens to Token Binding IDs. The specific method of generating bound 315 security tokens is application-defined and beyond the scope of this 316 document. 318 Upon receipt of a security token, the server attempts to retrieve TLS 319 Token Binding ID information from the token and from the TLS 320 connection with the client. Application-provided policy determines 321 whether to honor non-bound (bearer) tokens. If the token is bound 322 and a TLS Token Binding has not been established for the client 323 connection, the server MUST discard the token. If the TLS Token 324 Binding ID for the token does not match the TLS Token Binding ID 325 established for the client connection, the server MUST discard the 326 token. 328 7. IANA Considerations 330 This document establishes a registry for Token Binding type 331 identifiers entitled "Token Binding Types" under the "Token Binding 332 Protocol" heading. 334 Entries in this registry require the following fields: 336 o Value: The octet value that identifies the Token Binding type 337 (0-255). 339 o Description: The description of the Token Binding type. 341 o Specification: A reference to a specification that defines the 342 Token Binding type. 344 This registry operates under the "Expert Review" policy as defined in 345 [RFC5226]. The designated expert is advised to encourage the 346 inclusion of a reference to a permanent and readily available 347 specification that enables the creation of interoperable 348 implementations using the identified Token Binding type. 350 An initial set of registrations for this registry follows: 352 Value: 0 354 Description: provided_token_binding 356 Specification: this document 358 Value: 1 360 Description: referred_token_binding 362 Specification: this document 364 This document establishes a registry for Token Binding extensions 365 entitled "Token Binding Extensions" under the "Token Binding 366 Protocol" heading. 368 Entries in this registry require the following fields: 370 o Value: The octet value that identifies the Token Binding extension 371 (0-255). 373 o Description: The description of the Token Binding extension. 375 o Specification: A reference to a specification that defines the 376 Token Binding extension. 378 This registry operates under the "Expert Review" policy as defined in 379 [RFC5226]. The designated expert is advised to encourage the 380 inclusion of a reference to a permanent and readily available 381 specification that enables the creation of interoperable 382 implementations using the identified Token Binding extension. This 383 document creates no initial registrations in the "Token Binding 384 Extensions" registry. 386 This document uses "TLS SignatureAlgorithm" and "TLS HashAlgorithm" 387 registries originally created in [RFC5246], and "TLS NamedCurve" 388 registry originally created in [RFC4492]. This document creates no 389 new registrations in these registries. 391 8. Security Considerations 393 8.1. Security Token Replay 395 The goal of the Token Binding protocol is to prevent attackers from 396 exporting and replaying security tokens, thereby impersonating 397 legitimate users and gaining access to protected resources. Bound 398 tokens can still be replayed by the malware present in the User 399 Agent. In order to export the token to another machine and 400 successfully replay it, the attacker also needs to export the 401 corresponding private key. Token Binding private keys are therefore 402 high-value assets and SHOULD be strongly protected, ideally by 403 generating them in a hardware security module that prevents key 404 export. 406 8.2. Downgrade Attacks 408 The Token Binding protocol is only used when negotiated via [TBNEGO] 409 within the TLS handshake. TLS prevents active attackers from 410 modifying the messages of the TLS handshake, therefore it is not 411 possible for the attacker to remove or modify the Token Binding 412 Negotiation TLS Extension used to negotiate the Token Binding 413 protocol and key parameters. The signature algorithm and key length 414 used in the TokenBinding of type "provided_token_binding" MUST match 415 the parameters negotiated via [TBNEGO]. 417 8.3. Privacy Considerations 419 The Token Binding protocol uses persistent, long-lived TLS Token 420 Binding IDs. To protect privacy, TLS Token Binding IDs are never 421 transmitted in clear text and can be reset by the user at any time, 422 e.g. when clearing browser cookies. In order to prevent cooperating 423 servers from linking user identities, different keys SHOULD be used 424 by the client for connections to different servers, according to the 425 token scoping rules of the application protocol. 427 8.4. Token Binding Key Sharing Between Applications 429 Existing systems provide a variety of platform-specific mechanisms 430 for certain applications to share tokens, e.g. to enable single sign- 431 on scenarios. For these scenarios to keep working with bound tokens, 432 the applications that are allowed to share tokens will need to also 433 share Token Binding keys. Care must be taken to restrict the sharing 434 of Token Binding keys to the same group(s) of applications that share 435 the same tokens. 437 8.5. Triple Handshake Vulnerability in TLS 439 The Token Binding protocol relies on the tls_unique value to 440 associate a TLS connection with a TLS Token Binding. The triple 441 handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability 442 allowing the attacker to synchronize tls_unique values between TLS 443 connections. The attacker can then successfully replay bound tokens. 444 For this reason, the Token Binding protocol MUST NOT be negotiated 445 unless the Extended Master Secret TLS extension 446 [I-D.ietf-tls-session-hash] has also been negotiated. 448 9. References 450 9.1. Normative References 452 [HTTPSTB] Balfanz, D., Langley, A., Popov, A., and M. Nystroem, 453 "Token Binding over HTTP", 2014. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 459 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 460 for Transport Layer Security (TLS)", RFC 4492, May 2006. 462 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 463 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 464 May 2008. 466 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 467 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 469 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 470 for TLS", RFC 5929, July 2010. 472 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 473 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 474 2014. 476 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 477 Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. 479 [TBNEGO] Popov, A., Nystroem, M., Balfanz, D., and A. Langley, 480 "Transport Layer Security (TLS) Extension for Token 481 Binding Protocol Negotiation", 2015. 483 9.2. Informative References 485 [I-D.ietf-tls-session-hash] 486 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 487 A., and M. Ray, "Transport Layer Security (TLS) Session 488 Hash and Extended Master Secret Extension", draft-ietf- 489 tls-session-hash-05 (work in progress), April 2015. 491 [TRIPLE-HS] 492 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 493 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 494 Breaking and Fixing Authentication over TLS. IEEE 495 Symposium on Security and Privacy", 2014. 497 Authors' Addresses 499 Andrei Popov (editor) 500 Microsoft Corp. 501 USA 503 Email: andreipo@microsoft.com 505 Magnus Nystroem 506 Microsoft Corp. 507 USA 509 Email: mnystrom@microsoft.com 511 Dirk Balfanz 512 Google Inc. 513 USA 515 Email: balfanz@google.com 516 Adam Langley 517 Google Inc. 518 USA 520 Email: agl@google.com