One document matched: draft-williams-on-channel-binding-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc1964 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.1964.xml'>
<!ENTITY rfc2203 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2203.xml'>
<!ENTITY rfc2401 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2401.xml'>
<!ENTITY rfc2623 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2623.xml'>
<!ENTITY rfc2743 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc2744 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2744.xml'>
<!ENTITY rfc2817 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2817.xml'>
<!ENTITY rfc2818 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.2818.xml'>
<!ENTITY rfc3008 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.3008.xml'>
<!ENTITY rfc3530 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.3530.xml'>
<!ENTITY rfc3720 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.3720.xml'>
<!ENTITY rfc3748 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc4251 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4251.xml'>
<!ENTITY rfc4301 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc4302 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4302.xml'>
<!ENTITY rfc4303 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4303.xml'>
<!ENTITY rfc4346 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4346.xml'>
<!ENTITY rfc4422 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4422.xml'>
<!ENTITY rfc4462 SYSTEM '/home/nw141292/public_html/bibxml/reference.RFC.4462.xml'>
<!ENTITY nfsv4-rddp SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-nfsv4-nfsdirect.xml'>
<!ENTITY iser SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-ips-iser.xml'>
<!ENTITY connection-latching SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-btns-connection-latching.xml'>
<!ENTITY ipsec-apireq SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-btns-ipsec-apireq.xml'>
<!ENTITY btns-core SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-btns-core.xml'>
<!ENTITY btns-applic SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-btns-prob-and-applic'>
<!ENTITY stackable-pseudo-mechs SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-kitten-stackable-pseudo-mechs'>
<!ENTITY gs2 SYSTEM '/home/nw141292/public_html/bibxml/reference.I-D.ietf-sasl-gs2.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="full3978" docName="draft-williams-on-channel-binding-04.txt">
<front>
<title abbrev="On Channel Bindings">On the Use of Channel Bindings to Secure Channels</title>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city> <region>TX</region>
<code>78727</code> <country>US</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="August" year="2007"/>
<area>Security</area>
<workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
<t>This document discusses and formalizes the concept of
channel binding to secure channels.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref
target="RFC4301"/> <xref target="RFC4303"/> <xref
target="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."</t>
<t>The term "channel binding" as used in this document
derives from the GSS-API <xref target="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.</t>
<t>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 SASL [RFC4422] and even
protocols that provide their own authentication
mechanisms (e.g., the KDC exchanges of Kerberos V
[RFC4120]). We also envision use of the notion of
channel binding in the analysis of security protocols.</t>
<t>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. <xref target="uses"/>
describes some intended uses of channel binding.
Some applications may benefit additionally by reducing
the amount of active cryptographic state, thus reducing
overhead in accessing such state and, therefore, the
impact of security on latency.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC2401"/>
<xref target="RFC4301"/> or HTTP with TLS <xref
target="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 <xref
target="I-D.ietf-btns-prob-and-applic">BTNS</xref>).</t>
<t>For example, iSCSI <xref target="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.</t>
<t>This document describes a solution: the use of "channel
binding" (in the GSS-API <xref target="RFC2743"/>
<xref target="RFC2744"/> sense) to bind authentication at
application layers to secure sessions at lower layers
in the network stack.</t>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
</section>
<section title="Definitions">
<t>
<list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>Channel bindings: [See historical note below.]
<list style='empty'>
<t>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.</t>
<t>More formally, there are
two types of channel bindings:</t>
<t><list style='symbols'>
<t>unique channel bindings:
<vspace blankLines='1'/>
channel bindings that name a
channel in a cryptographically
secure manner and uniquely in
time;</t>
<t>end-point channel bindings:
<vspace blankLines='1'/>
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.</t>
</list>
</t>
</list>
</t>
<t>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" <xref
target="Lampson91"/> some
principal, such as a user, a computer, etcetera.
For example, a 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.
<vspace blankLines='1'/>
Cryptographic bindings are generally asymmetric
in nature (not to be confused with symmetric or
assymetric 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).</t>
</list>
</t>
<t>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 them. A secure channel typically consists
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.</t>
<t>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.</t>
<t>Note that the Extensible Authentication Protocol (EAP) <xref
target="RFC3748"/> which "channel binding" to refer
to a facility appears to be similar to the one
described here, but it is, in fact, quite different.
See <xref target='eap_channel_binding'/> for more
details.</t>
<section anchor="properties" title="Properties of channel binding">
<t>Applications, authentication frameworks (e.g., the
GSS-API, SASL), security mechanisms (e.g., the
Kerberos V GSS-API mechanism <xref
target="RFC1964"/>) and secure channels must
meet the following requirement and should follow the
following recommendations.</t>
<t>Requirements:
<list style="symbols">
<t>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).
<list style='symbols'>
<t>If the authentication protocol used
by the application supports channel
binding the application SHOULD use
it.</t>
<t>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.</t>
<t>If he 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.</t>
<t>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.</t>
</list>
</t>
<t>Specifications of channel bindings for any
secure channels MUST provide for a single,
canonical octet string encoding of the
channel bindings.</t>
<t>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.</t>
<t>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.</t>
<t>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 a 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 depends too on the strength of the
authentication of that name (that is, the
validation of the certificate, the trust
anchors, the algorihtms used in the
certificate path construction and
validation, etcetera).</t>
<t>End-point channel bindings MAY be identifiers
(e.g., certificate names) which 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.</t>
<t>Applications MUST use application-layer
session protection services for
confidentiality protection when the bound
channel does not provide confidentiality
protection.</t>
<t>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).</t>
<t>The channel binding operation MUST be
at least integrity protected in the security
mechanism used at the application layer.</t>
<t>Authentication frameworks and mechanisms that
support channel binding MUST communicate
channel binding failure to applications.</t>
<t>Applications MUST NOT send sensitive
information, requiring confidentiality
protect, over the underlying channel prior
to completing the channel binding
operation.</t>
</list>
</t>
<t>Recommendations:
<list style="symbols">
<t>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.</t>
</list>
</t>
<t>Options:
<list style="symbols">
<t>Authentication frameworks and mechanisms that
support channel binding MAY fail to
establish authentication if channel binding
fails.</t>
<t>Applications MAY send information information
over the underlying channel and without
intergrity 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.</t>
<t>A security mechanism MAY exchange integrity
protected channel bindings.</t>
<t>A security mechanism MAY exchange integrity
protected digests of channel bindings. Such
mechanisms SHOULD provide for hash/digest
agility.</t>
<t>A security mechanism MAY use channel bindings
in key exchange, authentication or key
derivation, prior to the exchange of
"authenticator" messages.</t>
</list>
</t>
</section>
<section anchor="eap_channel_binding" title="EAP channel binding">
<t>This section is informative. This document does not
update EAP <xref target='RFC3748'/>, it neither
normatively describes, nor does it impose
requirements on any aspect of EAP or EAP
methods.</t>
<t>EAP <xref target='RFC3748'/> includes a concept of
channel binding desribed as follows:
<list style='empty'>
<t>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).</t>
</list>
</t>
<t>Section 7.15 of <xref target='RFC3748'/> describes
the problem as one where a a Network Access Server (NAS), (a.k.a.
"authenticator") may like 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).</t>
<t>Section 7.15 of <xref target='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."</t>
<t>This has sometimes been taken to be very similar to
the generic notion of channel binding provided here.
However, these 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:
<list style='symbols'>
<t>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,</t>
<t>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.</t>
</list>
</t>
<t>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).</t>
<t>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.</t>
</section>
</section>
<section title="Authentication and channel binding semantics">
<t>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).</t>
<t>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.</t>
<section title="The GSS-API and channel binding">
<t>The GSS-API <xref target="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.</t>
<t>This channel binding facility is described in <xref
target="RFC2743"/> and <xref
target="RFC2744"/>.</t>
<t>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.</t>
<t>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 <xref
target="RFC3530"/> provides
its own GSS-API mechanism negotiation, as does the
SSHv2 protocol <xref target="RFC4462"/>. Such
pseudo-mechanisms are being proposed separately, see
<xref
target="I-D.ietf-kitten-stackable-pseudo-mechs"/>.</t>
</section>
<section title="SASL and channel binding">
<t>SASL <xref target="RFC4422"/> does not yet provide
for the use of channel binding during
initialization of SASL contexts.</t>
<t>Work is ongoing <xref
target="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 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.</t>
</section>
</section>
<section title="Channel bindings specifications">
<t>Channel bindings for various types of secure channels are
not described herein. Some channel bindings
specifications can be found in:</t>
<texttable>
<ttcol align='left' width='30%'>Secure Channel Type</ttcol>
<ttcol align='left' width='70%'>Reference</ttcol>
<c>SSHv2</c>
<c><xref target="I-D.williams-sshv2-channel-bindings"/></c>
<c>TLS</c>
<c><xref target="I-D.altman-tls-channel-bindings"/></c>
<c>IPsec</c>
<c>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.</c>
</texttable>
<section title="Examples of unique channel bindings" anchor="unique_cbs">
<t>The following text is not normative, but is here to
show how one might construct channel bindings for
various types of secure channels.</t>
<t>For SSHv2 <xref target="RFC4251"/> the SSHv2 session
ID should suffice as it is a cryptographic binding
of all relevant SSHv2 connection parameters: key
exchange and negotiation.</t>
<t>For TLS <xref target="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.</t>
</section>
<section title="Examples of end-point channel bindings">
<t>The following text is not normative, but is here to
show how one might construct channel bindings for
various types of secure channels.</t>
<t>For SSHv2 <xref target="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 channel bindings construction is not
as useful as the one given in <xref
target="unique_cbs"/> above.</t>
<t>For TLS <xref target="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.</t>
</section>
</section>
<section anchor="uses" title="Uses of channel binding">
<t>Uses for channel binding identified so far:
<list style="symbols">
<t>Delegating session cryptographic protection to
layers where hardware can reasonably be expected
to support relevant cryptographic protocols:
<list style="symbols">
<t>NFSv4 <xref target="RFC3530"/> with
Remote Direct Data Placement (RDDP)
<xref
target="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 <xref
target="RFC4303"/> <xref
target="RFC4302"/>.</t>
<t>iSCSI <xref target="RFC3720"/> with
Remote Direct Memory Access (RDMA)
<xref target="I-D.ietf-ips-iser"/>.
Cryptographic session protection would
be delegated to ESP/AH.</t>
<t>HTTP with TLS <xref target="RFC2817"/>
<xref target="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.</t>
</list>
</t>
<t>Reducing the number of live cryptographic
contexts that an application must maintain:
<list style="symbols">
<t>NFSv4 <xref target="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.</t>
</list>
</t>
</list>
</t>
<t>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.</t>
<t>There are a multitude of application layer cryptographic
session 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 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.</t>
<figure>
<preamble>The following figure shows how the various
network layers are related:</preamble>
<artwork><![CDATA[
+---------------------+
| Application layer |<---+
| |<-+ | In cleartext, relative
+---------------------+ | | to each other.
| RDDP |<---+
+---------------------+ |
| TCP/SCTP |<-+
+---------------------+ | Channel binding of app-layer
| ESP/AH |<-+ authentication to IPsec
+---------------------+
| IP |
+---------------------+
| ... |
+---------------------+
]]>
</artwork>
</figure>
</section>
<section title="Benefits of channel binding to secure channels">
<t>The use of channel binding to delegate session cryptographic
protection include: </t>
<t>
<list style='symbols'>
<t>Performance improvements by avoiding double
protection of application data in cases where
IPsec is in use and applications provide their
own secure channels.</t>
<t>Performance improvements by leveraging
hardware-accelerated IPsec.</t>
<t>Performance improvements by allowing RDDP
hardware offloading to be integrated with IPsec
hardware acceleration.
<list style='empty'>
<t>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.</t>
</list>
</t>
<t>Latency improvements for applications that
multiplex multiple users onto a single channel,
such as NFS w/ RPCSEC_GSS.</t>
</list>
</t>
<t>Delegation of session cryptographic protection to IPsec
requires features not yet specified. There is ongoing
work to specify:
<list style='symbols'>
<t>IPsec channels <xref
target="I-D.ietf-btns-connection-latching"/>;</t>
<t>Application programming interfaces (APIs) related
to IPsec channels <xref
target="I-D.ietf-btns-ipsec-apireq"/>;</t>
<t>Channel bindings for IPsec channels;</t>
<t>Low infrastructure IPsec authentication<xref
target="I-D.ietf-btns-core"/>.</t>
</list>
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The IANA is hereby requested to create a new registry for
channel bindings specifciations for various types of
channels.</t>
<t>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.</t>
<t>There is no naming convention for channel bindings: any
string composed of US-ASCII alphanumeric characters,
period ('.') and dash ('-') will suffice.</t>
<t>The procedure detailed in <xref
target='registration_procedure'/> is to be used for
registration of a value naming a specific individual
mechanism.</t>
<section anchor="registration_procedure" title="Registration Procedure">
<t>Registration of a new channel binding requires
expert review as defined in BCP 26 [RFC2434].</t>
<t>Registration of a channel binding is requested by
filling in the following template:
<list style='symbols'>
<t>Subject: Registration of channel binding X</t>
<t>Channel binding unique prefix (name):</t>
<t>Channel binding type: (One of "unique" or
"end-point")</t>
<t>Channel type: (E.g., TLS, IPsec, SSH,
etc...)</t>
<t>Published specification (recommended,
optional):</t>
<t>Channel binding is secret (requires
confidentiality protection): yes/no</t>
<t>Description (optional if a specification is
given; required if no Published
specification is specified):</t>
<t>Intended usage: (One of COMMON, LIMITED USE,
or OBSOLETE)</t>
<t>Person and email address to contact for
further information:</t>
<t>Owner/Change controller name and email
address:</t>
<t>Expert reviewer name and contact
information: (leave blank)</t>
<t>Note: (Any other information that the author
deems relevant may be added here.)</t>
</list>
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.</t>
<t>If the expert approves registration, it adds her/his
name to the submitted registration.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="registration_comments" title="Comments on
channel bindings Registrations">
<t>Comments on a registered Channel bindings should
first be sent to the "owner" of the channel bindings
and to the channel binding mailing list.</t>
<t>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
IANA's sole discretion, IANA may attach the comment
to the Channel binding's registration.</t>
</section>
<section anchor="iana_change_ctrl" title="Change control">
<t>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.</t>
<t>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.</t>
<t>The IESG may reassign responsibility for a Channel
bindings. 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.</t>
<t>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.</t>
<t>The IESG is considered to be the owner of all
channel bindings that are on the IETF standards
track.</t>
</section>
</section>
<section title="Security Considerations">
<t>Security considerations appear throughout this
document. In particular see <xref
target="properties"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="Non-unique channel bindings and channel
binding re-establishment">
<t>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.</t>
<t>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: 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).</t>
<t>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.</t>
</section>
</section>
</middle>
<back>
<references
title="Normative References">&rfc2119;
</references>
<references
title="Informative References">
&rfc1964;
&rfc2401;&rfc2743;&rfc2744;&rfc2817;&rfc2818;&rfc3530;
&rfc3720;&rfc3748;&rfc4251;&rfc4301;&rfc4302;&rfc4303;
&rfc4346;&rfc4422;&rfc4462;
&gs2;&stackable-pseudo-mechs;&iser;&nfsv4-rddp;
&connection-latching;&ipsec-apireq;&btns-applic;&btns-core;
<reference anchor='I-D.williams-sshv2-channel-bindings'>
<front>
<title>Channel Bindings for Secure Shell
Channels</title>
<author initials='N' surname='Williams' fullname='Nicolas Williams'>
<organization />
</author>
<date month='July' day='18' year='2006' />
<abstract><t>This document specifies the channel
bindings for SSHv2.</t></abstract>
</front>
<seriesInfo name='Internet-Draft'
value='draft-williams-sshv2-channel-bindings-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-williams-sshv2-channel-bindings-00.txt' />
</reference>
<reference anchor="Lampson91">
<front>
<title>Authentication in Distributed Systems: Theory
and Practive</title>
<author initials='B' surname='Lampson' fullname='Butler Lampson'>
<organization>DEC</organization>
</author>
<author initials='M' surname='Abadi' fullname='Martin Abadi'>
<organization>DEC</organization>
</author>
<author initials='M' surname='Burrows' fullname='Michael Burrows'>
<organization>DEC</organization>
</author>
<author initials='E' surname='Wobber' fullname='Edward Wobber'>
<organization>DEC</organization>
</author>
<date month='October' year='1991' />
</front>
<format type='PDF'
target='http://portal.acm.org/citation.cfm?doid=121133.121160' />
</reference>
<reference anchor='I-D.altman-tls-channel-bindings'>
<front>
<title>Channel Bindings for SSHv2</title>
<author initials='N' surname='Williams' fullname='Nicolas Williams'>
<organization />
</author>
<date month='July' day='18' year='2006' />
<abstract><t>This document specifies the channel
bindings for SSHv2.</t></abstract>
</front>
<seriesInfo name='Internet-Draft'
value='draft-altman-tls-channel-bindings-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-00.txt' />
</reference>
</references>
<section title="Acknowledgments">
<t>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, Bernard
Aboba, Tom Petch, Mark Brown and many others.</t>
</section>
</back>
</rfc>
<!--
7.1. Informative references
[Needs references to NFSv2/3 use of RPCSEC_GSS, to NFSv4, to SCTP,
and, possibly, to DNS, DNSSEC, TELNET, SPNEGO, SSHv2 gss keyex, and
CCM.]
7.2. Normative references
[Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 &
2744), SASL, SSHv2, IKEv2, IPsec, Kerberos V, ...]
-->
| PAFTECH AB 2003-2026 | 2026-04-19 17:55:47 |