NOTE: This individual submission Internet-Draft replaces the NFSv4 WG
draft-ietf-nfsv4-channel-bindings work item.
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: December 3, 2006 June 2006
On the Use of Channel Bindings to Secure Channels
draft-williams-on-channel-binding-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 Expires December 3, 2006 [Page 1]
Internet-Draft On Channel Bindings June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2.1. Properties of channel binding . . . . . . . . . . . . 5
3. Authentication and channel binding semantics . . . . . 7
3.1. The GSS-API and channel binding . . . . . . . . . . . 7
3.2. SASL and channel binding . . . . . . . . . . . . . . . 7
4. Channel bindings specifications . . . . . . . . . . . 9
4.1. Examples of unique channel bindings . . . . . . . . . 9
4.2. Examples of end-point channel bindings . . . . . . . . 9
5. Uses of channel binding . . . . . . . . . . . . . . . 11
6. Benefits of channel binding to secure channels . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . 15
8.1. Non-unique channel bindings and channel binding
re-establishment . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . 22
Williams Expires December 3, 2006 [Page 2]
Internet-Draft On Channel Bindings June 2006
1. Introduction
The GSS-API [RFC2743] has a concept of "channel binding" that allows
for applications to ensure that the end-points of an underlying
secure channel are seen to be the same by the peers at the GSS-API
level. Thus authentication at an application layer could be "bound"
to a secure channel that the application was using. The purpose and
benefits of doing this were not discussed at length, and details were
left unspecified. Now we find that this concept can be very useful,
primarily in leveraging hardware implementations of common
cryptographic protocols, such as IPsec [RFC4301] [RFC4303] [RFC4302]
and TLS [RFC4346].
The goal 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.
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.
And there may well be a MITM, particularly if the lower network layer
either provides no authentication or if 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).
This document describes a solution: the use of "channel binding" (in
the GSS-API [RFC2743] [RFC2744] sense) 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].
Williams Expires December 3, 2006 [Page 3]
Internet-Draft On Channel Bindings June 2006
2. Definitions
The terms defined below 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.
Also unfortunately there is a conflict with the Extensible
Authentication Protocol (EAP) [RFC3748] which uses "channel binding"
to refer to a facility that is subtly different from the one
described here.
It does not seem feasible to adopt new terminology to avoid these
problems now. The GSS-API, NFSv4 and other communities have been
using the terms "channel binding" and "channel bindings" in these
ways for a long time, sometimes with variations such as "channel
binding facility" and so on.
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.
o Channel binding: the process of establishing that no man-in-the-
middle exists between two end-points authenticated at one network
layer but using a secure channel at a lower network layer. This
term is used as a noun.
o Channel bindings: [See historical note above.]
Generally some data which "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:
Williams Expires December 3, 2006 [Page 4]
Internet-Draft On Channel Bindings June 2006
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.
2.1. Properties of channel binding
[NOTE: This section needs more work, I'm sure I've missed
somethings...]
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 following requirement
and should follow the following recommendations.
Requirements:
o Specifications of channel bindings for any secure channels MUST
provide for a single, canonical octet string encoding of the
channel bindings.
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. E.g., if an end-point channel binding
is the name of a certificate and this certificate is used in
establishng the channel to sign material, say, all the initinial
key exchange and negotiation messages for that channel, then that
certificate name could be said to be bound into the channel.
o End-point channel bindings may be identifiers which must be
authenticated through some infrastructure, such as a public key
infrastructure (PKI). In such cases the channel binding can be no
stronger, cryptographically, than the infrastructure, including
trust establishment. Applications MUST NOT use end-point channel
bindings when the end-points cannot be strongly authenticated due
to the configuration of the authentication service (e.g., because
Williams Expires December 3, 2006 [Page 5]
Internet-Draft On Channel Bindings June 2006
there are too many trust anchors, or because some are of dubious
repute).
o Applications MUST use application-layer session protection
services for confidentiality protection when the bound channel
does not provide confidentiality protection.
o The integrity of a secure channels 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.
Recommendations:
o Applications SHOULD use mutual authentication at the application
layer when using channel binding.
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 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 Expires December 3, 2006 [Page 6]
Internet-Draft On Channel Bindings June 2006
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 [I-D.ietf-kitten-stackable-pseudo-mechs].
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 [I-D.ietf-sasl-gs2] to specify how SASL, particularly
it's 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 a MITM) in that channel binding
success/failure will only affect the negotiation of SASL security
Williams Expires December 3, 2006 [Page 7]
Internet-Draft On Channel Bindings June 2006
layers. I.e., when channel binding succeeds SASL should select no
security layers, leaving session cryptographic protection to the
secure channel that has been bound to.
Williams Expires December 3, 2006 [Page 8]
Internet-Draft On Channel Bindings June 2006
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 | [I-D.williams-sshv2-channel-bindings] |
| | |
| TLS | [I-D.altman-tls-channel-bindings] |
| | |
| IPsec | There is no specification for this yet. We |
| | expect that channel bindings for IPsec will |
| | be of the non-unique variety. |
+--------------------+----------------------------------------------+
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.
For TLS [RFC4346]the TLS session ID is not sufficient as it is
assigned by the server, and so could be assigned by an MITM to match
a server's. Instead the initial, unencrypted TLS finished messages,
either the client's, the server's or both, are sufficient as they are
the output of the TLS PRF, 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 a MITM in the SSHv2 connection. Note that
not all SSHv2 key exchanges use host public keys, therefore this
Williams Expires December 3, 2006 [Page 9]
Internet-Draft On Channel Bindings June 2006
channel bindings construction is not as useful as the one given in
Section 4.1 above.
For TLS [RFC4346]the server certificate should suffice for the same
reasons as above. Again, not all TLS cipher suites involve server
certificates, therfore the utility of this construction of channel
bindings is limited to scenarios where server certificates are
commonly used.
Williams Expires December 3, 2006 [Page 10]
Internet-Draft On Channel Bindings June 2006
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)
[I-D.ietf-nfsv4-nfsdirect] for zer-copy reception where network
interface controllers (NICs) support RDDP. Cryptographic
session protection would be delegated to ESP/AH [RFC4303]
[RFC4302].
* iSCSI [RFC3720] with Remote Direct Memory Access (RDMA)
[I-D.ietf-ips-iser]. 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
proxy ("concentrator"). There is ongoing work to expand the
set of choices for end-to-end authentication at the HTTP layer,
which 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 user's
RPCs are protected with per-user GSS-API security contexts.
This means that large timesharing clients must often maintain
many cryptographic contexts per-NFSv4 conenction. 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 network
interface controllers (NIC) 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
Williams Expires December 3, 2006 [Page 11]
Internet-Draft On Channel Bindings June 2006
protection protocols available. It is not reasonable to expect the
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 TCP/IP, ESP/AH,
and DDP operations, 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.
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 |
+---------------------+
| ... |
+---------------------+
Williams Expires December 3, 2006 [Page 12]
Internet-Draft On Channel Bindings June 2006
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 w/ RPCSEC_GSS.
Delegation of session cryptographic protection to IPsec requires
features not yet specified. There is ongoing work to specify:
o IPsec channels [I-D.ietf-btns-connection-latching];
o Application programming interfaces (APIs) related to IPsec
channels [I-D.ietf-btns-ipsec-apireq];
o Channel bindings for IPsec channels;
o Low infrastructure IPsec authentication[I-D.ietf-btns-core].
Williams Expires December 3, 2006 [Page 13]
Internet-Draft On Channel Bindings June 2006
7. IANA Considerations
There are no IANA considerations in this document.
Williams Expires December 3, 2006 [Page 14]
Internet-Draft On Channel Bindings June 2006
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 use of such channels without channel binding easy to
configure accidentally.
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
Applications 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 hostbased client principal, and perhaps all the client's user
Williams Expires December 3, 2006 [Page 15]
Internet-Draft On Channel Bindings June 2006
principals, re-authenticate and perform channel binding before the
server will allow the clients to assert RPCSEC_GSS context handles.
Alternatively the protocol could: a) require 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 Expires December 3, 2006 [Page 16]
Internet-Draft On Channel Bindings June 2006
9. References
9.1. Normative
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative
[I-D.altman-tls-channel-bindings]
Williams, N., "Channel Bindings for SSHv2",
draft-altman-tls-channel-bindings-00 (work in progress),
July 2006.
[I-D.ietf-btns-connection-latching]
Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-00 (work in progress),
February 2006.
[I-D.ietf-btns-core]
Williams, N., "Better-Than-Nothing-Security: An
Unauthenticated Mode of IPsec", draft-ietf-btns-core-00
(work in progress), February 2006.
[I-D.ietf-btns-ipsec-apireq]
Richardson, M. and B. Sommerfeld, "Requirements for an
IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in
progress), April 2006.
[I-D.ietf-ips-iser]
Ko, M., "iSCSI Extensions for RDMA Specification",
draft-ietf-ips-iser-05 (work in progress), October 2005.
[I-D.ietf-kitten-stackable-pseudo-mechs]
Williams, N., "Stackable Generic Security Service Pseudo-
Mechanisms", draft-ietf-kitten-stackable-pseudo-mechs-01
(work in progress), October 2005.
[I-D.ietf-nfsv4-nfsdirect]
Callaghan, B. and T. Talpey, "NFS Direct Data Placement",
draft-ietf-nfsv4-nfsdirect-02 (work in progress),
October 2005.
[I-D.ietf-sasl-gs2]
Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
Mechanism Family", draft-ietf-sasl-gs2-00 (work in
progress), February 2006.
Williams Expires December 3, 2006 [Page 17]
Internet-Draft On Channel Bindings June 2006
[I-D.williams-sshv2-channel-bindings]
Williams, N., "Channel Bindings for Secure Shell
Channels", draft-williams-sshv2-channel-bindings-00 (work
in progress), July 2006.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 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.
[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.
[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.
Williams Expires December 3, 2006 [Page 18]
Internet-Draft On Channel Bindings June 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 Expires December 3, 2006 [Page 19]
Internet-Draft On Channel Bindings June 2006
Appendix A. Acknowledgments
Thanks to Mike Eisler for his work on the Channel Conjunction
Mechanism I-D and for bringing the problem to a head, Sam Hartman for
pointing out that channel binding provide a general solution to the
channel binding problem, Jeff Altman for his suggestion of using the
TLS finished messages as the TLS channel bindings, Bill Sommerfeld,
Radia Perlman, Simon Josefsson, Joe Salowey, Eric Rescorla, Michael
Richardson, and many others.
Williams Expires December 3, 2006 [Page 20]
Internet-Draft On Channel Bindings June 2006
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires December 3, 2006 [Page 21]
Internet-Draft On Channel Bindings June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires December 3, 2006 [Page 22]
