draft-ietf-nfsv4-channel-bindings-00.txt   draft-ietf-nfsv4-channel-bindings-01.txt 
Network Working Group Nicolas Williams Network Working Group Nicolas Williams
INTERNET-DRAFT Sun Microsystems INTERNET-DRAFT Sun Microsystems
October 2003 November 2004
On the Use of Channel Bindings to Secure Channels On the Use of Channel Bindings to Secure Channels
<draft-ietf-nfsv4-channel-bindings-00.txt> <draft-ietf-nfsv4-channel-bindings-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 31 skipping to change at line 31
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This draft expires on March 1st, 2004. Please send comments to the
author.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines and formalizes the concept of channel bindings This document defines and formalizes the concept of channel bindings
to secure layers and defines the actual contents of channel bindings to secure layers and defines the actual contents of channel bindings
for several secure channels. for several secure channels.
The concept of channel bindings allows applications to prove that the The concept of channel bindings allows applications to prove that the
end-points of two secure channels are the same by binding end-points of two secure channels are the same by binding
authentication at one network layer to the session protection authentication at one network layer to the session protection
negotiation at a lower network layer. The use of channel bindings negotiation at a lower network layer. The use of channel bindings
allows applications to delegate session protection to lower layers. allows applications to delegate session protection to lower layers.
N. Williams [Page 1] N. Williams [Page 1]
Table of Contents DRAFT Channel Bindings to Secure Channels Expires November 2004
1. Introduction 1. Introduction pg. 3
2. Definitions 2. Definitions pg. 4
3. Authentication protocols and channel bindings 3. Authentication protocols and channel bindings pg. 6
3.1. The GSS-API and channel bindings 3.1. The GSS-API and channel bindings pg. 6
3.2. SASL and channel bindings 3.2. SASL and channel bindings pg. 7
3.3. Kerberos V and channel bindings 3.3. Kerberos V and channel bindings pg. 7
4. Channel bindings to secure layers 4. Channel bindings to secure layers pg. 7
4.1. Bindings to SSHv2 channels 4.1. Bindings to SSHv2 channels pg. 7
4.2. Bindings to TLS channels 4.2. Bindings to TLS channels pg. 7
4.3. Bindings to IPsec transport mode IKEv2 IKE_SAs 4.3. Bindings to IPsec pg. 8
4.3.1. Interfaces for creating IPsec channels 4.3.1. Interfaces for creating IPsec channels pg. 8
4.5. Bindings to other types of channels 4.4. Bindings to other types of channels pg. 9
5. Benefits of channel bindings to secure channels 5. Benefits of channel bindings to secure channels pg. 9
6. Security considerations 6. Security considerations pg. 10
7. References 7. References pg. 10
7.1. Informative references 7.1. Informative references pg. 10
7.2. Normative references 7.2. Normative references pg. 11
8. Acknowledgements 8. Acknowledgements pg. 12
9. Author's Address 9. Author's Address pg. 12
N. Williams [Page 2] N. Williams [Page 2]
DRAFT Channel Bindings to Secure Channels Expires November 2004
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
[NOTE: This I-D text has been split out from the "The Channel [NOTE: This I-D text has been split out from the "The Channel
Conjunction Mechanism (CCM) for GSS" I-D, which will be Conjunction Mechanism (CCM) for GSS" I-D, which will be
skipping to change at line 130 skipping to change at line 129
authentication, over TLS to connect to some server but an attacker authentication, over TLS to connect to some server but an attacker
spoofs the name service lookup and causes the TELNET client to be spoofs the name service lookup and causes the TELNET client to be
redirected to some other host which TLS authenticates correctly and redirected to some other host which TLS authenticates correctly and
where the attacker forwards the connection, with or without TLS, to where the attacker forwards the connection, with or without TLS, to
the server that the user had intended. In this example there is an the server that the user had intended. In this example there is an
MITM from the point of view of the application (TELNET), even though MITM from the point of view of the application (TELNET), even though
there is no MITM as far as TLS is concerned. The TELNET client and there is no MITM as far as TLS is concerned. The TELNET client and
N. Williams [Page 3] N. Williams [Page 3]
DRAFT Channel Bindings to Secure Channels Expires April 2004 DRAFT Channel Bindings to Secure Channels Expires November 2004
server cannot assume that there is no MITM and so cannot leverage the server cannot assume that there is no MITM and so cannot leverage the
protection afforded by the TLS channel, unless they prove to each protection afforded by the TLS channel, unless they prove to each
other that there is no MITM. other that there is no MITM.
A solution to this problem is highly desirable, particularly where A solution to this problem is highly desirable, particularly where
multi-user applications are run over secure network layers (e.g., NFS multi-user applications are run over secure network layers (e.g., NFS
over IPsec). For such applications the authentication model used at over IPsec). For such applications the authentication model used at
the application layer (usually user<->server) is generally very the application layer (usually user<->server) is generally very
different from that used by secure, lower network layers, such as different from that used by secure, lower network layers, such as
skipping to change at line 188 skipping to change at line 187
2. Definitions 2. Definitions
The GSS-API [RFC2743] is a generic interface to GSS-API security The GSS-API [RFC2743] is a generic interface to GSS-API security
mechanisms which provides for authentication and session mechanisms which provides for authentication and session
cryptographic protection. One facility provided by the GSS-API is a cryptographic protection. One facility provided by the GSS-API is a
concept of "channel bindings" which consists of some data which must concept of "channel bindings" which consists of some data which must
N. Williams [Page 4] N. Williams [Page 4]
DRAFT Channel Bindings to Secure Channels Expires April 2004 DRAFT Channel Bindings to Secure Channels Expires November 2004
be provided, if at all, by initiators and acceptors and which the be provided, if at all, by initiators and acceptors and which the
GSS-API security mechanisms ensure are the same for both, the GSS-API security mechanisms ensure are the same for both, the
initiator and acceptor of any given GSS-API security context - if initiator and acceptor of any given GSS-API security context - if
the channel bindings provided by them do not match then the mechanism the channel bindings provided by them do not match then the mechanism
fails to establish a security context. fails to establish a security context.
o Channel bindings o Channel bindings
Some data which identifies a channel. Generally some data which names a channel or its end-points.
Where channel bindings are used they MUST be exchanged with
authenticated integrity protection.
o Channel bindings to secure sessions o Channel bindings to secure channels
Channel bindings that securely identify a secure channel, such Channel bindings that securely identify a secure channel or its
that no two channels of the same type can have the same channel end-points.
bindings.
Applications can exchange authenticated, integrity-protected Applications can exchange authenticated, integrity-protected
proofs of their possession of the same channel bindings data to verifiers of their same channel bindings data to prove that the
prove that the endpoints of the channel identified by the channel end-points of the channel identified by the channel bindings are
bindings are the same as the application endpoints (and thus, the same as the application endpoints and thus, there can be no
there can be no MITM at the lower layer). MITM at the lower layer.
More formally, channel bindings to secure sessions More formally, there are two types of channel bindings:
- bindings that name a channel in a cryptographically secure
manner (e.g., the session ID in SSHv2; see below)
- bindings that name the authenticated end-points of a channel
(e.g., as in IPsec; see below)
Bindings that name a channel
- MUST be cryptographically bound to the key exchange of the - MUST be cryptographically bound to the key exchange of the
secure session secure session
- MUST be cryptographically bound to all potentially un- - MUST be cryptographically bound to all potentially un-
authenticated plaintext used for negotiation of the secure authenticated plaintext used for negotiation of the secure
session (e.g., algorithm negotiations) session (e.g., algorithm negotiations)
and and
- users of channel bindings MUST exchange authenticated, - users of channel bindings MUST exchange authenticated,
integrity protected channel bindings data or signatures integrity protected channel bindings data or signatures thereof
thereof (such exchanges MAY also be confidentiality (such exchanges MAY also be confidentiality protected)
protected)
Additionally, the channel represented by the bindings MUST provide Additionally, the channel represented by the bindings MUST provide
a cryptographically secure key exchange and channel setup a cryptographically secure key exchange (and re-keying) and
negotiation, and it MUST provide at least cryptographically secure channel setup negotiation, and it MUST provide at least
data integrity protection services. cryptographically secure data integrity protection services.
Channel bindings data MAY but SHOULD NOT be constructed in such a Channel bindings data SHOULD NOT be constructed in such a way that
way that their exchange requires confidentiality protection. their exchange requires confidentiality protection.
No channel bindings described herein require confidentiality N. Williams [Page 5]
protection.
The security of channel bindings depends on the security of: DRAFT Channel Bindings to Secure Channels Expires November 2004
N. Williams [Page 5] No channel bindings described herein require confidentiality
protected exchanges.
DRAFT Channel Bindings to Secure Channels Expires April 2004 The security of channel bindings depends on the security of:
- the authentication and integrity protection technology used to - the authentication and integrity protection technology used to
protect the channel bindings exchanges at the application protect the channel bindings exchanges at the application
layers layers
- the security of the channels identified by the channel bindings - the security of the channels identified by the channel bindings
- the security of the channel bindings construction - the security of the channel bindings construction
o Channel bindings to network addresses o Channel bindings to network addresses
The GSS-API originally defined only channel bindings to network The GSS-API originally defined only channel bindings to network
addresses. Such channel bindings, of course, are generally not addresses. Such channel bindings, of course, are generally not
cryptographically secure - this is so even though IPsec, say, can cryptographically secure.
be used to secure communications between to IP nodes, except where
the initiators and acceptors using channel bindings to network
addresses are able actually confirm and enforce the use of IPsec
between them.
For channel bindings to network addresses to be secure the For channel bindings to network addresses to be secure the
application peers MUST be able to verify and ensure that network application peers MUST be able to verify and ensure that network
communications between them are secured and that there is no MITM communications between them are secured and that there is no MITM
- which generally means that the application peers MUST be able to - which generally means that the application peers MUST be able to
interpret and authorize identities authenticated by the network. interpret and authorize identities authenticated by the network
and MUST be able to protect the methods by which they obtain the
network addresses in the first place.
In practice channel bindings to network addresses have mostly just In practice channel bindings to network addresses have mostly just
caused trouble with NATs. caused trouble with Network Address Translation (NAT).
3. Authentication protocols and channel bindings 3. Authentication protocols and channel bindings
Some authentication services provide for channel bindings, such as Some authentication services provide for channel bindings, such as
the GSS-API and some GSS-API mechanisms - others do not, such as the GSS-API and some GSS-API mechanisms - others do not, such as
SASL. Where suitable channel bindings facilities are not provided SASL. Where suitable channel bindings facilities are not provided
application protocol designers may include a separate, protected application protocol designers may include a separate, protected
(where the authentication service provides message protection (where the authentication service provides message protection
services) exchange of channel bindings material services) exchange of channel bindings material
skipping to change at line 297 skipping to change at line 297
initialization of GSS-API security contexts, though GSS-API initialization of GSS-API security contexts, though GSS-API
mechanisms are not required to support this facility. mechanisms are not required to support this facility.
This channel bindings facility is defined in detail in RFC2744. This channel bindings facility is defined in detail in RFC2744.
Unfortunately, the use of GSS-API channel bindings is generally not Unfortunately, the use of GSS-API channel bindings is generally not
negotiated by GSS-API mechanisms, therefore GSS-API applications must negotiated by GSS-API mechanisms, therefore GSS-API applications must
agree a priori on the use of channel bindings or otherwise negotiate agree a priori on the use of channel bindings or otherwise negotiate
the use of channel bindings. the use of channel bindings.
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 bindings within their
N. Williams [Page 6] N. Williams [Page 6]
DRAFT Channel Bindings to Secure Channels Expires April 2004 DRAFT Channel Bindings to Secure Channels Expires November 2004
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 bindings within their
existing methods for negotiating GSS-API mechanisms. For example, existing methods for negotiating GSS-API mechanisms. For example,
NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as
does the MOUNT protocol for NFSv2/3 [RFC....]. [NOTE: This is an does the MOUNT protocol for NFSv2/3 [RFC....]. [NOTE: This is an
indirect reference to the Channel Conjunction Mechanism (CCM).] indirect reference to the Channel Conjunction Mechanism (CCM).]
3.2. SASL and channel bindings 3.2. SASL and channel bindings
SASL does not provide for the use of channel bindings during SASL does not provide for the use of channel bindings during
initialization of SASL contexts. initialization of SASL contexts.
skipping to change at line 355 skipping to change at line 354
4.1. Bindings to SSHv2 channels 4.1. Bindings to SSHv2 channels
SSHv2 provides both, a secure channel and material (the SSHv2 SSHv2 provides both, a secure channel and material (the SSHv2
"session ID") that is suitable for use as channel bindings. "session ID") that is suitable for use as channel bindings.
Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the
channel bindings for SSHv2. channel bindings for SSHv2.
4.2. Bindings to TLS channels 4.2. Bindings to TLS channels
TLS provides both, a secure channel and material (the TLS "finished"
messages), that is suitable for use as channel bindings.
N. Williams [Page 7] N. Williams [Page 7]
DRAFT Channel Bindings to Secure Channels Expires April 2004 DRAFT Channel Bindings to Secure Channels Expires November 2004
TLS provides both, a secure channel and material (the TLS "finished"
messages), that is suitable for use as channel bindings.
Thus it is RECOMMENDED that the concatenation of the client's and Thus it is RECOMMENDED that the concatenation of the client's and
server's "finished" messages, in that order, be used as the channel server's "finished" messages, in that order, be used as the channel
bindings for TLS. bindings for TLS.
Note that the TLS "session ID," in spite of being named similarly to Note that the TLS "session ID," in spite of being named similarly to
the SSHv2 session ID, is not suitable for use as channel bindings the SSHv2 session ID, is not suitable for use as channel bindings
because it is assigned by the server, so a MITM could assign the same because it is assigned by the server, so a MITM could assign the same
session ID on the client side as it gets from the server. session ID on the client side as it gets from the server.
4.3. Bindings to IPsec transport mode IKEv2 IKE_SAs 4.3. Bindings to IPsec
IPsec does not provide either a channel or material suitable for use
as channel bindings. However, it is possible to construct IPsec
channels with a simple programming interface for binding connection-
oriented transports to transport mode SAs, and it is possible to
construct channel bindings for IKEv2 IKE_SAs.
The RECOMMENDED channel bindings for IKEv2 IKE_SAs consist of a SHA-1
hash of the concatenation of the octets normally signed by the IKEv2
initiator and responder, in that order, in the AUTH payloads of the
IKEv2 SA exchange for the initial (i.e., non-rekeyed) transport-mode
IKE_SA that corresponds to the SA that a connection is being bound
to.
4.3.1. Interfaces for creating IPsec channels
In order to build an IPsec channel some additional programming
interfaces are needed. Specifically, an interface is needed to
express an application's desire to bind an as yet unconnected
connection-oriented endpoint to an IKEv2 IKE_SA, as well as the
application's desired binding parameters, plus an interface to query
a connected endpoint to examine if the binding to IPsec succeeded as
well as to obtain the necessary channel bindings.
Two forms of transport binding to IPsec are possible: a) binding to
an IKE_SA irrespective of authenticated identities, b) binding to
IKEv2 authenticated identities. Applications MAY request neither,
either or both of these. Additionally, applications MUST request
integrity or confidentiality protection (the latter MUST imply the
former) and MAY limit the set of IPsec integrity and/or
confidentiality protection algorithms, acceptable key lengths, etc...
Together these items constitute the connection binding parameters.
Applications MUST agree a priori, whether by design, configuration or IPsec does not provide a way to reliably name a channel regardless of
through some other form of out-of-band negotiation, on compatible what key exchange protocol is used.
binding parameters. This is because existing connection-oriented
transport protocols, such as TCP and SCTP, do not provide for
negotiation of IPsec connection binding parameters, therefore, if the
applications do not agree a priori, they will fail to interoperate.
Note also that the binding status of an established connection cannot
be changed without support for such binding negotiation in the
transport protocol.
N. Williams [Page 8] Therefore, the only reliable way to construct channel bindings to
IPsec is to use the identities authenticated by the IPsec key
exchange protocol for the given channel.
DRAFT Channel Bindings to Secure Channels Expires April 2004 New interfaces [IPSP-APIREQ] are required by which applications can
create IPsec "channels."
When a connection-oriented transport is bound to IPsec the host MUST The basic idea is to use the interfaces described in [IPSP-APIREQ] to
NOT send or process any IP packets for that connection protected with dynamically alter the SPD to reflect the requested bindings for the
any SA which either: a) is not the IKE_SA that the connection was requested connections and then use the authenticated IDs as the
bound to (or an SA that was derived therefrom in a cryptographically identity of the channel.
secure manner, such as through IKEv2 rekeying, or a CHILD_SA), b)
does not authenticate the same IKEv2 identities that were bound to,
or c) does not provide the protection service requested by the
application. That is, the host MUST enforce the connection binding
requirements of its applications. Server hosts determine the IKE_SA
and/or IKEv2 IDs to which new connections are bound by inspection of
the SA used to protect the initial packet for each new connection.
In terms of the familiar sockets APIs this means having a socket This approach does not name the channel directly, but no MITM can
option to set on sockets prior to calling connect() or listen() and ensure that the authenticated IDs used as channel bindings match on
an socket option (perhaps the same option) to get the binding both end-points unless the MITM has stolen or broken the IPsec
state and channel bindings after a socket has been connect()ed or credentials and/or authentication protocol. This is sufficient.
accept()ed. The programming language-specific details of these
interfaces are not specified here.
More formally the following APIs are needed: 4.3.1. Interfaces for creating IPsec channels
- An interface for indicating an application's desired connection In order to build an IPsec channel some additional application
binding parameters: programming interfaces are needed to:
- 'BINDING_TYPE', the type of binding, either or both of: - indicate that an as yet unconnected channel is to be bound to
IPsec IDs and
- 'IKE_SA_BINDING', an IKE_SA, not identified by the - explicitly specify one, the other or both of those IDs
application, and its rekeyed and CHILD_SA successors - implicitly specify one, the other or both of those IDs (e.g.,
the ID corresponding to the current application program
instance)
- indirectly specify one, the other or both of those IDs (e.g., a
hostname)
and/or and/or
- 'IKE_ID_BINDING', IKEv2 authenticated identities, - discover the IPsec IDs to which a channel is bound
optionally specified by the application
- 'BINDING_PROT', the payload protection service desired, that
is, integrity or confidentiality and integrity protection
- 'BINDING_PROT_ALGS', the acceptable protection service
algorithms and algorithm parameters
such that, once bound, no messages are sent, and no received
messages are processed, for the given connection that are not
protected by an SA that satisfies the binding requirements.
Unspecified binding parameters (the IKE_SA and/or IKEv2
authenticated IDs) are established by the first message sent
(client-side) or received (server-side) for a connection to be
bound. For example, for TCP connections, the binding parameters
are those of the SA selected for protecting the TCP SYN packet).
Applications MUST agree a priori on the connection binding
parameters to use (except for the BINDING_PROT_ALGS parameter,
where the server-side MAY specify a super-set of the client's
N. Williams [Page 9]
DRAFT Channel Bindings to Secure Channels Expires April 2004
BINDING_PROT_ALGS). Applications MAY leave BINDING_PROT_ALGS
unspecified, leaving the SPD as the control of what algorithms
are used.
- An interface for querying the binding state of a connection
(i.e., "is this connection bound to IPsec?").
- An interface for querying the channel bindings of a connection's
IKE_SA binding.
- An interface for querying the identities authenticated by IKEv2 N. Williams [Page 8]
for the bound SAs.
Connection binding can fail when bound IKE_SAs fail to rekey DRAFT Channel Bindings to Secure Channels Expires November 2004
properly, when bound identities' credentials expired, or when there
is disagreement, between client and server, on what type of
connection binding, if any, is to be used. Implementations of
connection binding MUST cause the connection to reset or to hang
under any of these conditions, but MUST specify which behaviour
results so that applications may detect connection failure and act as
appropriate.
Note that where applications bind application-layer authentication to For connection-less datagram transports the IDs to be used need to be
IKE_SAs, but not IKEv2 IDs, there is an optimization whereby the specified/discovered on a per-datagram basis.
IKEv2 IKE_SA need not be authenticated. That is, the use of
authentication at the application layer with channel bindings to
IKE_SAs gives meaning to "anonymous IPsec," thus enabling the use of
such applications with IPsec and without having to deploy an IKEv2
authentication infrastructure (for those applications).
Connection binding to IPsec does not require changes to the IPsec SPD See [IPSP-APIREQ].
model, though the "bypass" and "apply" actions of SPD entries are
irrelevant to connections bound to IPsec - the "discard" action and
any actions selecting or constraining the usable integrity and
confidentiality algorithms that can be used still apply.
4.5. Bindings to other types of channels 4.4. Bindings to other types of channels
For secure session protocols that do not provide material suitable For secure session protocols that do not provide material suitable
for use as channel bindings such material SHOULD be constructed by for use as channel bindings such material SHOULD be constructed by
concatenating the octets from the messages exchanged during the concatenating the octets from the messages exchanged during the
initialization of a session in the chronological order in which they initialization of a session in the chronological order in which they
were exchanged and processed (which requires synchronous session were exchanged and processed (which requires synchronous session
initialization), or a strong hash thereof (such as SHA-1). initialization), or a strong hash thereof (such as SHA-1).
Some secure session protocols do not provide a secure channel but Some secure session protocols do not provide a secure channel but
which do provide per-message integrity or confidentiality protection which do provide per-message integrity or confidentiality protection
services. It is up to the network layers that use such protocols to services. It is up to the network layers that use such protocols to
build channels from such services; applications MUST NOT delegate build channels from such services; applications MUST NOT delegate
session cryptographic protection to network layers that do not session cryptographic protection to network layers that do not
provide a secure channel. provide a secure channel.
Kerberos V, certain GSS-API and SASL mechanisms, all provide session Kerberos V, certain GSS-API and SASL mechanisms, all provide session
N. Williams [Page 10]
DRAFT Channel Bindings to Secure Channels Expires April 2004
cryptographic protection and the necessary key exchange, but they cryptographic protection and the necessary key exchange, but they
provide neither a channel nor material suitable for use as channel provide neither a channel nor material suitable for use as channel
bindings. bindings.
Thus the RECOMMENDED channel bindings for channels protected by Thus the RECOMMENDED channel bindings for channels protected by
Kerberos V consist of a SHA-1 hash of the concatenated octets of the Kerberos V consist of a SHA-1 hash of the concatenated octets of the
AP-REQ and AP-REP messages, in that order (or, for user-to-user AP-REQ and AP-REP messages, in that order (or, for user-to-user
exchanges, the various messages exchanged, including the ticket exchanges, the various messages exchanged, including the ticket
request, ticket and AP messages, in the order in which they were request, ticket and AP messages, in the order in which they were
generated and processed) used to initialize the channel's generated and processed) used to initialize the channel's
skipping to change at line 566 skipping to change at line 468
The use of channel bindings to delegate session cryptographic The use of channel bindings to delegate session cryptographic
protection include: protection include:
o Performance improvements by avoiding double protection in cases o Performance improvements by avoiding double protection in cases
where IPsec is in use and applications provide their own secure where IPsec is in use and applications provide their own secure
channels. channels.
o Performance improvements by leveraging hardware-accelerated IPsec. o Performance improvements by leveraging hardware-accelerated IPsec.
o Performance improvements by allowing RDMA hardware offloading to N. Williams [Page 9]
be integrated with IPsec hardware acceleration.
DRAFT Channel Bindings to Secure Channels Expires November 2004
o Performance improvements by allowing RDDP hardware offloading to
be integrated with IPsec hardware acceleration. If protocols
layered above RDDP use privacy protection then RDDP offload cannot
be done, thus by using channel bindings 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 o Latency improvements for applications that multiplex multiple
users onto a single channel, such as NFS w/ RPCSEC_GSS. users onto a single channel, such as NFS w/ RPCSEC_GSS.
6. Security considerations 6. Security considerations
When delegating session protection from one layer to another, one When delegating session protection from one layer to another, one
will almost certainly be making some session security trade-offs, will almost certainly be making some session security trade-offs,
such as using weaker data encryption/authentication modes. such as using weaker data encryption/authentication modes.
Implementors and administrators SHOULD understand these trade-offs. Implementors and administrators SHOULD understand these trade-offs.
Channel bindings cannot and MUST NOT be used without mutual Channel bindings cannot and MUST NOT be used without mutual
authentication (of client/user/initiator and server/user/acceptor) authentication (of client/user/initiator and server/user/acceptor)
and/or without integrity-protected, authenticated exchange of channel and/or without integrity-protected, authenticated exchange of channel
bindings material. bindings material.
Anonymous secure channels SHOULD NOT be used without authentication Anonymous secure channels SHOULD NOT be used without authentication
and corresponding use of channel bindings (to the anonymous secure and corresponding use of channel bindings (to the anonymous secure
channels) at higher network layers, or for any purposes other than channels) at higher network layers, or for any purposes other than
opportunistic encryption, since such channels provide no opportunistic encryption, since such channels provide no
N. Williams [Page 11]
DRAFT Channel Bindings to Secure Channels Expires April 2004
authenticated protection on their own. authenticated protection on their own.
The security of channel bindings depends on the security of the The security of channel bindings depends on the security of the
channels, the construction of the bindings and the security of the channels, the construction of the bindings and the security of the
authentication and integrity protection used to exchange channel authentication and integrity protection used to exchange channel
bindings. bindings.
7. References 7. References
7.1. Informative references 7.1. Informative references
skipping to change at line 618 skipping to change at line 524
[TELNET] [TELNET]
J. Postel, J.K. Reynolds, RFC0854 (STD0008): "Telnet Protocol J. Postel, J.K. Reynolds, RFC0854 (STD0008): "Telnet Protocol
Specification," May 1993, Status: Standard. Specification," May 1993, Status: Standard.
[DNS] [DNS]
P.V. Mockapetris, RFC1035 (STD0013): "Domain names - P.V. Mockapetris, RFC1035 (STD0013): "Domain names -
implementation and specification," November 1987, Status: implementation and specification," November 1987, Status:
Standard. Standard.
[DNSSEC] [DNSSEC]
N. Williams [Page 10]
DRAFT Channel Bindings to Secure Channels Expires November 2004
B. Wellington, RFC3008: "Domain Name System Security (DNSSEC) B. Wellington, RFC3008: "Domain Name System Security (DNSSEC)
Signing Authority," November 2000, Status: Proposed Standard. Signing Authority," November 2000, Status: Proposed Standard.
[RFC2203] [RFC2203]
M. Eisler, A. Chiu, L. Ling, RFC2203: "RPCSEC_GSS Protocol M. Eisler, A. Chiu, L. Ling, RFC2203: "RPCSEC_GSS Protocol
Specification," September 1997, Status: Proposed Standard. Specification," September 1997, Status: Proposed Standard.
[RFC2623] [RFC2623]
M. Eisler, "NFS Version 2 and Version 3 Security Issues and the M. Eisler, "NFS Version 2 and Version 3 Security Issues and the
NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," June 1999, NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," June 1999,
skipping to change at line 646 skipping to change at line 557
Negotiation Mechanism," December 1998, Status: Proposed Standard. Negotiation Mechanism," December 1998, Status: Proposed Standard.
[CCM] [CCM]
M. Eisler, N. Williams, Internet-Draft: "The Channel Conjunction M. Eisler, N. Williams, Internet-Draft: "The Channel Conjunction
Mechanism (CCM) for GSS," May 2003, Status: Internet-Draft. Mechanism (CCM) for GSS," May 2003, Status: Internet-Draft.
... ...
7.2. Normative references 7.2. Normative references
N. Williams [Page 12]
DRAFT Channel Bindings to Secure Channels Expires April 2004
[Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 & [Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 &
2744), SASL, SSHv2, IKEv2, IPsec, TCP, Kerberos V, SHA-1.] 2744), SASL, SSHv2, IKEv2, IPsec, Kerberos V, ...]
[RFC2026] [RFC2026]
S. Bradner, RFC2026: "The Internet Standard Process - Revision S. Bradner, RFC2026: "The Internet Standard Process - Revision
3," October 1996, Obsoletes - RFC 1602, Status: Best Current 3," October 1996, Obsoletes - RFC 1602, Status: Best Current
Practice. Practice.
[RFC2119] [RFC2119]
S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to
Indicate Requirement Levels," March 1997, Status: Best Current Indicate Requirement Levels," March 1997, Status: Best Current
Practice. Practice.
[RFC2743] [RFC2743]
J. Linn, RFC2743: "Generic Security Service Application Program J. Linn, RFC2743: "Generic Security Service Application Program
Interface Version 2, Update 1," January 2000, Status: Proposed Interface Version 2, Update 1," January 2000, Status: Proposed
Standard. Standard.
[RFC2744] [RFC2744]
J. Wray, RFC2744: "Generic Security Service API Version 2 : J. Wray, RFC2744: "Generic Security Service API Version 2 :
C-bindings," January 2000, Status: Proposed Standard. C-bindings," January 2000, Status: Proposed Standard.
[TCP] [IPSP-APIREQ]
J. Postel, RFC0793 (STD0007): "Transmission Control Protocol," W. Sommerfeld, draft-ietf-ipsp-ipsec-apireq-00: "Requirements for
September 1981, Status: Standard. an IPsec API," June 2003, Status: Draft.
N. Williams [Page 11]
DRAFT Channel Bindings to Secure Channels Expires November 2004
... ...
8. Acknowledgements 8. Acknowledgements
The author would like to thank Mike Eisler for his work on the The author would like to thank Mike Eisler for his work on the
Channel Conjunction Mechanism I-D and for bringing the problem to a Channel Conjunction Mechanism I-D and for bringing the problem to a
head, Sam Hartman for pointing out that channel bindings provide a head, Sam Hartman for pointing out that channel bindings provide a
general solution to the channel binding problem, Jeff Altman for his general solution to the channel binding problem, Jeff Altman for his
suggestion of using the TLS finished messages as the TLS channel suggestion of using the TLS finished messages as the TLS channel
skipping to change at line 703 skipping to change at line 614
Austin, TX 78727 Austin, TX 78727
Email: nicolas.williams@sun.com Email: nicolas.williams@sun.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
N. Williams [Page 13]
DRAFT Channel Bindings to Secure Channels Expires April 2004
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
skipping to change at line 734 skipping to change at line 640
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
N. Williams [Page 14] N. Williams [Page 12]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/