idnits 2.17.1 draft-altman-tls-channel-bindings-06.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 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 (August 31, 2009) is 5345 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 499, 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: March 4, 2010 Sun 6 L. Zhu 7 Microsoft Corporation 8 August 31, 2009 10 Channel Bindings for TLS 11 draft-altman-tls-channel-bindings-06.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. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 4, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document defines three channel binding types for Transport Layer 50 Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- 51 telnet, in accordance with RFC 5056 (On Channel Binding). 53 Table of Contents 55 1. Conventions used in this document . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 5 58 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. The 'tls-server-end-point' Channel Binding Type . . . . . . 6 61 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 8 64 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Applicability of TLS Channel Binding Types . . . . . . . . . 10 67 7. Required Application Programming Interfaces . . . . . . . . 13 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 69 9. Security Considerations . . . . . . . . . . . . . . . . . . 15 70 9.1. Cryptographic Algorithm Agility . . . . . . . . . . . . . . 15 71 9.2. On Disclosure of Channel Bindings Data by Authentication 72 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 17 75 10.2. Normative References for 'tls-server-end-point' . . . . . . 17 76 10.3. Informative References . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 79 1. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Introduction 87 Subsequent to the publication of "On Channel Bindings" [RFC5246], 88 three channel binding types for Transport Layer Security (TLS) were 89 proposed, reviewed and added to the IANA channel binding type 90 registry, all in accordance with [RFC5246]. Those channel binding 91 types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for- 92 telnet'. It has become desirable to have these channel binding types 93 re-registered through an RFC so as to make it easier to reference 94 them. This document does just that. The authors of those three 95 channel binding types have, or have indicated that they will, 96 transferred "ownership" of those channel binding types to the IESG. 98 We also provide some advice on the applicability of these channel 99 binding types, as well as advice on when to use which. And we 100 provide an abstract API that TLS implementors should provide, by 101 which to obtain channel bindings data for a TLS connection. 103 3. The 'tls-unique' Channel Binding Type 105 IANA is hereby directed to update the registration of the 'tls- 106 unique' channel binding type to match the following. Note that the 107 only material changes from the original registration should be: the 108 "owner" (now the IESG), contacts, the published specfication, and a 109 clarification to the description by the addition of a parenthetical 110 note (that is, the first such note in the descritption is a new 111 addition). We also added a note indicating that this specification 112 contains applicability advice, and we moved security considerations 113 notes to the security considerations section of this document. All 114 other fields of the registration are copied here for the convenience 115 of readers. 117 3.1. Description 119 Description: The client's TLS Finished message (note: the Finished 120 struct) from the first handshake of the connection (note: connection, 121 not session, so that the channel binding is specific to each 122 connection regardless of whether session resumption is used). 124 3.2. Registration 126 o Channel binding unique prefix: tls-unique 128 o Channel binding type: unique 130 o Channel type: TLS [RFC5246] 132 o Published specification: 134 o Channel binding is secret: no 136 o Description: 138 o Intended usage: COMMON 140 o Person and email address to contact for further information: Larry 141 Zhu (lzhu@microsoft.com), Nicolas Williams 142 (Nicolas.Williams@sun.com). 144 o Owner/Change controller name and email address: IESG. 146 o Expert reviewer name and contact information: IETF TLS WG 147 (tls@ietf.org, failing that, ietf@ietf.org) 149 o Note: see the published specification for advice on the 150 applicability of this channel binding type. 152 4. The 'tls-server-end-point' Channel Binding Type 154 IANA is hereby directed to update the registration of the 'tls- 155 server-end-point' channel binding type to match the following. Note 156 that the only material changes from the original registration should 157 be: the "owner" (now the IESG), the contacts, the published 158 specfication, and a note indicating that the published specification 159 should be consulted for applicability advice. References were added 160 to the description. All other fields of the registration are copied 161 here for the convenience of readers. 163 4.1. Description 165 Description: The hash of the TLS server's certificate [RFC5280] as it 166 appears, octet for octet, in the server's Certificate message (note 167 that the Certificate message contains a certificate_list, the first 168 element of which is the server's certificate). 170 The hash function is to be selected as follows: 172 o if the certificate's signatureAlgorithm uses a single hash 173 function, and that hash function is either MD5 [RFC1321] or SHA-1 174 [RFC3174] then use SHA-256 [FIPS-180-2]; 176 o if the certificate's signatureAlgorithm uses a single hash 177 function and that hash function neither MD5 nor SHA-1, then use 178 the hash function associated with the certificate's 179 signatureAlgorithm; 181 o if the certificate's signatureAlgorithm uses no hash functions or 182 multiple hash functions, then this channel binding type's channel 183 bindings are undefined at this time (updates to is channel binding 184 type may occur to address this issue if it ever arises). 186 The reason for using a hash of the certificate is that some 187 implementations need to track the channel binding of a TLS session in 188 kernel-mode memory, which is often at a premium. 190 4.2. Registration 192 o Channel binding unique prefix: tls-server-end-point 194 o Channel binding type: end-point 196 o Channel type: TLS [RFC5246] 198 o Published specification: 199 o Channel binding is secret: no 201 o Description: 203 o Intended usage: COMMON 205 o Person and email address to contact for further information: Larry 206 Zhu (lzhu@microsoft.com), Nicolas Williams 207 (Nicolas.Williams@sun.com). 209 o Owner/Change controller name and email address: IESG. 211 o Expert reviewer name and contact information: IETF TLS WG 212 (tls@ietf.org, failing that, ietf@ietf.org) 214 o Note: see the published specification for advice on the 215 applicability of this channel binding type. 217 5. The 'tls-unique-for-telnet' Channel Binding Type 219 IANA is hereby directed to update the registration of the 'tls- 220 unique-for-telnet' channel binding type to match the following. Note 221 that the only material changes from the original registration should 222 be: the "owner" (now the IESG), the contacts, the published 223 specfication, and a note indicating that the published specification 224 should be consulted for applicability advice. The description is 225 also clarified. We also moved security considerations notes to the 226 security considerations section of this document. All other fields 227 of the registration are copied here for the convenience of readers. 229 5.1. Description 231 Description: There is a proposal for adding a "StartTLS" extension to 232 TELNET, and a channel binding extension for the various TELNET AUTH 233 mechanisms whereby each side sends the other a "checksum" (MAC) of 234 their view of the channel's bindings. The client uses the first TLS 235 Finished messages (note: the Finished struct) from the client and 236 server, each concatenated in that order and in their clear text form. 237 The server does the same but in the opposite concatenation order 238 (server, then client). 240 5.2. Registration 242 o Channel binding unique prefix: tls-unique-for-telnet 244 o Channel binding type: unique 246 o Channel type: TLS [RFC5246] 248 o Published specification: 250 o Channel binding is secret: no 252 o Description: 254 o Intended usage: COMMON 256 o Person and email address to contact for further information: Jeff 257 Altman (jaltman@secure-endpoints.com), Nicolas Williams 258 (Nicolas.Williams@sun.com). 260 o Owner/Change controller name and email address: IESG. 262 o Expert reviewer name and contact information: IETF TLS WG 263 (tls@ietf.org, failing that, ietf@ietf.org) 265 o Note: see the published specification for advice on the 266 applicability of this channel binding type. 268 6. Applicability of TLS Channel Binding Types 270 The 'tls-unique-for-telnet' channel binding type is only applicable 271 to TELNET [RFC0854], and is available for all TLS connections. 273 The 'tls-unique' channel binding type is available for all TLS 274 connections, while 'tls-server-end-point' is only available when TLS 275 cipher suites with server certificates are used, specifically: cipher 276 suites that use the Certificate handshake message, which typically 277 involve the use of PKIX [RFC5280]. For example, 'tls-server-end- 278 point' is available when using TLS ciphers suites such as (this is 279 not an exhaustive list): 281 o TLS_DHE_DSS_WITH_* 283 o TLS_DHE_RSA_WITH_* 285 o TLS_DH_DSS_WITH_* 287 o TLS_DH_RSA_WITH_* 289 o TLS_ECDHE_ECDSA_WITH_* 291 o TLS_ECDHE_RSA_WITH_* 293 o TLS_ECDH_ECDSA_WITH_* 295 o TLS_ECDH_RSA_WITH_* 297 o TLS_RSA_PSK_WITH_* 299 o TLS_RSA_WITH_* 301 o TLS_SRP_SHA_DSS_WITH_* 303 o TLS_SRP_SHA_RSA_WITH_* 305 but is not available when using TLS cipher suites such as (this is 306 not an exhaustive list): 308 o TLS_DHE_PSK_WITH_* 310 o TLS_DH_anon_WITH_* 312 o TLS_ECDHE_PSK_WITH_* 314 o TLS_ECDH_anon_WITH_* 315 o TLS_KRB5_WITH_* 317 o TLS_PSK_WITH_* 319 o TLS_SRP_SHA_WITH_* 321 Nor is this channel binding type available for use with OpenPGP 322 server certificates [RFC5081] [RFC4880] (since these don't use the 323 Certificate handshake message). 325 Therefore 'tls-unique' is generally better than 'tls-server-end- 326 point'. However, 'tls-server-end-point' may be used with existing 327 TLS server-side proxies ("concentrators") without modification to the 328 proxies, whereas 'tls-unique' may require firmware or software 329 updates to server-side proxies. Therefore there may be cases where 330 'tls-server-end-point' may interoperate but where 'tls-unique' may 331 not. 333 Also, authentications mechanisms may arise which depend on channel 334 bindings to contribute entropy, in which case unique channel bindings 335 would have to always be used in preference to end-point channel 336 bindings. At this time there are no such mechanisms, though one such 337 SASL mechanism has been proposed. Whether such mechanisms should be 338 allowed is out of scope for this document. 340 In other words, for many applications there may be two potentially 341 applicable TLS channel binding types. Channel binding is all or 342 nothing for the GSS-API [RFC2743], and likely other frameworks. 343 Therefore agreement on the use of channel binding, and a particular 344 channel binding type is necessary. Such agreement can be obtained a 345 priori, by convention, or negotiated. 347 The specifics of whether and how to negotiate channel binding types 348 are beyond the scope of this document. However, it is RECOMMENDED 349 that application protocols making use of TLS channel bindings, use 350 'tls-unique' exclusively, except, perhaps, where server-side proxies 351 are common in deployments of an application protocol. In the latter 352 case an application protocol MAY specify that 'tls-server-end-point' 353 channel bindings must be used when available, with 'tls-unique' being 354 used when 'tls-server-end-point' channel bindings are not available. 355 Alternatively, the application may negotiate which channel binding 356 type to use, or may make the choice of channel binding type 357 configurable. 359 Specifically, application protocol specifications MUST indicate at 360 least one mandatory to implement channel binding type, MAY specify a 361 negotiation protocol, MAY allow for out-of-band negotiation or 362 configuration, and SHOULD have a preference for 'tls-unique' over 363 'tls-server-end-point'. 365 7. Required Application Programming Interfaces 367 TLS implementations supporting the use of 'tls-unique' and/or 'tls- 368 unique-for-telnet' channel binding types, MUST provide application 369 programming interfaces by which applications (clients and servers 370 both) may obtain the channel bindings for a TLS connection. Such 371 interfaces may be expressed in terms of extracting the channel 372 bindings data for a given connection and channel binding type. 373 Alternatively the implementor may provide interfaces by which to 374 obtain the initial client Finished message, the initial server 375 Finished message and/or the server certificate (in a form that 376 matches the description of the 'tls-server-end-point' channel binding 377 type). In the latter case the application has to have knowledge of 378 the channel binding type descriptions from this document. This 379 document takes no position on which form these application 380 programming interfaces must take. 382 8. IANA Considerations 384 The IANA is hereby directed to update three existing channel binding 385 type registrations. See the rest of this document. 387 9. Security Considerations 389 The Security Considerations section of [RFC5056] applies to this 390 document. 392 The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known 393 to both endpoints of a TLS connection, and are cryptographycally 394 bound to it. Therefore the TLS Finished messages can be safely used 395 as a channel binding provided that the authentication mechanism doing 396 the channel binding conforms to the requirements in [RFC5056]. 398 The server certificate, when present, is also cryptographically bound 399 to the TLS connection through its use in key transport and/or 400 authentication of the server (either by dint of its use in key 401 transport, by its use in signing key agreement, or by its use in key 402 agreement). Therefore the server certificate is suitable as an end- 403 point channel binding as described in [RFC5056]. 405 9.1. Cryptographic Algorithm Agility 407 The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do 408 not add any use of cryptography beyond that used by TLS itself. 409 Therefore these two channel binding types add no considerations with 410 respect to cryptographic algorithm agility. 412 The 'tls-server-end-point' channel binding type consist of a hash of 413 a server certificate. The reason for this is to produce manageably 414 small channel binding data, as some implementations will be using 415 kernel-mode memory (which is typically scarce) to store these. This 416 use of a hash algorithm is above and beyond TLS's use of 417 cryptography, therefore the 'tls-server-end-point' channel binding 418 type has a security consideration with respect to hash algorithm 419 agility. The algorithm to be used, however, is derived from the 420 server certificate's signature algorithm as described in Section 4.1; 421 to recap: use SHA-256 if the certificate signature algorithm uses MD5 422 or SHA-1, else use whatever hash function the certificate uses 423 (unless the signature algorithm uses no hash functions or more than 424 one hash function, in which case 'tls-server-end-point' is 425 undefined). This construction automatically makes 'tls-server-end- 426 point' hash algorithm agile, with a dependency on PKIX and TLS for 427 hash agility. 429 Current proposals for randomized signatures algorithms 430 [I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in 431 their construction -- a single hash function in each algorithm. 432 Therefore the 'tls-server-end-point' channel binding type should be 433 available even in cases where new signatures algorithms are used that 434 are based on current randomized hashing proposals (but we cannot 435 guarantee this, of course). 437 9.2. On Disclosure of Channel Bindings Data by Authentication 438 Mechanisms 440 When these channel binding types were first considered, one issue 441 that some commenters were concerned about was the possible impact on 442 the security of the TLS channel, of disclosure of the channel 443 bindings data by authentication mechanisms. This can happen, for 444 example, when an authentication mechanism transports the channel 445 bindings data, with no confidentiality protection, over other 446 transports (for example, in communicating with a trusted third 447 party), or when the TLS channel provides no confidentiality 448 protection and the authentication mechanism does not protect the 449 confidentiality of the channel bindings data. This section considers 450 that concern. 452 When the TLS connection uses a cipher suite that does not provide 453 confidentiality protection, the TLS Finished messages will be visible 454 to eavesdroppers, regardless of what the authentication mechanism 455 does. The same is true of the server certificate which, in any case, 456 is generally visible to eavesdroppers. Therefore we must consider 457 our choices of TLS channel bindings here to be safe to disclose by 458 definition -- if that were not the case then TLS with cipher suites 459 that don't provide confidentiality protection would be unsafe. 460 Furthermore, the TLS Finished message construction depends on the 461 security of the TLS PRF, which in turn needs to be resistant to key 462 recovery attacks, and we think that it is, as it is based on HMAC, 463 and the master secret is, well, secret (and the result of key 464 exchange). 466 Note too that in the case of an attempted active man-in-the-middle 467 attack, the attacker will already possess knowledge of the TLS 468 finished messages for both inbound and outbound TLS channels (which 469 will differ, given that the attacker cannot force them to be the 470 same). No additional information is obtained by the attacker from 471 the authentication mechanism's disclosure of channel bindings data -- 472 the attacker already has it, even when cipher suites providing 473 confidentiality protection are provided. 475 None of the channel binding types defined herein produce channel 476 bindings data that must be kept secret. Moreover, none of the 477 channel binding types defined herein can be expected to be private 478 (known only to the end-points of the channel), except that the unique 479 TLS channel binding types can be expected to be private when a cipher 480 suite that provides confidentiality protection is used to protect the 481 Finished message exchanges and the application data records 482 containing application-layer authentication messages. 484 10. References 486 10.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 492 Channels", RFC 5056, November 2007. 494 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 495 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 497 10.2. Normative References for 'tls-server-end-point' 499 [FIPS-180-2] 500 United States of America, National Institute of Standards 501 and Technology, "Secure Hash Standard (Federal Information 502 Processing Standard (FIPS) 180-2". 504 10.3. Informative References 506 [I-D.irtf-cfrg-rhash] 507 Halevi, S. and H. Krawczyk, "Strengthening Digital 508 Signatures via Randomized Hashing", 509 draft-irtf-cfrg-rhash-01 (work in progress), October 2007. 511 [NIST-SP.800-106.2009] 512 National Institute of Standards and Technology, "NIST 513 Special Publication 800-106: Randomized Hashing for 514 Digital Signatures", February 2009. 516 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 517 Specification", STD 8, RFC 854, May 1983. 519 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 520 April 1992. 522 [RFC2743] Linn, J., "Generic Security Service Application Program 523 Interface Version 2, Update 1", RFC 2743, January 2000. 525 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 526 (SHA1)", RFC 3174, September 2001. 528 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 529 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 531 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 532 Layer Security (TLS) Authentication", RFC 5081, 533 November 2007. 535 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 536 Housley, R., and W. Polk, "Internet X.509 Public Key 537 Infrastructure Certificate and Certificate Revocation List 538 (CRL) Profile", RFC 5280, May 2008. 540 Authors' Addresses 542 Jeff Altman 543 Secure Endpoints 544 255 W 94TH ST PHB 545 New York, NY 10025 546 US 548 Email: jaltman@secure-endpoints.com 550 Nicolas Williams 551 Sun Microsystems 552 5300 Riata Trace Ct 553 Austin, TX 78727 554 US 556 Email: Nicolas.Williams@sun.com 558 Larry Zhu 559 Microsoft Corporation 560 One Microsoft Way 561 Redmond, WA 98052 562 US 564 Email: lzhu@microsoft.com