idnits 2.17.1 draft-altman-tls-channel-bindings-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 30, 2010) is 5134 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 622, 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: October 1, 2010 Oracle 6 L. Zhu 7 Microsoft Corporation 8 March 30, 2010 10 Channel Bindings for TLS 11 draft-altman-tls-channel-bindings-10.txt 13 Abstract 15 This document defines three channel binding types for Transport Layer 16 Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- 17 telnet, in accordance with RFC 5056 (On Channel Binding). 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 1, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Conventions used in this document . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 5 74 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. The 'tls-server-end-point' Channel Binding Type . . . . . . 7 77 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 9 80 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Applicability of TLS Channel Binding Types . . . . . . . . . 11 83 7. Required Application Programming Interfaces . . . . . . . . 14 84 8. Description of backwards-incompatible changes made 85 herein to 'tls-unique' . . . . . . . . . . . . . . . . . . . 15 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 88 10.1. Cryptographic Algorithm Agility . . . . . . . . . . . . . . 17 89 10.2. On Disclosure of Channel Bindings Data by Authentication 90 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 20 93 11.2. Normative References for 'tls-server-end-point' . . . . . . 20 94 11.3. Informative References . . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 97 1. Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 Subsequent to the publication of "On Channel Bindings" [RFC5246], 106 three channel binding types for Transport Layer Security (TLS) were 107 proposed, reviewed and added to the IANA channel binding type 108 registry, all in accordance with [RFC5246]. Those channel binding 109 types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for- 110 telnet'. It has become desirable to have these channel binding types 111 re-registered through an RFC so as to make it easier to reference 112 them, and to correct them to describe actual implementations. This 113 document does just that. The authors of those three channel binding 114 types have, or have indicated that they will, transferred "ownership" 115 of those channel binding types to the IESG. 117 We also provide some advice on the applicability of these channel 118 binding types, as well as advice on when to use which. And we 119 provide an abstract API that TLS implementors should provide, by 120 which to obtain channel bindings data for a TLS connection. 122 WARNING: it turns out that the first implementor implemented and 123 deployed something rather different than what was described in the 124 IANA registration for 'tls-unique'. Subsequently it was decided that 125 we should adopt that form of 'tls-unique'. This means that this 126 document makes a backwards-incompatible change to 'tls-unique'. See 127 Section 8 for more details. 129 3. The 'tls-unique' Channel Binding Type 131 IANA is hereby directed to update the registration of the 'tls- 132 unique' channel binding type to match the following. There are 133 material and substantial changes from the original registration, both 134 in the description as well as registration meta-data (such as 135 registration ownership). 137 3.1. Description 139 Description: The first TLS Finished message sent (note: the Finished 140 struct) in the most recent TLS handshake of the TLS connection being 141 bound to (note: TLS connection, not session, so that the channel 142 binding is specific to each connection regardless of whether session 143 resumption is used). If TLS re-negotiation takes place before the 144 channel binding operation, then the first TLS Finished message sent 145 of the latest/inner-most TLS connection is used. Note that for full 146 TLS handshakes the first Finished message is sent by the client, 147 while for abbreviated TLS handshakes (session resumption) the first 148 Finished message is sent by the server. 150 WARNING: The definition, security and interoperability considerations 151 of this channel binding type have changed since the original 152 registration. Implementors should read the document that last 153 updated this registration for more information. 155 Interoperability note: 157 This definition of tls-unique means that the channel's bindings 158 data may change over time, which in turn creates a synchronization 159 problem should the channel's bindings data change between the time 160 that the client initiates authentication with channel binding and 161 the time that the server begins to process the client's first 162 authentication message. If that happens the authentication will 163 fail spuriously. 165 This synchronization problem can be avoided by clients and servers 166 as follows, based on the fact that while servers may request TLS 167 re-negotiation, only clients may initiate it. Server applications 168 MUST NOT request TLS re-negotiation during phases of the 169 application protocol during which application layer authentication 170 occurs. Client applications SHOULD NOT initiate TLS re- 171 negotiation between the start and completion of authentication. 173 The rationale for making the server behavior a requirement while 174 the client behavior is only a recommendation is that there 175 typically exist TLS APIs for requesting re-negotiation on the 176 server side of a TLS connection, while many client TLS stacks do 177 not provide fine-grained control over when TLS re-negotiation 178 occurs. 180 Application protocols should be designed in such a way that a 181 server would never need to request TLS re-negotiation immediately 182 before or during application-layer authentication. 184 3.2. Registration 186 o Channel binding unique prefix: tls-unique 188 o Channel binding type: unique 190 o Channel type: TLS [RFC5246] 192 o Published specification: 194 o Channel binding is secret: no 196 o Description: 198 o Intended usage: COMMON 200 o Person and email address to contact for further information: Larry 201 Zhu (lzhu@microsoft.com), Nicolas Williams 202 (Nicolas.Williams@sun.com). 204 o Owner/Change controller name and email address: IESG. 206 o Expert reviewer name and contact information: IETF TLS WG 207 (tls@ietf.org, failing that, ietf@ietf.org) 209 o Note: see the published specification for advice on the 210 applicability of this channel binding type. 212 4. The 'tls-server-end-point' Channel Binding Type 214 IANA is hereby directed to update the registration of the 'tls- 215 server-end-point' channel binding type to match the following. Note 216 that the only material changes from the original registration should 217 be: the "owner" (now the IESG), the contacts, the published 218 specfication, and a note indicating that the published specification 219 should be consulted for applicability advice. References were added 220 to the description. All other fields of the registration are copied 221 here for the convenience of readers. 223 4.1. Description 225 Description: The hash of the TLS server's certificate [RFC5280] as it 226 appears, octet for octet, in the server's Certificate message (note 227 that the Certificate message contains a certificate_list, the first 228 element of which is the server's certificate). 230 The hash function is to be selected as follows: 232 o if the certificate's signatureAlgorithm uses a single hash 233 function, and that hash function is either MD5 [RFC1321] or SHA-1 234 [RFC3174] then use SHA-256 [FIPS-180-2]; 236 o if the certificate's signatureAlgorithm uses a single hash 237 function and that hash function neither MD5 nor SHA-1, then use 238 the hash function associated with the certificate's 239 signatureAlgorithm; 241 o if the certificate's signatureAlgorithm uses no hash functions or 242 multiple hash functions, then this channel binding type's channel 243 bindings are undefined at this time (updates to is channel binding 244 type may occur to address this issue if it ever arises). 246 The reason for using a hash of the certificate is that some 247 implementations need to track the channel binding of a TLS session in 248 kernel-mode memory, which is often at a premium. 250 4.2. Registration 252 o Channel binding unique prefix: tls-server-end-point 254 o Channel binding type: end-point 256 o Channel type: TLS [RFC5246] 258 o Published specification: 259 o Channel binding is secret: no 261 o Description: 263 o Intended usage: COMMON 265 o Person and email address to contact for further information: Larry 266 Zhu (lzhu@microsoft.com), Nicolas Williams 267 (Nicolas.Williams@sun.com). 269 o Owner/Change controller name and email address: IESG. 271 o Expert reviewer name and contact information: IETF TLS WG 272 (tls@ietf.org, failing that, ietf@ietf.org) 274 o Note: see the published specification for advice on the 275 applicability of this channel binding type. 277 5. The 'tls-unique-for-telnet' Channel Binding Type 279 IANA is hereby directed to update the registration of the 'tls- 280 unique-for-telnet' channel binding type to match the following. Note 281 that the only material changes from the original registration should 282 be: the "owner" (now the IESG), the contacts, the published 283 specfication, and a note indicating that the published specification 284 should be consulted for applicability advice. The description is 285 also clarified. We also moved security considerations notes to the 286 security considerations section of this document. All other fields 287 of the registration are copied here for the convenience of readers. 289 5.1. Description 291 Description: There is a proposal for adding a "StartTLS" extension to 292 TELNET, and a channel binding extension for the various TELNET AUTH 293 mechanisms whereby each side sends the other a "checksum" (MAC) of 294 their view of the channel's bindings. The client uses the TLS 295 Finished messages (note: the Finished struct) sent by the client and 296 server, each concatenated in that order and in their clear text form, 297 of the first TLS handshake of the connection being bound to. The 298 server does the same but in the opposite concatenation order (server, 299 then client). 301 5.2. Registration 303 o Channel binding unique prefix: tls-unique-for-telnet 305 o Channel binding type: unique 307 o Channel type: TLS [RFC5246] 309 o Published specification: 311 o Channel binding is secret: no 313 o Description: 315 o Intended usage: COMMON 317 o Person and email address to contact for further information: Jeff 318 Altman (jaltman@secure-endpoints.com), Nicolas Williams 319 (Nicolas.Williams@sun.com). 321 o Owner/Change controller name and email address: IESG. 323 o Expert reviewer name and contact information: IETF TLS WG 324 (tls@ietf.org, failing that, ietf@ietf.org) 326 o Note: see the published specification for advice on the 327 applicability of this channel binding type. 329 6. Applicability of TLS Channel Binding Types 331 The 'tls-unique-for-telnet' channel binding type is only applicable 332 to TELNET [RFC0854], and is available for all TLS connections. 334 The 'tls-unique' channel binding type is available for all TLS 335 connections, while 'tls-server-end-point' is only available when TLS 336 cipher suites with server certificates are used, specifically: cipher 337 suites that use the Certificate handshake message, which typically 338 involve the use of PKIX [RFC5280]. For example, 'tls-server-end- 339 point' is available when using TLS ciphers suites such as (this is 340 not an exhaustive list): 342 o TLS_DHE_DSS_WITH_* 344 o TLS_DHE_RSA_WITH_* 346 o TLS_DH_DSS_WITH_* 348 o TLS_DH_RSA_WITH_* 350 o TLS_ECDHE_ECDSA_WITH_* 352 o TLS_ECDHE_RSA_WITH_* 354 o TLS_ECDH_ECDSA_WITH_* 356 o TLS_ECDH_RSA_WITH_* 358 o TLS_RSA_PSK_WITH_* 360 o TLS_RSA_WITH_* 362 o TLS_SRP_SHA_DSS_WITH_* 364 o TLS_SRP_SHA_RSA_WITH_* 366 but is not available when using TLS cipher suites such as (this is 367 not an exhaustive list): 369 o TLS_DHE_PSK_WITH_* 371 o TLS_DH_anon_WITH_* 373 o TLS_ECDHE_PSK_WITH_* 375 o TLS_ECDH_anon_WITH_* 376 o TLS_KRB5_WITH_* 378 o TLS_PSK_WITH_* 380 o TLS_SRP_SHA_WITH_* 382 Nor is 'tls-server-end-point' applicable for use with OpenPGP server 383 certificates [RFC5081] [RFC4880] (since these don't use the 384 Certificate handshake message). 386 Therefore 'tls-unique' is generally better than 'tls-server-end- 387 point'. However, 'tls-server-end-point' may be used with existing 388 TLS server-side proxies ("concentrators") without modification to the 389 proxies, whereas 'tls-unique' may require firmware or software 390 updates to server-side proxies. Therefore there may be cases where 391 'tls-server-end-point' may interoperate but where 'tls-unique' may 392 not. 394 Also, authentication mechanisms may arise which depend on channel 395 bindings to contribute entropy, in which case unique channel bindings 396 would have to always be used in preference to end-point channel 397 bindings. At this time there are no such mechanisms, though one such 398 SASL mechanism has been proposed. Whether such mechanisms should be 399 allowed is out of scope for this document. 401 In other words, for many applications there may be two potentially 402 applicable TLS channel binding types. Channel binding is all or 403 nothing for the GSS-API [RFC2743], and likely other frameworks. 404 Therefore agreement on the use of channel binding, and a particular 405 channel binding type is necessary. Such agreement can be obtained a 406 priori, by convention, or negotiated. 408 The specifics of whether and how to negotiate channel binding types 409 are beyond the scope of this document. However, it is RECOMMENDED 410 that application protocols making use of TLS channel bindings, use 411 'tls-unique' exclusively, except, perhaps, where server-side proxies 412 are common in deployments of an application protocol. In the latter 413 case an application protocol MAY specify that 'tls-server-end-point' 414 channel bindings must be used when available, with 'tls-unique' being 415 used when 'tls-server-end-point' channel bindings are not available. 416 Alternatively, the application may negotiate which channel binding 417 type to use, or may make the choice of channel binding type 418 configurable. 420 Specifically, application protocol specifications MUST indicate at 421 least one mandatory to implement channel binding type, MAY specify a 422 negotiation protocol, MAY allow for out-of-band negotiation or 423 configuration, and SHOULD have a preference for 'tls-unique' over 424 'tls-server-end-point'. 426 7. Required Application Programming Interfaces 428 TLS implementations supporting the use of 'tls-unique' and/or 'tls- 429 unique-for-telnet' channel binding types, MUST provide application 430 programming interfaces by which applications (clients and servers 431 both) may obtain the channel bindings for a TLS connection. Such 432 interfaces may be expressed in terms of extracting the channel 433 bindings data for a given connection and channel binding type. 434 Alternatively the implementor may provide interfaces by which to 435 obtain the initial client Finished message, the initial server 436 Finished message and/or the server certificate (in a form that 437 matches the description of the 'tls-server-end-point' channel binding 438 type). In the latter case the application has to have knowledge of 439 the channel binding type descriptions from this document. This 440 document takes no position on which form these application 441 programming interfaces must take. 443 TLS implementations supporting TLS re-negotiation SHOULD provide APIs 444 that allow for application control over when re-negotiation can take 445 place. For example, a TLS client implementation may provide a 446 "callback" interface to indicate that the server requested re- 447 negotiation, but may not start re-negotiation until the application 448 calls a function to indicate that now is a good time to re-negotiate. 450 8. Description of backwards-incompatible changes made herein to 'tls- 451 unique' 453 The original description of 'tls-unique' read as follows: 455 |OLD| Description: The client's TLS Finished message (note: the 456 |OLD| Finished struct) from the first handshake of the connection 457 |OLD| (note: connection, not session, so that the channel binding 458 |OLD| is specific to each connection regardless of whether session 459 |OLD| resumption is used). 461 Original 'tls-unique' description 463 In other words: the client's Finished message from the first handhske 464 of a connection, regardless of whether that handshake was a full or 465 abbreviated handshake, and regardless of how many subsequent 466 handshakes (re-negotiations) might have followed. 468 As explained in Section 2 this is no longer the description of 'tls- 469 unique', and the new description is not backwards compatible with the 470 original except in the case of TLS connections where: a) only one 471 handshake has taken place before application-layer authentication, 472 and b) that one handshake was a full handshake. 474 This change has a number of implications: 476 o Backwards-incompatibility. It is possible that some 477 implementations of the original 'tls-unique' channel binding type 478 may have been deployed. We know of at least one TLS 479 implementation that exports 'tls-unique' channel bindings with the 480 original semantics, but we know of no deployed application using 481 the same. Implementations of the original and new 'tls-unique' 482 channel binding type will only interoperate when: a) full TLS 483 handshakes are used, b) TLS re-negotiation is not used. 485 o Security considerations -- see Section 10. 487 o Interoperability considerations. As described in Section 3 the 488 new definition of the 'tls-unique' channel binding type has an 489 interoperability problem that may result in spurious 490 authentication failures unless the application implements one or 491 both of the the techniques described in that section. 493 9. IANA Considerations 495 The IANA is hereby directed to update three existing channel binding 496 type registrations. See the rest of this document. 498 10. Security Considerations 500 The Security Considerations sections of [RFC5056], [RFC5246] and 501 [RFC5746] apply to this document. 503 The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known 504 to both endpoints of a TLS connection, and are cryptographycally 505 bound to it. For implementations of TLS that correctly handle re- 506 negotiation [RFC5746] each handshake on a TLS connection is bound to 507 the preceding handshake, if any. Therefore the TLS Finished messages 508 can be safely used as a channel binding provided that the 509 authentication mechanism doing the channel binding conforms to the 510 requirements in [RFC5056]. Applications utilizing 'tls-unique' 511 channel binding with TLS implementations without support for secure 512 re-negotiation [RFC5746] MUST ensure that that ChangeCipherSpec has 513 been used in any and all re-negotiations prior to application-layer 514 authentication, and MUST discard any knowledge learned from the 515 server prior to the completion of application-layer authentication. 517 The server certificate, when present, is also cryptographically bound 518 to the TLS connection through its use in key transport and/or 519 authentication of the server (either by dint of its use in key 520 transport, by its use in signing key agreement, or by its use in key 521 agreement). Therefore the server certificate is suitable as an end- 522 point channel binding as described in [RFC5056]. 524 10.1. Cryptographic Algorithm Agility 526 The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do 527 not add any use of cryptography beyond that used by TLS itself. 528 Therefore these two channel binding types add no considerations with 529 respect to cryptographic algorithm agility. 531 The 'tls-server-end-point' channel binding type consist of a hash of 532 a server certificate. The reason for this is to produce manageably 533 small channel binding data, as some implementations will be using 534 kernel-mode memory (which is typically scarce) to store these. This 535 use of a hash algorithm is above and beyond TLS's use of 536 cryptography, therefore the 'tls-server-end-point' channel binding 537 type has a security consideration with respect to hash algorithm 538 agility. The algorithm to be used, however, is derived from the 539 server certificate's signature algorithm as described in Section 4.1; 540 to recap: use SHA-256 if the certificate signature algorithm uses MD5 541 or SHA-1, else use whatever hash function the certificate uses 542 (unless the signature algorithm uses no hash functions or more than 543 one hash function, in which case 'tls-server-end-point' is 544 undefined). This construction automatically makes 'tls-server-end- 545 point' hash algorithm agile, with a dependency on PKIX and TLS for 546 hash agility. 548 Current proposals for randomized signatures algorithms 549 [I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in 550 their construction -- a single hash function in each algorithm. 551 Therefore the 'tls-server-end-point' channel binding type should be 552 available even in cases where new signatures algorithms are used that 553 are based on current randomized hashing proposals (but we cannot 554 guarantee this, of course). 556 10.2. On Disclosure of Channel Bindings Data by Authentication 557 Mechanisms 559 When these channel binding types were first considered, one issue 560 that some commenters were concerned about was the possible impact on 561 the security of the TLS channel, of disclosure of the channel 562 bindings data by authentication mechanisms. This can happen, for 563 example, when an authentication mechanism transports the channel 564 bindings data, with no confidentiality protection, over other 565 transports (for example, in communicating with a trusted third 566 party), or when the TLS channel provides no confidentiality 567 protection and the authentication mechanism does not protect the 568 confidentiality of the channel bindings data. This section considers 569 that concern. 571 When the TLS connection uses a cipher suite that does not provide 572 confidentiality protection, the TLS Finished messages will be visible 573 to eavesdroppers, regardless of what the authentication mechanism 574 does. The same is true of the server certificate which, in any case, 575 is generally visible to eavesdroppers. Therefore we must consider 576 our choices of TLS channel bindings here to be safe to disclose by 577 definition -- if that were not the case then TLS with cipher suites 578 that don't provide confidentiality protection would be unsafe. 579 Furthermore, the TLS Finished message construction depends on the 580 security of the TLS PRF, which in turn needs to be resistant to key 581 recovery attacks, and we think that it is, as it is based on HMAC, 582 and the master secret is, well, secret (and the result of key 583 exchange). 585 Note too that in the case of an attempted active man-in-the-middle 586 attack, the attacker will already possess knowledge of the TLS 587 finished messages for both inbound and outbound TLS channels (which 588 will differ, given that the attacker cannot force them to be the 589 same). No additional information is obtained by the attacker from 590 the authentication mechanism's disclosure of channel bindings data -- 591 the attacker already has it, even when cipher suites providing 592 confidentiality protection are provided. 594 None of the channel binding types defined herein produce channel 595 bindings data that must be kept secret. Moreover, none of the 596 channel binding types defined herein can be expected to be private 597 (known only to the end-points of the channel), except that the unique 598 TLS channel binding types can be expected to be private when a cipher 599 suite that provides confidentiality protection is used to protect the 600 Finished message exchanges and the application data records 601 containing application-layer authentication messages. 603 11. References 605 11.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 611 Channels", RFC 5056, November 2007. 613 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 614 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 616 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 617 "Transport Layer Security (TLS) Renegotiation Indication 618 Extension", RFC 5746, February 2010. 620 11.2. Normative References for 'tls-server-end-point' 622 [FIPS-180-2] 623 United States of America, National Institute of Standards 624 and Technology, "Secure Hash Standard (Federal Information 625 Processing Standard (FIPS) 180-2". 627 11.3. Informative References 629 [I-D.irtf-cfrg-rhash] 630 Halevi, S. and H. Krawczyk, "Strengthening Digital 631 Signatures via Randomized Hashing", 632 draft-irtf-cfrg-rhash-01 (work in progress), October 2007. 634 [NIST-SP.800-106.2009] 635 National Institute of Standards and Technology, "NIST 636 Special Publication 800-106: Randomized Hashing for 637 Digital Signatures", February 2009. 639 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 640 Specification", STD 8, RFC 854, May 1983. 642 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 643 April 1992. 645 [RFC2743] Linn, J., "Generic Security Service Application Program 646 Interface Version 2, Update 1", RFC 2743, January 2000. 648 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 649 (SHA1)", RFC 3174, September 2001. 651 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 652 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 654 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 655 Layer Security (TLS) Authentication", RFC 5081, 656 November 2007. 658 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 659 Housley, R., and W. Polk, "Internet X.509 Public Key 660 Infrastructure Certificate and Certificate Revocation List 661 (CRL) Profile", RFC 5280, May 2008. 663 Authors' Addresses 665 Jeff Altman 666 Secure Endpoints 667 255 W 94TH ST PHB 668 New York, NY 10025 669 US 671 Email: jaltman@secure-endpoints.com 673 Nicolas Williams 674 Oracle 675 5300 Riata Trace Ct 676 Austin, TX 78727 677 US 679 Email: Nicolas.Williams@oracle.com 681 Larry Zhu 682 Microsoft Corporation 683 One Microsoft Way 684 Redmond, WA 98052 685 US 687 Email: lzhu@microsoft.com