idnits 2.17.1 draft-altman-tls-channel-bindings-05.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 (June 29, 2009) is 5414 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 473, 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: December 31, 2009 Sun 6 L. Zhu 7 Microsoft Corporation 8 June 29, 2009 10 Channel Bindings for TLS 11 draft-altman-tls-channel-bindings-05.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 December 31, 2009. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 18 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 (ietf@ietf.org) 148 o Note: see the published specification for advice on the 149 applicability of this channel binding type. 151 4. The 'tls-server-end-point' Channel Binding Type 153 IANA is hereby directed to update the registration of the 'tls- 154 server-end-point' channel binding type to match the following. Note 155 that the only material changes from the original registration should 156 be: the "owner" (now the IESG), the contacts, the published 157 specfication, and a note indicating that the published specification 158 should be consulted for applicability advice. References were added 159 to the description. All other fields of the registration are copied 160 here for the convenience of readers. 162 4.1. Description 164 Description: The hash of the TLS server's end entity certificate 165 [RFC5280] as it appears, octet for octet, in the server's Certificate 166 message (note that the Certificate message contains a 167 certificate_list, the first element of which is the server's end 168 entity certificate.) The hash function to be selected is as follows: 169 if the certificate's signature hash algorithm is either MD5 [RFC1321] 170 or SHA-1 [RFC3174], then use SHA-256 [FIPS-180-2], otherwise use the 171 certificate's signature hash algorithm. 173 The reason for using a hash of the certificate is that some 174 implementations need to track the channel binding of a TLS session in 175 kernel-mode memory, which is often at a premium. 177 4.2. Registration 179 o Channel binding unique prefix: tls-server-end-point 181 o Channel binding type: end-point 183 o Channel type: TLS [RFC5246] 185 o Published specification: 187 o Channel binding is secret: no 189 o Description: 191 o Intended usage: COMMON 193 o Person and email address to contact for further information: Larry 194 Zhu (lzhu@microsoft.com), Nicolas Williams 195 (Nicolas.Williams@sun.com). 197 o Owner/Change controller name and email address: IESG. 199 o Expert reviewer name and contact information: IETF (ietf@ietf.org) 201 o Note: see the published specification for advice on the 202 applicability of this channel binding type. 204 5. The 'tls-unique-for-telnet' Channel Binding Type 206 IANA is hereby directed to update the registration of the 'tls- 207 unique-for-telnet' channel binding type to match the following. Note 208 that the only material changes from the original registration should 209 be: the "owner" (now the IESG), the contacts, the published 210 specfication, and a note indicating that the published specification 211 should be consulted for applicability advice. The description is 212 also clarified. We also moved security considerations notes to the 213 security considerations section of this document. All other fields 214 of the registration are copied here for the convenience of readers. 216 5.1. Description 218 Description: There is a proposal for adding a "StartTLS" extension to 219 TELNET, and a channel binding extension for the various TELNET AUTH 220 mechanisms whereby each side sends the other a "checksum" (MAC) of 221 their view of the channel's bindings. The client uses the first TLS 222 Finished messages (note: the Finished struct) from the client and 223 server, each concatenated in that order and in their clear text form. 224 The server does the same but in the opposite concatenation order 225 (server, then client). 227 5.2. Registration 229 o Channel binding unique prefix: tls-unique-for-telnet 231 o Channel binding type: unique 233 o Channel type: TLS [RFC5246] 235 o Published specification: 237 o Channel binding is secret: no 239 o Description: 241 o Intended usage: COMMON 243 o Person and email address to contact for further information: Jeff 244 Altman (jaltman@secure-endpoints.com), Nicolas Williams 245 (Nicolas.Williams@sun.com). 247 o Owner/Change controller name and email address: IESG. 249 o Expert reviewer name and contact information: IETF (ietf@ietf.org) 251 o Note: see the published specification for advice on the 252 applicability of this channel binding type. 254 6. Applicability of TLS Channel Binding Types 256 The 'tls-unique-for-telnet' channel binding type is only applicable 257 to TELNET [RFC0854], and is available for all TLS connections. 259 The 'tls-unique' channel binding type is available for all TLS 260 connections, while 'tls-server-end-point' is only available when TLS 261 cipher suites with server certificates are used, specifically: cipher 262 suites that use the Certificate handshake message, which typically 263 involve the use of PKIX [RFC5280]. For example, 'tls-server-end- 264 point' is available when using TLS ciphers suites such as (this is 265 not an exhaustive list): 267 o TLS_DHE_DSS_WITH_* 269 o TLS_DHE_RSA_WITH_* 271 o TLS_DH_DSS_WITH_* 273 o TLS_DH_RSA_WITH_* 275 o TLS_ECDHE_ECDSA_WITH_* 277 o TLS_ECDHE_RSA_WITH_* 279 o TLS_ECDH_ECDSA_WITH_* 281 o TLS_ECDH_RSA_WITH_* 283 o TLS_RSA_PSK_WITH_* 285 o TLS_RSA_WITH_* 287 o TLS_SRP_SHA_DSS_WITH_* 289 o TLS_SRP_SHA_RSA_WITH_* 291 but is not available when using TLS cipher suites such as (this is 292 not an exhaustive list): 294 o TLS_DHE_PSK_WITH_* 296 o TLS_DH_anon_WITH_* 298 o TLS_ECDHE_PSK_WITH_* 300 o TLS_ECDH_anon_WITH_* 301 o TLS_KRB5_WITH_* 303 o TLS_PSK_WITH_* 305 o TLS_SRP_SHA_WITH_* 307 Nor is this channel binding type available for use with OpenPGP 308 server certificates [RFC5081] [RFC4880] (since these don't use the 309 Certificate handshake message). 311 Therefore 'tls-unique' is generally better than 'tls-server-end- 312 point'. However, 'tls-server-end-point' may be used with existing 313 TLS server-side proxies ("concentrators") without modification to the 314 proxies, whereas 'tls-unique' may require firmware or software 315 updates to server-side proxies. Therefore there may be cases where 316 'tls-server-end-point' may interoperate but where 'tls-unique' may 317 not. 319 Also, authentications mechanisms may arise which depend on channel 320 bindings to contribute entropy, in which case unique channel bindings 321 would have to always be used in preference to end-point channel 322 bindings. At this time there are no such mechanisms, though one such 323 SASL mechanism has been proposed. Whether such mechanisms should be 324 allowed is out of scope for this document. 326 In other words, for many applications there may be two potentially 327 applicable TLS channel binding types. Channel binding is all or 328 nothing for the GSS-API [RFC2743], and likely other frameworks. 329 Therefore agreement on the use of channel binding, and a particular 330 channel binding type is necessary. Such agreement can be obtained a 331 priori, by convention, or negotiated. 333 The specifics of whether and how to negotiate channel binding types 334 are beyond the scope of this document. However, it is RECOMMENDED 335 that application protocols making use of TLS channel bindings, use 336 'tls-unique' exclusively, except, perhaps, where server-side proxies 337 are common in deployments of an application protocol. In the latter 338 case an application protocol MAY specify that 'tls-server-end-point' 339 channel bindings must be used when available, with 'tls-unique' being 340 used when 'tls-server-end-point' channel bindings are not available. 341 Alternatively, the application may negotiate which channel binding 342 type to use, or may make the choice of channel binding type 343 configurable. 345 Specifically, application protocol specifications MUST indicate at 346 least one mandatory to implement channel binding type, MAY specify a 347 negotiation protocol, MAY allow for out-of-band negotiation or 348 configuration, and SHOULD have a preference for 'tls-unique' over 349 'tls-server-end-point'. 351 7. Required Application Programming Interfaces 353 TLS implementations supporting the use of 'tls-unique' and/or 'tls- 354 unique-for-telnet' channel binding types, MUST provide application 355 programming interfaces by which applications (clients and servers 356 both) may obtain the channel bindings for a TLS connection. Such 357 interfaces may be expressed in terms of extracting the channel 358 bindings data for a given connection and channel binding type. 359 Alternatively the implementor may provide interfaces by which to 360 obtain the initial client Finished message, the initial server 361 Finished message and/or the server certificate (in a form that 362 matches the description of the 'tls-server-end-point' channel binding 363 type). In the latter case the application has to have knowledge of 364 the channel binding type descriptions from this document. This 365 document takes no position on which form these application 366 programming interfaces must take. 368 8. IANA Considerations 370 The IANA is hereby directed to update three existing channel binding 371 type registrations. See the rest of this document. 373 9. Security Considerations 375 The Security Considerations section of [RFC5056] applies to this 376 document. 378 The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known 379 to both endpoints of a TLS connection, and are cryptographycally 380 bound to it. Therefore the TLS Finished messages can be safely used 381 as a channel binding provided that the authentication mechanism doing 382 the channel binding conforms to the requirements in [RFC5056]. 384 The server certificate, when present, is also cryptographically bound 385 to the TLS connection through its use in key transport and/or 386 authentication of the server (either by dint of its use in key 387 transport, by its use in signing key agreement, or by its use in key 388 agreement). Therefore the server certificate is suitable as an end- 389 point channel binding as described in [RFC5056]. 391 9.1. Cryptographic Algorithm Agility 393 The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do 394 not add any use of cryptography beyond that used by TLS itself. 395 Therefore these two channel binding types add no considerations with 396 respect to cryptographic algorithm agility. 398 The 'tls-server-end-point' channel binding type consist of a hash of 399 a server certificate. The reason for this is to produce manageably 400 small channel binding data, as some implementations will be using 401 kernel-mode memory (which is typically scarce) to store these. This 402 use of a hash algorithm is above and beyond TLS's use of 403 cryptography, therefore the 'tls-server-end-point' channel binding 404 type has a security consideration with respect to hash algorithm 405 agility. The algorithm to be used, however, is derived from the 406 certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1, 407 else use whatever hash function the certificate uses. This 408 construction automatically makes 'tls-server-end-point' hash 409 algorithm agile and depends on PKIX and TLS for hash agility. 411 9.2. On Disclosure of Channel Bindings Data by Authentication 412 Mechanisms 414 When these channel binding types were first considered, one issue 415 that some commenters were concerned about was the possible impact on 416 the security of the TLS channel, of disclosure of the channel 417 bindings data by authentication mechanisms. This can happen, for 418 example, when an authentication mechanism transports the channel 419 bindings data, with no confidentiality protection, over other 420 transports (for example, in communicating with a trusted third 421 party), or when the TLS channel provides no confidentiality 422 protection and the authentication mechanism does not protect the 423 confidentiality of the channel bindings data. This section considers 424 that concern. 426 When the TLS connection uses a cipher suite that does not provide 427 confidentiality protection, the TLS Finished messages will be visible 428 to eavesdroppers, regardless of what the authentication mechanism 429 does. The same is true of the server certificate which, in any case, 430 is generally visible to eavesdroppers. Therefore we must consider 431 our choices of TLS channel bindings here to be safe to disclose by 432 definition -- if that were not the case then TLS with cipher suites 433 that don't provide confidentiality protection would be unsafe. 434 Furthermore, the TLS Finished message construction depends on the 435 security of the TLS PRF, which in turn needs to be resistant to key 436 recovery attacks, and we think that it is, as it is based on HMAC, 437 and the master secret is, well, secret (and the result of key 438 exchange). 440 Note too that in the case of an attempted active man-in-the-middle 441 attack, the attacker will already possess knowledge of the TLS 442 finished messages for both inbound and outbound TLS channels (which 443 will differ, given that the attacker cannot force them to be the 444 same). No additional information is obtained by the attacker from 445 the authentication mechanism's disclosure of channel bindings data -- 446 the attacker already has it, even when cipher suites providing 447 confidentiality protection are provided. 449 None of the channel binding types defined herein produce channel 450 bindings data that must be kept secret. Moreover, none of the 451 channel binding types defined herein can be expected to be private 452 (known only to the end-points of the channel), except that the unique 453 TLS channel binding types can be expected to be private when a cipher 454 suite that provides confidentiality protection is used to protect the 455 Finished message exchanges and the application data records 456 containing application-layer authentication messages. 458 10. References 460 10.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 466 Channels", RFC 5056, November 2007. 468 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 469 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 471 10.2. Normative References for 'tls-server-end-point' 473 [FIPS-180-2] 474 United States of America, National Institute of Standards 475 and Technology, "Secure Hash Standard (Federal Information 476 Processing Standard (FIPS) 180-2". 478 10.3. Informative References 480 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 481 Specification", STD 8, RFC 854, May 1983. 483 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 484 April 1992. 486 [RFC2743] Linn, J., "Generic Security Service Application Program 487 Interface Version 2, Update 1", RFC 2743, January 2000. 489 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 490 (SHA1)", RFC 3174, September 2001. 492 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 493 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 495 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 496 Layer Security (TLS) Authentication", RFC 5081, 497 November 2007. 499 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 500 Housley, R., and W. Polk, "Internet X.509 Public Key 501 Infrastructure Certificate and Certificate Revocation List 502 (CRL) Profile", RFC 5280, May 2008. 504 Authors' Addresses 506 Jeff Altman 507 Secure Endpoints 508 255 W 94TH ST PHB 509 New York, NY 10025 510 US 512 Email: jaltman@secure-endpoints.com 514 Nicolas Williams 515 Sun Microsystems 516 5300 Riata Trace Ct 517 Austin, TX 78727 518 US 520 Email: Nicolas.Williams@sun.com 522 Larry Zhu 523 Microsoft Corporation 524 One Microsoft Way 525 Redmond, WA 98052 526 US 528 Email: lzhu@microsoft.com