idnits 2.17.1 draft-altman-tls-channel-bindings-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2, 2009) is 5314 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: 'FIPS-180-2' is mentioned on line 509, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP J. Altman 3 Internet-Draft Secure Endpoints 4 Intended status: Standards Track N. Williams 5 Expires: April 5, 2010 Sun 6 L. Zhu 7 Microsoft Corporation 8 October 2, 2009 10 Channel Bindings for TLS 11 draft-altman-tls-channel-bindings-07.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 5, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines three channel binding types for Transport Layer 60 Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- 61 telnet, in accordance with RFC 5056 (On Channel Binding). 63 Table of Contents 65 1. Conventions used in this document . . . . . . . . . . . . . 4 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 6 68 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. The 'tls-server-end-point' Channel Binding Type . . . . . . 7 71 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 9 74 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. Applicability of TLS Channel Binding Types . . . . . . . . . 11 77 7. Required Application Programming Interfaces . . . . . . . . 14 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 79 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 80 9.1. Cryptographic Algorithm Agility . . . . . . . . . . . . . . 16 81 9.2. On Disclosure of Channel Bindings Data by Authentication 82 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 18 85 10.2. Normative References for 'tls-server-end-point' . . . . . . 18 86 10.3. Informative References . . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 89 1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 Subsequent to the publication of "On Channel Bindings" [RFC5246], 98 three channel binding types for Transport Layer Security (TLS) were 99 proposed, reviewed and added to the IANA channel binding type 100 registry, all in accordance with [RFC5246]. Those channel binding 101 types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for- 102 telnet'. It has become desirable to have these channel binding types 103 re-registered through an RFC so as to make it easier to reference 104 them. This document does just that. The authors of those three 105 channel binding types have, or have indicated that they will, 106 transferred "ownership" of those channel binding types to the IESG. 108 We also provide some advice on the applicability of these channel 109 binding types, as well as advice on when to use which. And we 110 provide an abstract API that TLS implementors should provide, by 111 which to obtain channel bindings data for a TLS connection. 113 3. The 'tls-unique' Channel Binding Type 115 IANA is hereby directed to update the registration of the 'tls- 116 unique' channel binding type to match the following. Note that the 117 only material changes from the original registration should be: the 118 "owner" (now the IESG), contacts, the published specfication, and a 119 clarification to the description by the addition of a parenthetical 120 note (that is, the first such note in the descritption is a new 121 addition). We also added a note indicating that this specification 122 contains applicability advice, and we moved security considerations 123 notes to the security considerations section of this document. All 124 other fields of the registration are copied here for the convenience 125 of readers. 127 3.1. Description 129 Description: The client's TLS Finished message (note: the Finished 130 struct) from the first handshake of the connection (note: connection, 131 not session, so that the channel binding is specific to each 132 connection regardless of whether session resumption is used). 134 3.2. Registration 136 o Channel binding unique prefix: tls-unique 138 o Channel binding type: unique 140 o Channel type: TLS [RFC5246] 142 o Published specification: 144 o Channel binding is secret: no 146 o Description: 148 o Intended usage: COMMON 150 o Person and email address to contact for further information: Larry 151 Zhu (lzhu@microsoft.com), Nicolas Williams 152 (Nicolas.Williams@sun.com). 154 o Owner/Change controller name and email address: IESG. 156 o Expert reviewer name and contact information: IETF TLS WG 157 (tls@ietf.org, failing that, ietf@ietf.org) 159 o Note: see the published specification for advice on the 160 applicability of this channel binding type. 162 4. The 'tls-server-end-point' Channel Binding Type 164 IANA is hereby directed to update the registration of the 'tls- 165 server-end-point' channel binding type to match the following. Note 166 that the only material changes from the original registration should 167 be: the "owner" (now the IESG), the contacts, the published 168 specfication, and a note indicating that the published specification 169 should be consulted for applicability advice. References were added 170 to the description. All other fields of the registration are copied 171 here for the convenience of readers. 173 4.1. Description 175 Description: The hash of the TLS server's certificate [RFC5280] as it 176 appears, octet for octet, in the server's Certificate message (note 177 that the Certificate message contains a certificate_list, the first 178 element of which is the server's certificate). 180 The hash function is to be selected as follows: 182 o if the certificate's signatureAlgorithm uses a single hash 183 function, and that hash function is either MD5 [RFC1321] or SHA-1 184 [RFC3174] then use SHA-256 [FIPS-180-2]; 186 o if the certificate's signatureAlgorithm uses a single hash 187 function and that hash function neither MD5 nor SHA-1, then use 188 the hash function associated with the certificate's 189 signatureAlgorithm; 191 o if the certificate's signatureAlgorithm uses no hash functions or 192 multiple hash functions, then this channel binding type's channel 193 bindings are undefined at this time (updates to is channel binding 194 type may occur to address this issue if it ever arises). 196 The reason for using a hash of the certificate is that some 197 implementations need to track the channel binding of a TLS session in 198 kernel-mode memory, which is often at a premium. 200 4.2. Registration 202 o Channel binding unique prefix: tls-server-end-point 204 o Channel binding type: end-point 206 o Channel type: TLS [RFC5246] 208 o Published specification: 209 o Channel binding is secret: no 211 o Description: 213 o Intended usage: COMMON 215 o Person and email address to contact for further information: Larry 216 Zhu (lzhu@microsoft.com), Nicolas Williams 217 (Nicolas.Williams@sun.com). 219 o Owner/Change controller name and email address: IESG. 221 o Expert reviewer name and contact information: IETF TLS WG 222 (tls@ietf.org, failing that, ietf@ietf.org) 224 o Note: see the published specification for advice on the 225 applicability of this channel binding type. 227 5. The 'tls-unique-for-telnet' Channel Binding Type 229 IANA is hereby directed to update the registration of the 'tls- 230 unique-for-telnet' channel binding type to match the following. Note 231 that the only material changes from the original registration should 232 be: the "owner" (now the IESG), the contacts, the published 233 specfication, and a note indicating that the published specification 234 should be consulted for applicability advice. The description is 235 also clarified. We also moved security considerations notes to the 236 security considerations section of this document. All other fields 237 of the registration are copied here for the convenience of readers. 239 5.1. Description 241 Description: There is a proposal for adding a "StartTLS" extension to 242 TELNET, and a channel binding extension for the various TELNET AUTH 243 mechanisms whereby each side sends the other a "checksum" (MAC) of 244 their view of the channel's bindings. The client uses the first TLS 245 Finished messages (note: the Finished struct) from the client and 246 server, each concatenated in that order and in their clear text form. 247 The server does the same but in the opposite concatenation order 248 (server, then client). 250 5.2. Registration 252 o Channel binding unique prefix: tls-unique-for-telnet 254 o Channel binding type: unique 256 o Channel type: TLS [RFC5246] 258 o Published specification: 260 o Channel binding is secret: no 262 o Description: 264 o Intended usage: COMMON 266 o Person and email address to contact for further information: Jeff 267 Altman (jaltman@secure-endpoints.com), Nicolas Williams 268 (Nicolas.Williams@sun.com). 270 o Owner/Change controller name and email address: IESG. 272 o Expert reviewer name and contact information: IETF TLS WG 273 (tls@ietf.org, failing that, ietf@ietf.org) 275 o Note: see the published specification for advice on the 276 applicability of this channel binding type. 278 6. Applicability of TLS Channel Binding Types 280 The 'tls-unique-for-telnet' channel binding type is only applicable 281 to TELNET [RFC0854], and is available for all TLS connections. 283 The 'tls-unique' channel binding type is available for all TLS 284 connections, while 'tls-server-end-point' is only available when TLS 285 cipher suites with server certificates are used, specifically: cipher 286 suites that use the Certificate handshake message, which typically 287 involve the use of PKIX [RFC5280]. For example, 'tls-server-end- 288 point' is available when using TLS ciphers suites such as (this is 289 not an exhaustive list): 291 o TLS_DHE_DSS_WITH_* 293 o TLS_DHE_RSA_WITH_* 295 o TLS_DH_DSS_WITH_* 297 o TLS_DH_RSA_WITH_* 299 o TLS_ECDHE_ECDSA_WITH_* 301 o TLS_ECDHE_RSA_WITH_* 303 o TLS_ECDH_ECDSA_WITH_* 305 o TLS_ECDH_RSA_WITH_* 307 o TLS_RSA_PSK_WITH_* 309 o TLS_RSA_WITH_* 311 o TLS_SRP_SHA_DSS_WITH_* 313 o TLS_SRP_SHA_RSA_WITH_* 315 but is not available when using TLS cipher suites such as (this is 316 not an exhaustive list): 318 o TLS_DHE_PSK_WITH_* 320 o TLS_DH_anon_WITH_* 322 o TLS_ECDHE_PSK_WITH_* 324 o TLS_ECDH_anon_WITH_* 325 o TLS_KRB5_WITH_* 327 o TLS_PSK_WITH_* 329 o TLS_SRP_SHA_WITH_* 331 Nor is this channel binding type available for use with OpenPGP 332 server certificates [RFC5081] [RFC4880] (since these don't use the 333 Certificate handshake message). 335 Therefore 'tls-unique' is generally better than 'tls-server-end- 336 point'. However, 'tls-server-end-point' may be used with existing 337 TLS server-side proxies ("concentrators") without modification to the 338 proxies, whereas 'tls-unique' may require firmware or software 339 updates to server-side proxies. Therefore there may be cases where 340 'tls-server-end-point' may interoperate but where 'tls-unique' may 341 not. 343 Also, authentications mechanisms may arise which depend on channel 344 bindings to contribute entropy, in which case unique channel bindings 345 would have to always be used in preference to end-point channel 346 bindings. At this time there are no such mechanisms, though one such 347 SASL mechanism has been proposed. Whether such mechanisms should be 348 allowed is out of scope for this document. 350 In other words, for many applications there may be two potentially 351 applicable TLS channel binding types. Channel binding is all or 352 nothing for the GSS-API [RFC2743], and likely other frameworks. 353 Therefore agreement on the use of channel binding, and a particular 354 channel binding type is necessary. Such agreement can be obtained a 355 priori, by convention, or negotiated. 357 The specifics of whether and how to negotiate channel binding types 358 are beyond the scope of this document. However, it is RECOMMENDED 359 that application protocols making use of TLS channel bindings, use 360 'tls-unique' exclusively, except, perhaps, where server-side proxies 361 are common in deployments of an application protocol. In the latter 362 case an application protocol MAY specify that 'tls-server-end-point' 363 channel bindings must be used when available, with 'tls-unique' being 364 used when 'tls-server-end-point' channel bindings are not available. 365 Alternatively, the application may negotiate which channel binding 366 type to use, or may make the choice of channel binding type 367 configurable. 369 Specifically, application protocol specifications MUST indicate at 370 least one mandatory to implement channel binding type, MAY specify a 371 negotiation protocol, MAY allow for out-of-band negotiation or 372 configuration, and SHOULD have a preference for 'tls-unique' over 373 'tls-server-end-point'. 375 7. Required Application Programming Interfaces 377 TLS implementations supporting the use of 'tls-unique' and/or 'tls- 378 unique-for-telnet' channel binding types, MUST provide application 379 programming interfaces by which applications (clients and servers 380 both) may obtain the channel bindings for a TLS connection. Such 381 interfaces may be expressed in terms of extracting the channel 382 bindings data for a given connection and channel binding type. 383 Alternatively the implementor may provide interfaces by which to 384 obtain the initial client Finished message, the initial server 385 Finished message and/or the server certificate (in a form that 386 matches the description of the 'tls-server-end-point' channel binding 387 type). In the latter case the application has to have knowledge of 388 the channel binding type descriptions from this document. This 389 document takes no position on which form these application 390 programming interfaces must take. 392 8. IANA Considerations 394 The IANA is hereby directed to update three existing channel binding 395 type registrations. See the rest of this document. 397 9. Security Considerations 399 The Security Considerations section of [RFC5056] applies to this 400 document. 402 The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known 403 to both endpoints of a TLS connection, and are cryptographycally 404 bound to it. Therefore the TLS Finished messages can be safely used 405 as a channel binding provided that the authentication mechanism doing 406 the channel binding conforms to the requirements in [RFC5056]. 408 The server certificate, when present, is also cryptographically bound 409 to the TLS connection through its use in key transport and/or 410 authentication of the server (either by dint of its use in key 411 transport, by its use in signing key agreement, or by its use in key 412 agreement). Therefore the server certificate is suitable as an end- 413 point channel binding as described in [RFC5056]. 415 9.1. Cryptographic Algorithm Agility 417 The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do 418 not add any use of cryptography beyond that used by TLS itself. 419 Therefore these two channel binding types add no considerations with 420 respect to cryptographic algorithm agility. 422 The 'tls-server-end-point' channel binding type consist of a hash of 423 a server certificate. The reason for this is to produce manageably 424 small channel binding data, as some implementations will be using 425 kernel-mode memory (which is typically scarce) to store these. This 426 use of a hash algorithm is above and beyond TLS's use of 427 cryptography, therefore the 'tls-server-end-point' channel binding 428 type has a security consideration with respect to hash algorithm 429 agility. The algorithm to be used, however, is derived from the 430 server certificate's signature algorithm as described in Section 4.1; 431 to recap: use SHA-256 if the certificate signature algorithm uses MD5 432 or SHA-1, else use whatever hash function the certificate uses 433 (unless the signature algorithm uses no hash functions or more than 434 one hash function, in which case 'tls-server-end-point' is 435 undefined). This construction automatically makes 'tls-server-end- 436 point' hash algorithm agile, with a dependency on PKIX and TLS for 437 hash agility. 439 Current proposals for randomized signatures algorithms 440 [I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in 441 their construction -- a single hash function in each algorithm. 442 Therefore the 'tls-server-end-point' channel binding type should be 443 available even in cases where new signatures algorithms are used that 444 are based on current randomized hashing proposals (but we cannot 445 guarantee this, of course). 447 9.2. On Disclosure of Channel Bindings Data by Authentication 448 Mechanisms 450 When these channel binding types were first considered, one issue 451 that some commenters were concerned about was the possible impact on 452 the security of the TLS channel, of disclosure of the channel 453 bindings data by authentication mechanisms. This can happen, for 454 example, when an authentication mechanism transports the channel 455 bindings data, with no confidentiality protection, over other 456 transports (for example, in communicating with a trusted third 457 party), or when the TLS channel provides no confidentiality 458 protection and the authentication mechanism does not protect the 459 confidentiality of the channel bindings data. This section considers 460 that concern. 462 When the TLS connection uses a cipher suite that does not provide 463 confidentiality protection, the TLS Finished messages will be visible 464 to eavesdroppers, regardless of what the authentication mechanism 465 does. The same is true of the server certificate which, in any case, 466 is generally visible to eavesdroppers. Therefore we must consider 467 our choices of TLS channel bindings here to be safe to disclose by 468 definition -- if that were not the case then TLS with cipher suites 469 that don't provide confidentiality protection would be unsafe. 470 Furthermore, the TLS Finished message construction depends on the 471 security of the TLS PRF, which in turn needs to be resistant to key 472 recovery attacks, and we think that it is, as it is based on HMAC, 473 and the master secret is, well, secret (and the result of key 474 exchange). 476 Note too that in the case of an attempted active man-in-the-middle 477 attack, the attacker will already possess knowledge of the TLS 478 finished messages for both inbound and outbound TLS channels (which 479 will differ, given that the attacker cannot force them to be the 480 same). No additional information is obtained by the attacker from 481 the authentication mechanism's disclosure of channel bindings data -- 482 the attacker already has it, even when cipher suites providing 483 confidentiality protection are provided. 485 None of the channel binding types defined herein produce channel 486 bindings data that must be kept secret. Moreover, none of the 487 channel binding types defined herein can be expected to be private 488 (known only to the end-points of the channel), except that the unique 489 TLS channel binding types can be expected to be private when a cipher 490 suite that provides confidentiality protection is used to protect the 491 Finished message exchanges and the application data records 492 containing application-layer authentication messages. 494 10. References 496 10.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 502 Channels", RFC 5056, November 2007. 504 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 505 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 507 10.2. Normative References for 'tls-server-end-point' 509 [FIPS-180-2] 510 United States of America, National Institute of Standards 511 and Technology, "Secure Hash Standard (Federal Information 512 Processing Standard (FIPS) 180-2". 514 10.3. Informative References 516 [I-D.irtf-cfrg-rhash] 517 Halevi, S. and H. Krawczyk, "Strengthening Digital 518 Signatures via Randomized Hashing", 519 draft-irtf-cfrg-rhash-01 (work in progress), October 2007. 521 [NIST-SP.800-106.2009] 522 National Institute of Standards and Technology, "NIST 523 Special Publication 800-106: Randomized Hashing for 524 Digital Signatures", February 2009. 526 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 527 Specification", STD 8, RFC 854, May 1983. 529 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 530 April 1992. 532 [RFC2743] Linn, J., "Generic Security Service Application Program 533 Interface Version 2, Update 1", RFC 2743, January 2000. 535 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 536 (SHA1)", RFC 3174, September 2001. 538 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 539 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 541 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 542 Layer Security (TLS) Authentication", RFC 5081, 543 November 2007. 545 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 546 Housley, R., and W. Polk, "Internet X.509 Public Key 547 Infrastructure Certificate and Certificate Revocation List 548 (CRL) Profile", RFC 5280, May 2008. 550 Authors' Addresses 552 Jeff Altman 553 Secure Endpoints 554 255 W 94TH ST PHB 555 New York, NY 10025 556 US 558 Email: jaltman@secure-endpoints.com 560 Nicolas Williams 561 Sun Microsystems 562 5300 Riata Trace Ct 563 Austin, TX 78727 564 US 566 Email: Nicolas.Williams@sun.com 568 Larry Zhu 569 Microsoft Corporation 570 One Microsoft Way 571 Redmond, WA 98052 572 US 574 Email: lzhu@microsoft.com