idnits 2.17.1 draft-williams-on-channel-binding-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 990. 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 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, 2007) is 6082 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: 'RFC4120' is mentioned on line 110, but not defined == Missing Reference: 'RFC2434' is mentioned on line 660, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-00 == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-00 == Outdated reference: A later version (-07) exists of draft-ietf-btns-core-01 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 == Outdated reference: A later version (-08) exists of draft-ietf-nfsv4-nfsdirect-04 == Outdated reference: A later version (-20) exists of draft-ietf-sasl-gs2-06 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track August 31, 2007 5 Expires: March 3, 2008 7 On the Use of Channel Bindings to Secure Channels 8 draft-williams-on-channel-binding-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 3, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The concept of channel binding allows applications to establish that 42 the two end-points of a secure channel at one network layer are the 43 same as at a higher layer by binding authentication at the higher 44 layer to the channel at the lower layer. This allows applications to 45 delegate session protection to lower layers, which has various 46 performance benefits. 48 This document discusses and formalizes the concept of channel binding 49 to secure channels. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . 4 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Properties of channel binding . . . . . . . . . . . . 6 57 2.2. EAP channel binding . . . . . . . . . . . . . . . . . 9 58 3. Authentication and channel binding semantics . . . . . 11 59 3.1. The GSS-API and channel binding . . . . . . . . . . . 11 60 3.2. SASL and channel binding . . . . . . . . . . . . . . . 11 61 4. Channel bindings specifications . . . . . . . . . . . 13 62 4.1. Examples of unique channel bindings . . . . . . . . . 13 63 4.2. Examples of end-point channel bindings . . . . . . . . 13 64 5. Uses of channel binding . . . . . . . . . . . . . . . 15 65 6. Benefits of channel binding to secure channels . . . . 17 66 7. IANA Considerations . . . . . . . . . . . . . . . . . 18 67 7.1. Registration Procedure . . . . . . . . . . . . . . . . 18 68 7.2. Comments on channel bindings Registrations . . . . . . 19 69 7.3. Change control . . . . . . . . . . . . . . . . . . . . 20 70 8. Security Considerations . . . . . . . . . . . . . . . 21 71 8.1. Non-unique channel bindings and channel binding 72 re-establishment . . . . . . . . . . . . . . . . . . . 21 73 9. References . . . . . . . . . . . . . . . . . . . . . . 23 74 9.1. Normative References . . . . . . . . . . . . . . . . . 23 75 9.2. Informative References . . . . . . . . . . . . . . . . 23 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 77 Author's Address . . . . . . . . . . . . . . . . . . . 27 78 Intellectual Property and Copyright Statements . . . . 28 80 1. Introduction 82 In a number of situations, it is useful for an application to be able 83 to handle authentication within the application layer, while 84 simultaneously being able to utilize session or transport security at 85 a lower network layer. For example, IPsec [RFC4301] [RFC4303] 86 [RFC4302] is amenable to being accelerated in hardware to handle very 87 high link speeds, but IPsec key exchange protocols and the IPsec 88 architecture are not as amenable to use as a security mechanism 89 within applications, particularly applications that have users as 90 clients. A method of combining security at both layers is therefore 91 attractive. To enable this to be done securely, it is necessary to 92 "bind" the mechanisms together -- so as to avoid man-in-the-middle 93 vulnerabilities and enable the mechanisms to be integrated in a 94 seamless way. This is the objective of "Channel Bindings." 96 The term "channel binding" as used in this document derives from the 97 GSS-API [RFC2743], which has a channel binding facility that was 98 intended for binding GSS-API authentication to secure channels at 99 lower network layers. The purpose and benefits of the GSS-API 100 channel binding facility were not discussed at length, and some 101 details were left unspecified. Now we find that this concept can be 102 very useful, therefore we begin with a generalization and 103 formalization of "channel binding" independent of the GSS-API. 105 Although inspired by and derived from the GSS-API, the notion of 106 channel binding described herein is not at all limited to use by GSS- 107 API applications. We envision use of channel binding by applications 108 that utilize other security frameworks, such as SASL [RFC4422] and 109 even protocols that provide their own authentication mechanisms 110 (e.g., the KDC exchanges of Kerberos V [RFC4120]). We also envision 111 use of the notion of channel binding in the analysis of security 112 protocols. 114 The main goal of channel binding is to be able to delegate 115 cryptographic session protection to network layers below the 116 application in hopes of being able to better leverage hardware 117 implementations of cryptographic protocols. Section 5 describes some 118 intended uses of channel binding. Some applications may benefit 119 additionally by reducing the amount of active cryptographic state, 120 thus reducing overhead in accessing such state and, therefore, the 121 impact of security on latency. 123 The critical security problem to solve in order to achieve such 124 delegation of session protection is: ensuring that there is no man- 125 in-the-middle (MITM), from the point of view the application, at the 126 lower network layer to which session protection is to be delegated. 128 And there may well be a MITM, particularly if the lower network layer 129 either provides no authentication or if there is no strong connection 130 between the authentication or principals used at the application and 131 those used at the lower network layer. 133 Even if such MITM attacks seem particularly difficult to effect, the 134 attacks must be prevented for certain applications to be able to make 135 effective use of technologies such as IPsec [RFC2401] [RFC4301] or 136 HTTP with TLS [RFC4346] in certain contexts (e.g., when there is no 137 authentication to speak of, or when one node's set of trust anchors 138 is too weak to believe that it can authenticate its peers). 139 Additionally, secure channels that are susceptible to MITM attacks 140 because they provide no useful end-point authentication are useful 141 when combined with application-layer authentication (otherwise they 142 are only somewhat "better than nothing" -- see BTNS 143 [I-D.ietf-btns-prob-and-applic]). 145 For example, iSCSI [RFC3720] provides for application-layer 146 authentication (e.g., using Kerberos V), but relies on IPsec for 147 transport protection; iSCSI does not provide a binding between the 148 two. iSCSI initiators have to be careful to make sure that the name 149 of the server authenticated at the application layer and the name of 150 the peer at the IPsec layer match -- an informal form of channel 151 binding. 153 This document describes a solution: the use of "channel binding" (in 154 the GSS-API [RFC2743] [RFC2744] sense) to bind authentication at 155 application layers to secure sessions at lower layers in the network 156 stack. 158 1.1. Conventions used in this document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2. Definitions 166 o Secure channel: a packet, datagram, octet stream connection, or 167 sequence of connections, between two end-points that affords 168 cryptographic integrity and, optionally, confidentiality to data 169 exchanged over it. We assume that the channel is secure -- if an 170 attacker can successfully cryptanalyze a channel's session keys, 171 for example, then the channel is not secure. 173 o Channel binding: the process of establishing that no man-in-the- 174 middle exists between two end-points authenticated at one network 175 layer but using a secure channel at a lower network layer. This 176 term is used as a noun. 178 o Channel bindings: [See historical note below.] 180 Generally some data which "names" a channel or one or both of 181 its end-points such that if this data can be shown, at a higher 182 network layer, to be the same at both ends of a channel then 183 there are no MITMs between the two end-points at that higher 184 network layer. This term is used as a noun. 186 More formally, there are two types of channel bindings: 188 + unique channel bindings: 190 channel bindings that name a channel in a cryptographically 191 secure manner and uniquely in time; 193 + end-point channel bindings: 195 channel bindings that name the authenticated end-points, or 196 even a single end-point, of a channel which are, in turn, 197 securely bound to the channel, but which do not identify a 198 channel uniquely in time. 200 o Cryptographic binding: (e.g., "cryptographically bound") a 201 cryptographic operation that causes an object, such as a private 202 encryption or signing key, or an established secure channel, to 203 "speak for" [Lampson91] some principal, such as a user, a 204 computer, etcetera. For example, a PKIX certificate binds a 205 private key to the name of a principal in the trust domain of the 206 certificate's issuer such that a possessor of said private key can 207 act on behalf of the user (or other entity) named by the 208 certificate. 210 Cryptographic bindings are generally asymmetric in nature (not to 211 be confused with symmetric or assymetric key cryptography) in that 212 an object is rendered capable of standing for another, but the 213 reverse is not usually the case (we don't say that a user speaks 214 for their private keys, but we do say that the user's private keys 215 speak for the user). 217 Note that there may be many instances of "cryptographic binding" in 218 an application of channel binding. The credentials that authenticate 219 principals at the application layer bind private or secret keys to 220 the identities of those principals, such that said keys speak for 221 them. A secure channel typically consists symmetric session keys 222 used to provide confidentiality and integrity protection to data sent 223 over the channel; each end-point's session keys speak for that end- 224 point of the channel. Finally, each end-point of a channel bound to 225 authentication at the application layer speaks for the principal 226 authenticated at the application layer on the same side of the 227 channel. 229 The terms defined above have been in use for many years and have been 230 taken to mean, at least in some contexts, what is stated below. 231 Unfortunately this means that "channel binding" can refer to the 232 channel binding operation and, sometimes to the name of a channel, 233 and "channel bindings" -- a difference of only one letter -- 234 generally refers to the name of a channel. 236 Note that the Extensible Authentication Protocol (EAP) [RFC3748] 237 which "channel binding" to refer to a facility appears to be similar 238 to the one described here, but it is, in fact, quite different. See 239 Section 2.2 for more details. 241 2.1. Properties of channel binding 243 Applications, authentication frameworks (e.g., the GSS-API, SASL), 244 security mechanisms (e.g., the Kerberos V GSS-API mechanism 245 [RFC1964]) and secure channels must meet the following requirement 246 and should follow the following recommendations. 248 Requirements: 250 o In order to use channel binding applications MUST verify that the 251 same channel bindings are observed at either side of the channel. 252 To do this the application MUST use an authentication protocol at 253 the application layer to authenticate one, the other or both 254 application peers (one at each end of the channel). 256 * If the authentication protocol used by the application supports 257 channel binding the application SHOULD use it. 259 * An authentication protocol that supports channel binding MUST 260 provide an input slot in its API for a "handle" to the channel, 261 or its channel bindings. 263 * If he authentication protocol does not support a channel 264 binding operation but provides a "security layer" with at least 265 integrity protection, then the application MUST use the 266 authentication protocol's integrity protection facilities to 267 exchange channel bindings, or cryptographic hashes thereof. 269 * The name of the type of channel binding MUST be used by the 270 application and/or authentication protocol to avoid ambiguity 271 about which of several possible types of channels is being 272 bound. If nested instances of the same type of channel are 273 available then the innermost channel MUST be used. 275 o Specifications of channel bindings for any secure channels MUST 276 provide for a single, canonical octet string encoding of the 277 channel bindings. 279 o The channel bindings for a given type of secure channel MUST be 280 constructed in such a way that an MITM could not easily force the 281 channel bindings of a given channel to match those of another. 283 o Unique channel bindings MUST bind not only the key exchange for 284 the secure channel, but also any negotiations and authentication 285 that may have taken place to establish the channel. 287 o End-point channel bindings MUST be bound into the secure channel 288 and all its negotiations. For example, a public key as an end- 289 point channel binding should be used to verify a signature of a 290 such negotiations (or to encrypt them), including the initial key 291 exchange and negotiation messages for that channel -- such a key 292 would then be bound into the channel. A certificate name as end- 293 point channel binding could also be bound into the channel in a 294 similar way, though in the case of a certificate name the binding 295 depends too on the strength of the authentication of that name 296 (that is, the validation of the certificate, the trust anchors, 297 the algorihtms used in the certificate path construction and 298 validation, etcetera). 300 o End-point channel bindings MAY be identifiers (e.g., certificate 301 names) which must be authenticated through some infrastructure, 302 such as a public key infrastructure (PKI). In such cases 303 applications MUST ensure that the channel provides adequate 304 authentication of such identifiers (e.g., that the certificate 305 validation policy and trust anchors used by the channel satisfy 306 the application's requirements). To avoid implementation 307 difficulties in addressing this requirement applications SHOULD 308 use cryptographic quantities as end-point channel bindings, such 309 as certificate subject public keys. 311 o Applications MUST use application-layer session protection 312 services for confidentiality protection when the bound channel 313 does not provide confidentiality protection. 315 o The integrity of a secure channel MUST NOT be weakened should 316 their channel bindings be revealed to an attacker. That is, the 317 construction of the channel bindings for any type of secure 318 channel MUST NOT leak secret information about the channel. End- 319 point channel bindings, however, MAY leak information about the 320 end-points of the channel (e.g., their names). 322 o The channel binding operation MUST be at least integrity protected 323 in the security mechanism used at the application layer. 325 o Authentication frameworks and mechanisms that support channel 326 binding MUST communicate channel binding failure to applications. 328 o Applications MUST NOT send sensitive information, requiring 329 confidentiality protect, over the underlying channel prior to 330 completing the channel binding operation. 332 Recommendations: 334 o End-point channel bindings where the end-points are meaningful 335 names SHOULD NOT be used when the channel does not provide 336 confidentiality protection and privacy protection is desired. 337 Alternatively channels that export such channel bindings SHOULD 338 provide for the use of a digest and SHOULD NOT introduce new 339 digest/hash agility problems as a result. 341 Options: 343 o Authentication frameworks and mechanisms that support channel 344 binding MAY fail to establish authentication if channel binding 345 fails. 347 o Applications MAY send information information over the underlying 348 channel and without intergrity protection from the application- 349 layer authentication protocol prior to completing the channel 350 binding operation if such information requires only integrity 351 protection. This could be useful for optimistic negotiations. 353 o A security mechanism MAY exchange integrity protected channel 354 bindings. 356 o A security mechanism MAY exchange integrity protected digests of 357 channel bindings. Such mechanisms SHOULD provide for hash/digest 358 agility. 360 o A security mechanism MAY use channel bindings in key exchange, 361 authentication or key derivation, prior to the exchange of 362 "authenticator" messages. 364 2.2. EAP channel binding 366 This section is informative. This document does not update EAP 367 [RFC3748], it neither normatively describes, nor does it impose 368 requirements on any aspect of EAP or EAP methods. 370 EAP [RFC3748] includes a concept of channel binding desribed as 371 follows: 373 The communication within an EAP method of integrity-protected 374 channel properties such as endpoint identifiers which can be 375 compared to values communicated via out of band mechanisms (such 376 as via a AAA or lower layer protocol). 378 Section 7.15 of [RFC3748] describes the problem as one where a a 379 Network Access Server (NAS), (a.k.a. "authenticator") may like to the 380 peer (client) and cause the peer to make incorrect authorization 381 decisions (e.g., as to what traffic may transit through the NAS). 382 This is not quite like the purpose of generic channel binding (MITM 383 detection). 385 Section 7.15 of [RFC3748] calls for "a protected exchange of channel 386 properties such as endpoint identifiers" such that "it is possible to 387 match the channel properties provided by the authenticator via out- 388 of-band mechanisms against those exchanged within the EAP method." 390 This has sometimes been taken to be very similar to the generic 391 notion of channel binding provided here. However, these is a very 392 subtle difference between the two concepts of channel binding that 393 makes it much too difficult to put forth requirements and 394 recommendations that apply to both. The difference is about the 395 lower-layer channel: 397 o in the generic channel binding case the identities of either end 398 of this channel are irrelevant to anything other than the 399 construction of a name for that channel, in which case the 400 identities of the channel's end-points must be established a 401 priori, 403 o whereas in the EAP case the identity of the NAS end of the 404 channel, and even security properties of the channel itself, may 405 be established during or after authentication of the EAP peer to 406 the EAP server. 408 In other words: there is a fundamental difference in mechanics 409 (timing of lower-layer channel establishment) and in purpose 410 (authentication of lower layer channel properties for authorization 411 purposes vs. MITM detection). 413 After some discussion we have concluded that there is no simple way 414 to obtain requirements and recommendations that apply to both, 415 generic and EAP channel binding. Therefore EAP is out of the scope 416 of this document. 418 3. Authentication and channel binding semantics 420 Some authentication frameworks and/or mechanisms provide for channel 421 binding, such as the GSS-API and some GSS-API mechanisms, whereas 422 others may not, such as SASL (however, ongoing work is adding channel 423 binding support to SASL). Semantics may vary with respect to 424 negotiation, how the binding occurs, and handling of channel binding 425 failure (see below). 427 Where suitable channel binding facilities are not provided, 428 application protocols MAY include a separate, protected exchange of 429 channel bindings. In order to do this the application-layer 430 authentication service must provide message protection services, at 431 least integrity protection. 433 3.1. The GSS-API and channel binding 435 The GSS-API [RFC2743] provides for the use of channel binding during 436 initialization of GSS-API security contexts, though GSS-API 437 mechanisms are not required to support this facility. 439 This channel binding facility is described in [RFC2743] and 440 [RFC2744]. 442 GSS-API mechanisms must fail security context establishment when 443 channel binding fails, and the GSS-API provides no mechanism for the 444 negotiation of channel binding. As a result GSS-API applications 445 must agree a priori, through negotiation or otherwise, on the use of 446 channel binding. 448 Fortunately, it is possible to design GSS-API pseudo-mechanisms that 449 simply wrap around existing mechanisms for the purpose of allowing 450 applications to negotiate the use of channel binding within their 451 existing methods for negotiating GSS-API mechanisms. For example, 452 NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as 453 does the SSHv2 protocol [RFC4462]. Such pseudo-mechanisms are being 454 proposed separately, see [I-D.ietf-kitten-stackable-pseudo-mechs]. 456 3.2. SASL and channel binding 458 SASL [RFC4422] does not yet provide for the use of channel binding 459 during initialization of SASL contexts. 461 Work is ongoing [I-D.ietf-sasl-gs2] to specify how SASL, particularly 462 it's new bridge to the GSS-API, performs channel binding. SASL will 463 likely differ from the GSS-API in its handling of channel binding 464 failure (i.e., when there may be a MITM) in that channel binding 465 success/failure will only affect the negotiation of SASL security 466 layers. I.e., when channel binding succeeds SASL should select no 467 security layers, leaving session cryptographic protection to the 468 secure channel that has been bound to. 470 4. Channel bindings specifications 472 Channel bindings for various types of secure channels are not 473 described herein. Some channel bindings specifications can be found 474 in: 476 +--------------------+----------------------------------------------+ 477 | Secure Channel | Reference | 478 | Type | | 479 +--------------------+----------------------------------------------+ 480 | SSHv2 | [I-D.williams-sshv2-channel-bindings] | 481 | | | 482 | TLS | [I-D.altman-tls-channel-bindings] | 483 | | | 484 | IPsec | There is no specification for IPsec channel | 485 | | bindings yet, but the IETF Better Than | 486 | | Nothing Security (BTNS) WG is working to | 487 | | specify IPsec channels, and possibly IPsec | 488 | | channel bindings. | 489 +--------------------+----------------------------------------------+ 491 4.1. Examples of unique channel bindings 493 The following text is not normative, but is here to show how one 494 might construct channel bindings for various types of secure 495 channels. 497 For SSHv2 [RFC4251] the SSHv2 session ID should suffice as it is a 498 cryptographic binding of all relevant SSHv2 connection parameters: 499 key exchange and negotiation. 501 For TLS [RFC4346]the TLS session ID is not sufficient as it is 502 assigned by the server, and so could be assigned by an MITM to match 503 a server's. Instead the initial, unencrypted TLS finished messages, 504 either the client's, the server's or both, are sufficient as they are 505 the output of the TLS PRF, keyed with the session key, applied to all 506 handshake material. 508 4.2. Examples of end-point channel bindings 510 The following text is not normative, but is here to show how one 511 might construct channel bindings for various types of secure 512 channels. 514 For SSHv2 [RFC4251] the SSHv2 host public key, when present, should 515 suffice as it is used to sign the algorithm suite negotiation and 516 Diffie-Hellman key exchange; as long the client observes the host 517 public key that corresponds to the private host key that the server 518 used then there cannot be a MITM in the SSHv2 connection. Note that 519 not all SSHv2 key exchanges use host public keys, therefore this 520 channel bindings construction is not as useful as the one given in 521 Section 4.1 above. 523 For TLS [RFC4346]the server certificate should suffice for the same 524 reasons as above. Again, not all TLS cipher suites involve server 525 certificates, therfore the utility of this construction of channel 526 bindings is limited to scenarios where server certificates are 527 commonly used. 529 5. Uses of channel binding 531 Uses for channel binding identified so far: 533 o Delegating session cryptographic protection to layers where 534 hardware can reasonably be expected to support relevant 535 cryptographic protocols: 537 * NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP) 538 [I-D.ietf-nfsv4-nfsdirect] for zer-copy reception where network 539 interface controllers (NICs) support RDDP. Cryptographic 540 session protection would be delegated to ESP/AH [RFC4303] 541 [RFC4302]. 543 * iSCSI [RFC3720] with Remote Direct Memory Access (RDMA) 544 [I-D.ietf-ips-iser]. Cryptographic session protection would be 545 delegated to ESP/AH. 547 * HTTP with TLS [RFC2817] [RFC2818]. In situations involving 548 proxies users may want to bind authentication to a TLS channel 549 between the last client-side proxy and the first server-side 550 proxy ("concentrator"). There is ongoing work to expand the 551 set of choices for end-to-end authentication at the HTTP layer, 552 which coupled with channel binding to TLS would allow for 553 proxies while not forgoing protection over public internets. 555 o Reducing the number of live cryptographic contexts that an 556 application must maintain: 558 * NFSv4 [RFC3530] multiplexes multiple users onto individual 559 connections. Each user is authenticated separately and user's 560 RPCs are protected with per-user GSS-API security contexts. 561 This means that large timesharing clients must often maintain 562 many cryptographic contexts per-NFSv4 conenction. With channel 563 binding to IPsec they could maintain a much smaller number of 564 cryptographic contexts per-NFSv4 connection, thus reducing 565 memory pressure and interactions with cryptographic hardware. 567 For example, applications that wish to use RDDP to achieve zero-copy 568 semantics on reception may use a network layer understood by network 569 interface controllers (NIC) to offload delivery of application data 570 into pre-arranged memory buffers. Note that in order to obtain zero- 571 copy reception semantics either application data has to be in 572 cleartext relative to this RDDP layer, or the RDDP implementation 573 must know how to implement cryptographic session protection protocols 574 used at the application layer. 576 There are a multitude of application layer cryptographic session 577 protection protocols available. It is not reasonable to expect the 578 NICs should support many such protocols. Further, some application 579 protocols may maintain many cryptographic session contexts per- 580 connection (for example, NFSv4 does). It is thought to be simpler to 581 push the cryptographic session protection down the network stack (to 582 IPsec), and yet be able to produce NICs that offload other operations 583 (i.e. - TCP/IP, ESP/AH, and DDP), than it would be to add support in 584 the NIC for the many session cryptographic protection protocols in 585 use in common applications at the application layer. 587 The following figure shows how the various network layers are 588 related: 590 +---------------------+ 591 | Application layer |<---+ 592 | |<-+ | In cleartext, relative 593 +---------------------+ | | to each other. 594 | RDDP |<---+ 595 +---------------------+ | 596 | TCP/SCTP |<-+ 597 +---------------------+ | Channel binding of app-layer 598 | ESP/AH |<-+ authentication to IPsec 599 +---------------------+ 600 | IP | 601 +---------------------+ 602 | ... | 603 +---------------------+ 605 6. Benefits of channel binding to secure channels 607 The use of channel binding to delegate session cryptographic 608 protection include: 610 o Performance improvements by avoiding double protection of 611 application data in cases where IPsec is in use and applications 612 provide their own secure channels. 614 o Performance improvements by leveraging hardware-accelerated IPsec. 616 o Performance improvements by allowing RDDP hardware offloading to 617 be integrated with IPsec hardware acceleration. 619 Where protocols layered above RDDP use privacy protection RDDP 620 offload cannot be done, thus by using channel binding to IPsec 621 the privacy protection is moved to IPsec, which is layered 622 below RDDP, so RDDP can address application protocol data 623 that's in cleartext relative to the RDDP headers. 625 o Latency improvements for applications that multiplex multiple 626 users onto a single channel, such as NFS w/ RPCSEC_GSS. 628 Delegation of session cryptographic protection to IPsec requires 629 features not yet specified. There is ongoing work to specify: 631 o IPsec channels [I-D.ietf-btns-connection-latching]; 633 o Application programming interfaces (APIs) related to IPsec 634 channels [I-D.ietf-btns-ipsec-apireq]; 636 o Channel bindings for IPsec channels; 638 o Low infrastructure IPsec authentication[I-D.ietf-btns-core]. 640 7. IANA Considerations 642 The IANA is hereby requested to create a new registry for channel 643 bindings specifciations for various types of channels. 645 The purpose of this registry is not only to ensure uniqueness of 646 values used to name channel bindings, but also to provide a 647 definitive reference to technical specifications detailing each 648 channel binding available for use on the Internet. 650 There is no naming convention for channel bindings: any string 651 composed of US-ASCII alphanumeric characters, period ('.') and dash 652 ('-') will suffice. 654 The procedure detailed in Section 7.1 is to be used for registration 655 of a value naming a specific individual mechanism. 657 7.1. Registration Procedure 659 Registration of a new channel binding requires expert review as 660 defined in BCP 26 [RFC2434]. 662 Registration of a channel binding is requested by filling in the 663 following template: 665 o Subject: Registration of channel binding X 667 o Channel binding unique prefix (name): 669 o Channel binding type: (One of "unique" or "end-point") 671 o Channel type: (E.g., TLS, IPsec, SSH, etc...) 673 o Published specification (recommended, optional): 675 o Channel binding is secret (requires confidentiality protection): 676 yes/no 678 o Description (optional if a specification is given; required if no 679 Published specification is specified): 681 o Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 683 o Person and email address to contact for further information: 685 o Owner/Change controller name and email address: 687 o Expert reviewer name and contact information: (leave blank) 689 o Note: (Any other information that the author deems relevant may be 690 added here.) 692 and sending it via electronic mail to channel-binding@ietf.org (a 693 public mailing list) and carbon copying IANA at . 694 After allowing two weeks for community input on the mailing list to 695 be determined, an expert will determine the appropriateness of the 696 registration request and either approve or disapprove the request 697 with notice to the requestor, the mailing list, and IANA. 699 If the expert approves registration, it adds her/his name to the 700 submitted registration. 702 The expert has the primary responsibility of making sure that channel 703 bindings for IETF specifications go through the IETF consensus 704 process and that prefixes are unique. 706 The review should focus on the appropriateness of the requested 707 channel binding for the proposed use, the appropriateness of the 708 proposed prefix and correctness of the channel binding type in the 709 registration. The scope of this request review may entail 710 consideration of relevant aspects of any provided technical 711 specification, such as their IANA Considerations section. However, 712 this review is narrowly focused on the appropriateness of the 713 requested registration and not on the overall soundness of any 714 provided technical specification. 716 Authors are encouraged to pursue community review by posting the 717 technical specification as an Internet-Draft and soliciting comment 718 by posting to appropriate IETF mailing lists. 720 7.2. Comments on channel bindings Registrations 722 Comments on a registered Channel bindings should first be sent to the 723 "owner" of the channel bindings and to the channel binding mailing 724 list. 726 Submitters of comments may, after a reasonable attempt to contact the 727 owner, request IANA to attach their comment to the channel binding 728 type registration itself by sending mail to . At 729 IANA's sole discretion, IANA may attach the comment to the Channel 730 binding's registration. 732 7.3. Change control 734 Once a channel bindings registration has been published by IANA, the 735 author may request a change to its definition. The change request 736 follows the same procedure as the registration request. 738 The owner of a channel bindings may pass responsibility for the 739 channel bindings to another person or agency by informing IANA; this 740 can be done without discussion or review. 742 The IESG may reassign responsibility for a Channel bindings. The 743 most common case of this will be to enable changes to be made to 744 mechanisms where the author of the registration has died, has moved 745 out of contact, or is otherwise unable to make changes that are 746 important to the community. 748 Channel bindings registrations may not be deleted; mechanisms that 749 are no longer believed appropriate for use can be declared OBSOLETE 750 by a change to their "intended usage" field; such channel bindings 751 will be clearly marked in the lists published by IANA. 753 The IESG is considered to be the owner of all channel bindings that 754 are on the IETF standards track. 756 8. Security Considerations 758 Security considerations appear throughout this document. In 759 particular see Section 2.1. 761 When delegating session protection from one layer to another, one 762 will almost certainly be making some session security trade-offs, 763 such as using weaker cipher modes in one layer than might be used in 764 the other. Evaluation and comparison of the relative cryptographic 765 strengths of these is difficult, may not be easily automated and is 766 far out of scope for this document. Implementors and administrators 767 should understand these trade-offs. Interfaces to secure channels 768 and application-layer authentication frameworks and mechanisms could 769 provide some notion of security profile so that applications may 770 avoid delegation of session protection to channels that are too weak 771 to match a required security profile. 773 Channel binding makes "anonymous" channels (where neither end-point 774 is strongly authenticated to the other) useful. Implementors should 775 avoid making use of such channels without channel binding easy to 776 configure accidentally. 778 The security of channel binding depends on the security of the 779 channels, the construction of their channel bindings, and the 780 security of the authentication mechanism used by the application and 781 its channel binding method. 783 Channel bindings should be constructed in such a way that revealing 784 the channel bindings of a channel to third parties does not weaken 785 the security of the channel. However, for end-point channel bindings 786 disclosure of the channel bindings may disclose the identities of the 787 peers. 789 8.1. Non-unique channel bindings and channel binding re-establishment 791 Applications developers may be tempted to use non-unique channel 792 bindings for fast re-authentication following channel re- 793 establishment. Care must be taken to avoid the possibility of 794 attacks on multi-user systems. 796 Consider a user multiplexing protocol like NFSv4 using channel 797 binding to IPsec on a multi-user client. If another user can connect 798 directly to port 2049 (NFS) on some server using IPsec and merely 799 assert RPCSEC_GSS credential handles, then this user will be able to 800 impersonate any user authenticated by the client to the server. This 801 is because the new connection will have the same channel bindings as 802 the NFS client's! To prevent this the server must require that at 803 least a host-based client principal, and perhaps all the client's 804 user principals, re-authenticate and perform channel binding before 805 the server will allow the clients to assert RPCSEC_GSS context 806 handles. Alternatively the protocol could: a) require that secure 807 channels provide confidentiality protection, and b) that fast re- 808 authentication cookies be difficult to guess (e.g., large numbers 809 selected randomly). 811 In other contexts there may not be such problems, for example, in the 812 case of application protocols that don't multiplex users over a 813 single channel and where confidentiality protection is always used in 814 the secure channel. 816 9. References 818 9.1. Normative References 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, March 1997. 823 9.2. Informative References 825 [I-D.altman-tls-channel-bindings] 826 Williams, N., "Channel Bindings for SSHv2", 827 draft-altman-tls-channel-bindings-00 (work in progress), 828 July 2006. 830 [I-D.ietf-btns-connection-latching] 831 Williams, N., "IPsec Channels: Connection Latching", 832 draft-ietf-btns-connection-latching-00 (work in progress), 833 February 2006. 835 [I-D.ietf-btns-core] 836 Richardson, M. and N. Williams, "Better-Than-Nothing- 837 Security: An Unauthenticated Mode of IPsec", 838 draft-ietf-btns-core-01 (work in progress), June 2006. 840 [I-D.ietf-btns-ipsec-apireq] 841 Richardson, M. and B. Sommerfeld, "Requirements for an 842 IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in 843 progress), April 2006. 845 [I-D.ietf-btns-prob-and-applic] 846 Touch, J., "Problem and Applicability Statement for Better 847 Than Nothing Security (BTNS)", 848 draft-ietf-btns-prob-and-applic-05 (work in progress), 849 February 2007. 851 [I-D.ietf-ips-iser] 852 Ko, M., "iSCSI Extensions for RDMA Specification", 853 draft-ietf-ips-iser-06 (work in progress), October 2005. 855 [I-D.ietf-kitten-stackable-pseudo-mechs] 856 Williams, N., "Stackable Generic Security Service Pseudo- 857 Mechanisms", draft-ietf-kitten-stackable-pseudo-mechs-02 858 (work in progress), June 2006. 860 [I-D.ietf-nfsv4-nfsdirect] 861 Callaghan, B. and T. Talpey, "NFS Direct Data Placement", 862 draft-ietf-nfsv4-nfsdirect-04 (work in progress), 863 October 2006. 865 [I-D.ietf-sasl-gs2] 866 Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 867 Mechanism Family", draft-ietf-sasl-gs2-06 (work in 868 progress), February 2007. 870 [I-D.williams-sshv2-channel-bindings] 871 Williams, N., "Channel Bindings for Secure Shell 872 Channels", draft-williams-sshv2-channel-bindings-00 (work 873 in progress), July 2006. 875 [Lampson91] 876 Lampson, B., Abadi, M., Burrows, M., and E. Wobber, 877 "Authentication in Distributed Systems: Theory and 878 Practive", October 1991. 880 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 881 RFC 1964, June 1996. 883 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 884 Internet Protocol", RFC 2401, November 1998. 886 [RFC2743] Linn, J., "Generic Security Service Application Program 887 Interface Version 2, Update 1", RFC 2743, January 2000. 889 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 890 C-bindings", RFC 2744, January 2000. 892 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 893 HTTP/1.1", RFC 2817, May 2000. 895 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 897 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 898 Beame, C., Eisler, M., and D. Noveck, "Network File System 899 (NFS) version 4 Protocol", RFC 3530, April 2003. 901 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 902 and E. Zeidner, "Internet Small Computer Systems Interface 903 (iSCSI)", RFC 3720, April 2004. 905 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 906 Levkowetz, "Extensible Authentication Protocol (EAP)", 907 RFC 3748, June 2004. 909 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 910 Protocol Architecture", RFC 4251, January 2006. 912 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 913 Internet Protocol", RFC 4301, December 2005. 915 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 916 December 2005. 918 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 919 RFC 4303, December 2005. 921 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 922 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 924 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 925 Security Layer (SASL)", RFC 4422, June 2006. 927 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 928 "Generic Security Service Application Program Interface 929 (GSS-API) Authentication and Key Exchange for the Secure 930 Shell (SSH) Protocol", RFC 4462, May 2006. 932 Appendix A. Acknowledgments 934 Thanks to Mike Eisler for his work on the Channel Conjunction 935 Mechanism I-D and for bringing the problem to a head, Sam Hartman for 936 pointing out that channel binding provide a general solution to the 937 channel binding problem, Jeff Altman for his suggestion of using the 938 TLS finished messages as the TLS channel bindings, Bill Sommerfeld, 939 Radia Perlman, Simon Josefsson, Joe Salowey, Eric Rescorla, Michael 940 Richardson, Bernard Aboba, Tom Petch, Mark Brown and many others. 942 Author's Address 944 Nicolas Williams 945 Sun Microsystems 946 5300 Riata Trace Ct 947 Austin, TX 78727 948 US 950 Email: Nicolas.Williams@sun.com 952 Full Copyright Statement 954 Copyright (C) The IETF Trust (2007). 956 This document is subject to the rights, licenses and restrictions 957 contained in BCP 78, and except as set forth therein, the authors 958 retain all their rights. 960 This document and the information contained herein are provided on an 961 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 962 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 963 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 964 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 965 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 966 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 968 Intellectual Property 970 The IETF takes no position regarding the validity or scope of any 971 Intellectual Property Rights or other rights that might be claimed to 972 pertain to the implementation or use of the technology described in 973 this document or the extent to which any license under such rights 974 might or might not be available; nor does it represent that it has 975 made any independent effort to identify any such rights. Information 976 on the procedures with respect to rights in RFC documents can be 977 found in BCP 78 and BCP 79. 979 Copies of IPR disclosures made to the IETF Secretariat and any 980 assurances of licenses to be made available, or the result of an 981 attempt made to obtain a general license or permission for the use of 982 such proprietary rights by implementers or users of this 983 specification can be obtained from the IETF on-line IPR repository at 984 http://www.ietf.org/ipr. 986 The IETF invites any interested party to bring to its attention any 987 copyrights, patents or patent applications, or other proprietary 988 rights that may cover technology that may be required to implement 989 this standard. Please address the information to the IETF at 990 ietf-ipr@ietf.org. 992 Acknowledgment 994 Funding for the RFC Editor function is provided by the IETF 995 Administrative Support Activity (IASA).