diff options
Diffstat (limited to 'doc/rfc/rfc5056.txt')
| -rw-r--r-- | doc/rfc/rfc5056.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc5056.txt b/doc/rfc/rfc5056.txt new file mode 100644 index 0000000..1b09d8c --- /dev/null +++ b/doc/rfc/rfc5056.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group N. Williams +Request for Comments: 5056 Sun +Category: Standards Track November 2007 + + + On the Use of Channel Bindings to Secure Channels + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The concept of channel binding allows applications to establish that + the two end-points of a secure channel at one network layer are the + same as at a higher layer by binding authentication at the higher + layer to the channel at the lower layer. This allows applications to + delegate session protection to lower layers, which has various + performance benefits. + + This document discusses and formalizes the concept of channel binding + to secure channels. + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Standards Track [Page 1] + +RFC 5056 On Channel Bindings November 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Definitions .....................................................4 + 2.1. Properties of Channel Binding ..............................6 + 2.2. EAP Channel Binding ........................................9 + 3. Authentication and Channel Binding Semantics ...................10 + 3.1. The GSS-API and Channel Binding ...........................10 + 3.2. SASL and Channel Binding ..................................11 + 4. Channel Bindings Specifications ................................11 + 4.1. Examples of Unique Channel Bindings .......................11 + 4.2. Examples of End-Point Channel Bindings ....................12 + 5. Uses of Channel Binding ........................................12 + 6. Benefits of Channel Binding to Secure Channels .................14 + 7. IANA Considerations ............................................15 + 7.1. Registration Procedure ....................................15 + 7.2. Comments on Channel Bindings Registrations ................16 + 7.3. Change Control ............................................17 + 8. Security Considerations ........................................17 + 8.1. Non-Unique Channel Bindings and Channel Binding + Re-Establishment ..........................................18 + 9. References .....................................................19 + 9.1. Normative References ......................................19 + 9.2. Informative References ....................................19 + Appendix A. Acknowledgments .......................................22 + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Standards Track [Page 2] + +RFC 5056 On Channel Bindings November 2007 + + +1. Introduction + + In a number of situations, it is useful for an application to be able + to handle authentication within the application layer, while + simultaneously being able to utilize session or transport security at + a lower network layer. For example, IPsec [RFC4301] [RFC4303] + [RFC4302] is amenable to being accelerated in hardware to handle very + high link speeds, but IPsec key exchange protocols and the IPsec + architecture are not as amenable to use as a security mechanism + within applications, particularly applications that have users as + clients. A method of combining security at both layers is therefore + attractive. To enable this to be done securely, it is necessary to + "bind" the mechanisms together -- so as to avoid man-in-the-middle + vulnerabilities and enable the mechanisms to be integrated in a + seamless way. This is the objective of "Channel Bindings". + + The term "channel binding", as used in this document, derives from + the Generic Security Service Application Program Interface (GSS-API) + [RFC2743], which has a channel binding facility that was intended for + binding GSS-API authentication to secure channels at lower network + layers. The purpose and benefits of the GSS-API channel binding + facility were not discussed at length, and some details were left + unspecified. Now we find that this concept can be very useful, + therefore we begin with a generalization and formalization of + "channel binding" independent of the GSS-API. + + Although inspired by and derived from the GSS-API, the notion of + channel binding described herein is not at all limited to use by GSS- + API applications. We envision use of channel binding by applications + that utilize other security frameworks, such as Simple Authentication + and Security Layer (SASL) [RFC4422] and even protocols that provide + their own authentication mechanisms (e.g., the Key Distribution + Center (KDC) exchanges of Kerberos V [RFC4120]). We also envision + use of the notion of channel binding in the analysis of security + protocols. + + The main goal of channel binding is to be able to delegate + cryptographic session protection to network layers below the + application in hopes of being able to better leverage hardware + implementations of cryptographic protocols. Section 5 describes some + intended uses of channel binding. Also, some applications may + benefit by reducing the amount of active cryptographic state, thus + reducing overhead in accessing such state and, therefore, the impact + of security on latency. + + + + + + + +Williams Standards Track [Page 3] + +RFC 5056 On Channel Bindings November 2007 + + + The critical security problem to solve in order to achieve such + delegation of session protection is ensuring that there is no man- + in-the-middle (MITM), from the point of view the application, at the + lower network layer to which session protection is to be delegated. + + There may well be an MITM, particularly if either the lower network + layer provides no authentication or there is no strong connection + between the authentication or principals used at the application and + those used at the lower network layer. + + Even if such MITM attacks seem particularly difficult to effect, the + attacks must be prevented for certain applications to be able to make + effective use of technologies such as IPsec [RFC2401] [RFC4301] or + HTTP with TLS [RFC4346] in certain contexts (e.g., when there is no + authentication to speak of, or when one node's set of trust anchors + is too weak to believe that it can authenticate its peers). + Additionally, secure channels that are susceptible to MITM attacks + because they provide no useful end-point authentication are useful + when combined with application-layer authentication (otherwise they + are only somewhat "better than nothing" -- see Better Than Nothing + Security (BTNS) [BTNS-AS]). + + For example, Internet Small Computer Systems Interface (iSCSI) + [RFC3720] provides for application-layer authentication (e.g., using + Kerberos V), but relies on IPsec for transport protection; iSCSI does + not provide a binding between the two. iSCSI initiators have to be + careful to make sure that the name of the server authenticated at the + application layer and the name of the peer at the IPsec layer match + -- an informal form of channel binding. + + This document describes a solution: the use of "channel binding" to + bind authentication at application layers to secure sessions at lower + layers in the network stack. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Definitions + + o Secure channel: a packet, datagram, octet stream connection, or + sequence of connections between two end-points that affords + cryptographic integrity and, optionally, confidentiality to data + exchanged over it. We assume that the channel is secure -- if an + attacker can successfully cryptanalyze a channel's session keys, + for example, then the channel is not secure. + + + +Williams Standards Track [Page 4] + +RFC 5056 On Channel Bindings November 2007 + + + o Channel binding: the process of establishing that no man-in-the- + middle exists between two end-points that have been authenticated + at one network layer but are using a secure channel at a lower + network layer. This term is used as a noun. + + o Channel bindings: [See historical note below.] + + Generally, some data that "names" a channel or one or both of + its end-points such that if this data can be shown, at a higher + network layer, to be the same at both ends of a channel, then + there are no MITMs between the two end-points at that higher + network layer. This term is used as a noun. + + More formally, there are two types of channel bindings: + + + unique channel bindings: + + channel bindings that name a channel in a cryptographically + secure manner and uniquely in time; + + + end-point channel bindings: + + channel bindings that name the authenticated end-points, or + even a single end-point, of a channel which are, in turn, + securely bound to the channel, but which do not identify a + channel uniquely in time. + + o Cryptographic binding: (e.g., "cryptographically bound") a + cryptographic operation that causes an object, such as a private + encryption or signing key, or an established secure channel, to + "speak for" [Lampson91] some principal, such as a user, a + computer, etcetera. For example, a Public Key Infrastructure for + X.509 Certificates (PKIX) certificate binds a private key to the + name of a principal in the trust domain of the certificate's + issuer such that a possessor of said private key can act on behalf + of the user (or other entity) named by the certificate. + + Cryptographic bindings are generally asymmetric in nature (not to + be confused with symmetric or asymmetric key cryptography) in that + an object is rendered capable of standing for another, but the + reverse is not usually the case (we don't say that a user speaks + for their private keys, but we do say that the user's private keys + speak for the user). + + Note that there may be many instances of "cryptographic binding" in + an application of channel binding. The credentials that authenticate + principals at the application layer bind private or secret keys to + the identities of those principals, such that said keys speak for + + + +Williams Standards Track [Page 5] + +RFC 5056 On Channel Bindings November 2007 + + + them. A secure channel typically consists of symmetric session keys + used to provide confidentiality and integrity protection to data sent + over the channel; each end-point's session keys speak for that end- + point of the channel. Finally, each end-point of a channel bound to + authentication at the application layer speaks for the principal + authenticated at the application layer on the same side of the + channel. + + The terms defined above have been in use for many years and have been + taken to mean, at least in some contexts, what is stated below. + Unfortunately this means that "channel binding" can refer to the + channel binding operation and, sometimes to the name of a channel, + and "channel bindings" -- a difference of only one letter -- + generally refers to the name of a channel. + + Note that the Extensible Authentication Protocol (EAP) [RFC3748] uses + "channel binding" to refer to a facility that may appear to be + similar to the one decribed here, but it is, in fact, quite + different. See Section 2.2 for mode details. + +2.1. Properties of Channel Binding + + Applications, authentication frameworks (e.g., the GSS-API, SASL), + security mechanisms (e.g., the Kerberos V GSS-API mechanism + [RFC1964]), and secure channels must meet the requirements and should + follow the recommendations that are listed below. + + Requirements: + + o In order to use channel binding, applications MUST verify that the + same channel bindings are observed at either side of the channel. + To do this, the application MUST use an authentication protocol at + the application layer to authenticate one, the other, or both + application peers (one at each end of the channel). + + * If the authentication protocol used by the application supports + channel binding, the application SHOULD use it. + + * An authentication protocol that supports channel binding MUST + provide an input slot in its API for a "handle" to the channel, + or its channel bindings. + + * If the authentication protocol does not support a channel + binding operation, but provides a "security layer" with at + least integrity protection, then the application MUST use the + authentication protocol's integrity protection facilities to + exchange channel bindings, or cryptographic hashes thereof. + + + + +Williams Standards Track [Page 6] + +RFC 5056 On Channel Bindings November 2007 + + + * The name of the type of channel binding MUST be used by the + application and/or authentication protocol to avoid ambiguity + about which of several possible types of channels is being + bound. If nested instances of the same type of channel are + available, then the innermost channel MUST be used. + + o Specifications of channel bindings for any secure channels MUST + provide for a single, canonical octet string encoding of the + channel bindings. Under this framework, channel bindings MUST + start with the channel binding unique prefix followed by a colon + (ASCII 0x3A). + + o The channel bindings for a given type of secure channel MUST be + constructed in such a way that an MITM could not easily force the + channel bindings of a given channel to match those of another. + + o Unique channel bindings MUST bind not only the key exchange for + the secure channel, but also any negotiations and authentication + that may have taken place to establish the channel. + + o End-point channel bindings MUST be bound into the secure channel + and all its negotiations. For example, a public key as an end- + point channel binding should be used to verify a signature of such + negotiations (or to encrypt them), including the initial key + exchange and negotiation messages for that channel -- such a key + would then be bound into the channel. A certificate name as end- + point channel binding could also be bound into the channel in a + similar way, though in the case of a certificate name, the binding + also depends on the strength of the authentication of that name + (that is, the validation of the certificate, the trust anchors, + the algorithms used in the certificate path construction and + validation, etcetera). + + o End-point channel bindings MAY be identifiers (e.g., certificate + names) that must be authenticated through some infrastructure, + such as a public key infrastructure (PKI). In such cases, + applications MUST ensure that the channel provides adequate + authentication of such identifiers (e.g., that the certificate + validation policy and trust anchors used by the channel satisfy + the application's requirements). To avoid implementation + difficulties in addressing this requirement, applications SHOULD + use cryptographic quantities as end-point channel bindings, such + as certificate-subject public keys. + + o Applications that desire confidentiality protection MUST use + application-layer session protection services for confidentiality + protection when the bound channel does not provide confidentiality + protection. + + + +Williams Standards Track [Page 7] + +RFC 5056 On Channel Bindings November 2007 + + + o The integrity of a secure channel MUST NOT be weakened should + their channel bindings be revealed to an attacker. That is, the + construction of the channel bindings for any type of secure + channel MUST NOT leak secret information about the channel. End- + point channel bindings, however, MAY leak information about the + end-points of the channel (e.g., their names). + + o The channel binding operation MUST be at least integrity protected + in the security mechanism used at the application layer. + + o Authentication frameworks and mechanisms that support channel + binding MUST communicate channel binding failure to applications. + + o Applications MUST NOT send sensitive information, requiring + confidentiality protection, over the underlying channel prior to + completing the channel binding operation. + + Recommendations: + + o End-point channel bindings where the end-points are meaningful + names SHOULD NOT be used when the channel does not provide + confidentiality protection and privacy protection is desired. + Alternatively, channels that export such channel bindings SHOULD + provide for the use of a digest and SHOULD NOT introduce new + digest/hash agility problems as a result. + + Options: + + o Authentication frameworks and mechanisms that support channel + binding MAY fail to establish authentication if channel binding + fails. + + o Applications MAY send information over the underlying channel and + without integrity protection from the application-layer + authentication protocol prior to completing the channel binding + operation if such information requires only integrity protection. + This could be useful for optimistic negotiations. + + o A security mechanism MAY exchange integrity-protected channel + bindings. + + o A security mechanism MAY exchange integrity-protected digests of + channel bindings. Such mechanisms SHOULD provide for hash/digest + agility. + + o A security mechanism MAY use channel bindings in key exchange, + authentication, or key derivation, prior to the exchange of + "authenticator" messages. + + + +Williams Standards Track [Page 8] + +RFC 5056 On Channel Bindings November 2007 + + +2.2. EAP Channel Binding + + This section is informative. This document does not update EAP + [RFC3748], it neither normatively describes, nor does it impose + requirements on any aspect of EAP or EAP methods. + + EAP [RFC3748] includes a concept of channel binding described as + follows: + + The communication within an EAP method of integrity-protected + channel properties such as endpoint identifiers which can be + compared to values communicated via out of band mechanisms (such + as via a AAA or lower layer protocol). + + Section 7.15 of [RFC3748] describes the problem as one where a + Network Access Server (NAS) (a.k.a. "authenticator") may lie to the + peer (client) and cause the peer to make incorrect authorization + decisions (e.g., as to what traffic may transit through the NAS). + This is not quite like the purpose of generic channel binding (MITM + detection). + + Section 7.15 of [RFC3748] calls for "a protected exchange of channel + properties such as endpoint identifiers" such that "it is possible to + match the channel properties provided by the authenticator via out- + of-band mechanisms against those exchanged within the EAP method". + + This has sometimes been taken to be very similar to the generic + notion of channel binding provided here. However, there is a very + subtle difference between the two concepts of channel binding that + makes it much too difficult to put forth requirements and + recommendations that apply to both. The difference is about the + lower-layer channel: + + o In the generic channel binding case, the identities of either end + of this channel are irrelevant to anything other than the + construction of a name for that channel, in which case the + identities of the channel's end-points must be established a + priori. + + o Whereas in the EAP case, the identity of the NAS end of the + channel, and even security properties of the channel itself, may + be established during or after authentication of the EAP peer to + the EAP server. + + In other words: there is a fundamental difference in mechanics + (timing of lower-layer channel establishment) and in purpose + (authentication of lower-layer channel properties for authorization + purposes vs. MITM detection). + + + +Williams Standards Track [Page 9] + +RFC 5056 On Channel Bindings November 2007 + + + After some discussion we have concluded that there is no simple way + to obtain requirements and recommendations that apply to both generic + and EAP channel binding. Therefore, EAP is out of the scope of this + document. + +3. Authentication and Channel Binding Semantics + + Some authentication frameworks and/or mechanisms provide for channel + binding, such as the GSS-API and some GSS-API mechanisms, whereas + others may not, such as SASL (however, ongoing work is adding channel + binding support to SASL). Semantics may vary with respect to + negotiation, how the binding occurs, and handling of channel binding + failure (see below). + + Where suitable channel binding facilities are not provided, + application protocols MAY include a separate, protected exchange of + channel bindings. In order to do this, the application-layer + authentication service must provide message protection services (at + least integrity protection). + +3.1. The GSS-API and Channel Binding + + The GSS-API [RFC2743] provides for the use of channel binding during + initialization of GSS-API security contexts, though GSS-API + mechanisms are not required to support this facility. + + This channel binding facility is described in [RFC2743] and + [RFC2744]. + + GSS-API mechanisms must fail security context establishment when + channel binding fails, and the GSS-API provides no mechanism for the + negotiation of channel binding. As a result GSS-API applications + must agree a priori, through negotiation or otherwise, on the use of + channel binding. + + Fortunately, it is possible to design GSS-API pseudo-mechanisms that + simply wrap around existing mechanisms for the purpose of allowing + applications to negotiate the use of channel binding within their + existing methods for negotiating GSS-API mechanisms. For example, + NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as + does the SSHv2 protocol [RFC4462]. Such pseudo-mechanisms are being + proposed separately, see [STACKABLE]. + + + + + + + + + +Williams Standards Track [Page 10] + +RFC 5056 On Channel Bindings November 2007 + + +3.2. SASL and Channel Binding + + SASL [RFC4422] does not yet provide for the use of channel binding + during initialization of SASL contexts. + + Work is ongoing [SASL-GS2] to specify how SASL, particularly its new + bridge to the GSS-API, performs channel binding. SASL will likely + differ from the GSS-API in its handling of channel binding failure + (i.e., when there may be an MITM) in that channel binding + success/failure will only affect the negotiation of SASL security + layers. That is, when channel binding succeeds, SASL should select + no security layers, leaving session cryptographic protection to the + secure channel that SASL authentication has been bound to. + +4. Channel Bindings Specifications + + Channel bindings for various types of secure channels are not + described herein. Some channel bindings specifications can be found + in: + + +--------------------+----------------------------------------------+ + | Secure Channel | Reference | + | Type | | + +--------------------+----------------------------------------------+ + | SSHv2 | [SSH-CB] | + | | | + | TLS | [TLS-CB] | + | | | + | IPsec | There is no specification for IPsec channel | + | | bindings yet, but the IETF Better Than | + | | Nothing Security (BTNS) WG is working to | + | | specify IPsec channels, and possibly IPsec | + | | channel bindings. | + +--------------------+----------------------------------------------+ + +4.1. Examples of Unique Channel Bindings + + The following text is not normative, but is here to show how one + might construct channel bindings for various types of secure + channels. + + For SSHv2 [RFC4251] the SSHv2 session ID should suffice as it is a + cryptographic binding of all relevant SSHv2 connection parameters: + key exchange and negotiation. + + The TLS [RFC4346] session ID is simply assigned by the server. As + such, the TLS session ID does not have the required properties to be + useful as a channel binding because any MITM, posing as the server, + + + +Williams Standards Track [Page 11] + +RFC 5056 On Channel Bindings November 2007 + + + can simply assign the same session ID to the victim client as the + server assigned to the MITM. Instead, the initial, unencrypted TLS + finished messages (the client's, the server's, or both) are + sufficient as they are the output of the TLS pseudo-random function, + keyed with the session key, applied to all handshake material. + +4.2. Examples of End-Point Channel Bindings + + The following text is not normative, but is here to show how one + might construct channel bindings for various types of secure + channels. + + For SSHv2 [RFC4251] the SSHv2 host public key, when present, should + suffice as it is used to sign the algorithm suite negotiation and + Diffie-Hellman key exchange; as long the client observes the host + public key that corresponds to the private host key that the server + used, then there cannot be an MITM in the SSHv2 connection. Note + that not all SSHv2 key exchanges use host public keys; therefore, + this channel bindings construction is not as useful as the one given + in Section 4.1. + + For TLS [RFC4346]the server certificate should suffice for the same + reasons as above. Again, not all TLS cipher suites involve server + certificates; therefore, the utility of this construction of channel + bindings is limited to scenarios where server certificates are + commonly used. + +5. Uses of Channel Binding + + Uses for channel binding identified so far: + + o Delegating session cryptographic protection to layers where + hardware can reasonably be expected to support relevant + cryptographic protocols: + + * NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP) + [NFS-DDP] for zero-copy reception where network interface + controllers (NICs) support RDDP. Cryptographic session + protection would be delegated to Encapsulating Security Payload + (ESP) [RFC4303] / Authentication Headers (AHs) [RFC4302]. + + * iSCSI [RFC3720] with Remote Direct Memory Access (RDMA) + [RFC5046]. Cryptographic session protection would be delegated + to ESP/AH. + + * HTTP with TLS [RFC2817] [RFC2818]. In situations involving + proxies, users may want to bind authentication to a TLS channel + between the last client-side proxy and the first server-side + + + +Williams Standards Track [Page 12] + +RFC 5056 On Channel Bindings November 2007 + + + proxy ("concentrator"). There is ongoing work to expand the + set of choices for end-to-end authentication at the HTTP layer, + that, coupled with channel binding to TLS, would allow for + proxies while not forgoing protection over public internets. + + o Reducing the number of live cryptographic contexts that an + application must maintain: + + * NFSv4 [RFC3530] multiplexes multiple users onto individual + connections. Each user is authenticated separately, and users' + remote procedure calls (RPCs) are protected with per-user GSS- + API security contexts. This means that large timesharing + clients must often maintain many cryptographic contexts per- + NFSv4 connection. With channel binding to IPsec, they could + maintain a much smaller number of cryptographic contexts per- + NFSv4 connection, thus reducing memory pressure and + interactions with cryptographic hardware. + + For example, applications that wish to use RDDP to achieve zero-copy + semantics on reception may use a network layer understood by NICs to + offload delivery of application data into pre-arranged memory + buffers. Note that in order to obtain zero-copy reception semantics + either application data has to be in cleartext relative to this RDDP + layer, or the RDDP implementation must know how to implement + cryptographic session protection protocols used at the application + layer. + + There are a multitude of application-layer cryptographic session + protection protocols available. It is not reasonable to expect that + NICs should support many such protocols. Further, some application + protocols may maintain many cryptographic session contexts per- + connection (for example, NFSv4 does). It is thought to be simpler to + push the cryptographic session protection down the network stack (to + IPsec), and yet be able to produce NICs that offload other operations + (i.e., TCP/IP, ESP/AH, and DDP), than it would be to add support in + the NIC for the many session cryptographic protection protocols in + use in common applications at the application layer. + + + + + + + + + + + + + + +Williams Standards Track [Page 13] + +RFC 5056 On Channel Bindings November 2007 + + + The following figure shows how the various network layers are + related: + + +---------------------+ + | Application layer |<---+ + | |<-+ | In cleartext, relative + +---------------------+ | | to each other. + | RDDP |<---+ + +---------------------+ | + | TCP/SCTP |<-+ + +---------------------+ | Channel binding of app-layer + | ESP/AH |<-+ authentication to IPsec + +---------------------+ + | IP | + +---------------------+ + | ... | + +---------------------+ + +6. Benefits of Channel Binding to Secure Channels + + The use of channel binding to delegate session cryptographic + protection include: + + o Performance improvements by avoiding double protection of + application data in cases where IPsec is in use and applications + provide their own secure channels. + + o Performance improvements by leveraging hardware-accelerated IPsec. + + o Performance improvements by allowing RDDP hardware offloading to + be integrated with IPsec hardware acceleration. + + Where protocols layered above RDDP use privacy protection, RDDP + offload cannot be done. Thus, by using channel binding to + IPsec, the privacy protection is moved to IPsec, which is + layered below RDDP. So, RDDP can address application protocol + data that's in cleartext relative to the RDDP headers. + + o Latency improvements for applications that multiplex multiple + users onto a single channel, such as NFS with RPCSEC_GSS + [RFC2203]. + + Delegation of session cryptographic protection to IPsec requires + features not yet specified. There is ongoing work to specify: + + o IPsec channels [CONN-LATCH]; + + + + + +Williams Standards Track [Page 14] + +RFC 5056 On Channel Bindings November 2007 + + + o Application programming interfaces (APIs) related to IPsec + channels [BTNS-IPSEC]; + + o Channel bindings for IPsec channels; + + o Low infrastructure IPsec authentication [BTNS-CORE]. + +7. IANA Considerations + + IANA has created a new registry for channel bindings specifications + for various types of channels. + + The purpose of this registry is not only to ensure uniqueness of + values used to name channel bindings, but also to provide a + definitive reference to technical specifications detailing each + channel binding available for use on the Internet. + + There is no naming convention for channel bindings: any string + composed of US-ASCII alphanumeric characters, period ('.'), and dash + ('-') will suffice. + + The procedure detailed in Section 7.1 is to be used for registration + of a value naming a specific individual mechanism. + +7.1. Registration Procedure + + Registration of a new channel binding requires expert review as + defined in BCP 26 [RFC2434]. + + Registration of a channel binding is requested by filling in the + following template: + + o Subject: Registration of channel binding X + + o Channel binding unique prefix (name): + + o Channel binding type: (One of "unique" or "end-point") + + o Channel type: (e.g., TLS, IPsec, SSH, etc.) + + o Published specification (recommended, optional): + + o Channel binding is secret (requires confidentiality protection): + yes/no + + o Description (optional if a specification is given; required if no + published specification is specified): + + + + +Williams Standards Track [Page 15] + +RFC 5056 On Channel Bindings November 2007 + + + o Intended usage: (one of COMMON, LIMITED USE, or OBSOLETE) + + o Person and email address to contact for further information: + + o Owner/Change controller name and email address: + + o Expert reviewer name and contact information: (leave blank) + + o Note: (Any other information that the author deems relevant may be + added here.) + + and sending it via electronic mail to <channel-binding@ietf.org> (a + public mailing list) and carbon copying IANA at <iana@iana.org>. + After allowing two weeks for community input on the mailing list to + be determined, an expert will determine the appropriateness of the + registration request and either approve or disapprove the request + with notice to the requestor, the mailing list, and IANA. + + If the expert approves registration, it adds her/his name to the + submitted registration. + + The expert has the primary responsibility of making sure that channel + bindings for IETF specifications go through the IETF consensus + process and that prefixes are unique. + + The review should focus on the appropriateness of the requested + channel binding for the proposed use, the appropriateness of the + proposed prefix, and correctness of the channel binding type in the + registration. The scope of this request review may entail + consideration of relevant aspects of any provided technical + specification, such as their IANA Considerations section. However, + this review is narrowly focused on the appropriateness of the + requested registration and not on the overall soundness of any + provided technical specification. + + Authors are encouraged to pursue community review by posting the + technical specification as an Internet-Draft and soliciting comment + by posting to appropriate IETF mailing lists. + +7.2. Comments on Channel Bindings Registrations + + Comments on registered channel bindings should first be sent to the + "owner" of the channel bindings and to the channel binding mailing + list. + + Submitters of comments may, after a reasonable attempt to contact the + owner, request IANA to attach their comment to the channel binding + type registration itself by sending mail to <iana@iana.org>. At + + + +Williams Standards Track [Page 16] + +RFC 5056 On Channel Bindings November 2007 + + + IANA's sole discretion, IANA may attach the comment to the channel + bindings registration. + +7.3. Change Control + + Once a channel bindings registration has been published by IANA, the + author may request a change to its definition. The change request + follows the same procedure as the registration request. + + The owner of a channel bindings may pass responsibility for the + channel bindings to another person or agency by informing IANA; this + can be done without discussion or review. + + The IESG may reassign responsibility for a channel bindings + registration. The most common case of this will be to enable changes + to be made to mechanisms where the author of the registration has + died, has moved out of contact, or is otherwise unable to make + changes that are important to the community. + + Channel bindings registrations may not be deleted; mechanisms that + are no longer believed appropriate for use can be declared OBSOLETE + by a change to their "intended usage" field. Such channel bindings + will be clearly marked in the lists published by IANA. + + The IESG is considered to be the owner of all channel bindings that + are on the IETF standards track. + +8. Security Considerations + + Security considerations appear throughout this document. In + particular see Section 2.1. + + When delegating session protection from one layer to another, one + will almost certainly be making some session security trade-offs, + such as using weaker cipher modes in one layer than might be used in + the other. Evaluation and comparison of the relative cryptographic + strengths of these is difficult, may not be easily automated, and is + far out of scope for this document. Implementors and administrators + should understand these trade-offs. Interfaces to secure channels + and application-layer authentication frameworks and mechanisms could + provide some notion of security profile so that applications may + avoid delegation of session protection to channels that are too weak + to match a required security profile. + + Channel binding makes "anonymous" channels (where neither end-point + is strongly authenticated to the other) useful. Implementors should + avoid making it easy to use such channels without channel binding. + + + + +Williams Standards Track [Page 17] + +RFC 5056 On Channel Bindings November 2007 + + + The security of channel binding depends on the security of the + channels, the construction of their channel bindings, and the + security of the authentication mechanism used by the application and + its channel binding method. + + Channel bindings should be constructed in such a way that revealing + the channel bindings of a channel to third parties does not weaken + the security of the channel. However, for end-point channel bindings + disclosure of the channel bindings may disclose the identities of the + peers. + +8.1. Non-Unique Channel Bindings and Channel Binding Re-Establishment + + Application developers may be tempted to use non-unique channel + bindings for fast re-authentication following channel re- + establishment. Care must be taken to avoid the possibility of + attacks on multi-user systems. + + Consider a user multiplexing protocol like NFSv4 using channel + binding to IPsec on a multi-user client. If another user can connect + directly to port 2049 (NFS) on some server using IPsec and merely + assert RPCSEC_GSS credential handles, then this user will be able to + impersonate any user authenticated by the client to the server. This + is because the new connection will have the same channel bindings as + the NFS client's! To prevent this, the server must require that at + least a host-based client principal, and perhaps all the client's + user principals, re-authenticate and perform channel binding before + the server will allow the clients to assert RPCSEC_GSS context + handles. Alternatively, the protocol could require a) that secure + channels provide confidentiality protection and b) that fast re- + authentication cookies be difficult to guess (e.g., large numbers + selected randomly). + + In other contexts there may not be such problems, for example, in the + case of application protocols that don't multiplex users over a + single channel and where confidentiality protection is always used in + the secure channel. + + + + + + + + + + + + + + +Williams Standards Track [Page 18] + +RFC 5056 On Channel Bindings November 2007 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [BTNS-AS] Touch, J., Black, D., and Y. Wang, "Problem and + Applicability Statement for Better Than Nothing Security + (BTNS)", Work in Progress, October 2007. + + [BTNS-CORE] Richardson, M. and N. Williams, "Better-Than-Nothing- + Security: An Unauthenticated Mode of IPsec", Work in + Progress, September 2007. + + [BTNS-IPSEC] Richardson, M. and B. Sommerfeld, "Requirements for an + IPsec API", Work in Progress, April 2006. + + [CONN-LATCH] Williams, N., "IPsec Channels: Connection Latching", + Work in Progress, September 2007. + + [Lampson91] Lampson, B., Abadi, M., Burrows, M., and E. Wobber, + "Authentication in Distributed Systems: Theory and + Practive", October 1991. + + [NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data + Placement", Work in Progress, July 2007. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. + + [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol + Specification", RFC 2203, September 1997. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [RFC2744] Wray, J., "Generic Security Service API Version 2 : + C-bindings", RFC 2744, January 2000. + + + +Williams Standards Track [Page 19] + +RFC 5056 On Channel Bindings November 2007 + + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, May 2000. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., + Beame, C., Eisler, M., and D. Noveck, "Network File + System (NFS) version 4 Protocol", RFC 3530, April 2003. + + [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., + and E. Zeidner, "Internet Small Computer Systems + Interface (iSCSI)", RFC 3720, April 2004. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and + H. Levkowetz, "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, January 2006. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.1", RFC 4346, April + 2006. + + [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and + Security Layer (SASL)", RFC 4422, June 2006. + + [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, + "Generic Security Service Application Program Interface + (GSS-API) Authentication and Key Exchange for the Secure + Shell (SSH) Protocol", RFC 4462, May 2006. + + + + + + + +Williams Standards Track [Page 20] + +RFC 5056 On Channel Bindings November 2007 + + + [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, + H., and P. Thaler, "Internet Small Computer System + Interface (iSCSI) Extensions for Remote Direct Memory + Access (RDMA)", RFC 5046, October 2007. + + [SASL-GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The + GS2 Mechanism Family", Work in Progress, October 2007. + + [SSH-CB] Williams, N., "Channel Binding Identifiers for Secure + Shell Channels", Work in Progress, November 2007. + + [STACKABLE] Williams, N., "Stackable Generic Security Service + Pseudo-Mechanisms", Work in Progress, June 2006. + + [TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for + TLS", Work in Progress, November 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Standards Track [Page 21] + +RFC 5056 On Channel Bindings November 2007 + + +Appendix A. Acknowledgments + + Thanks to Mike Eisler for his work on the Channel Conjunction + Mechanism document and for bringing the problem to a head, Sam + Hartman for pointing out that channel binding provides a general + solution to the channel binding problem, and Jeff Altman for his + suggestion of using the TLS finished messages as the TLS channel + bindings. Also, thanks to Bill Sommerfeld, Radia Perlman, Simon + Josefsson, Joe Salowey, Eric Rescorla, Michael Richardson, Bernard + Aboba, Tom Petch, Mark Brown, and many others. + +Author's Address + + Nicolas Williams + Sun Microsystems + 5300 Riata Trace Ct. + Austin, TX 78727 + US + + EMail: Nicolas.Williams@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Standards Track [Page 22] + +RFC 5056 On Channel Bindings November 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Williams Standards Track [Page 23] + |