On the Use of Channel Bindings to Secure Channels
RFC 5056

Received changes through RFC Editor sync (changed abstract to '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. [STANDARDS-TRACK]')

[Ballot comment]
Nits in -03:
OLD:
      point channel binding should be used to verify a signature of a
      such negotiations (or to encrypt them), including the initial key
NEW:
      point channel binding should be used to verify a signature of
      such negotiations (or to encrypt them), including the initial key

OLD:
  o  Applications MUST NOT send sensitive information, requiring
      confidentiality protect, over the underlying channel prior to
NEW:
  o  Applications MUST NOT send sensitive information, requiring
      confidentiality protection, over the underlying channel prior to

[Ballot comment]
I feel that Chris Newman's Discuss must result in a document change
before this work should go forward.

> Note that the Extensible Authentication Protocol (EAP) [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.

Is there a word missing from here? This sentence is hard to
parse.

> [I-D.ietf-nfsv4-nfsdirect] for zer-copy reception where network

"Zer-copy"?

> bindings specifciations for various types of channels.

s/specifciations/specifications/

[Ballot discuss]
This is a good document and long overdue. Once the following
is cleared I will move to a Yes position.

I am uncomfortable with the IANA considerations part of the
document. Specifically, the document claims the following:

  ... not only to ensure uniqueness of
  values used to name channel bindings, but also to provide a
  definitive reference to technical specifications ...

The first part makes a lot of sense, but in order to do make
it useful, shouldn't there be some kind of a protocol parameter
somewhere which takes on the values of these bindings? For
instance, that you must feed "IPSEC-BINDING-RFC5555"
into an application layer authentication protocol
parameter or something along those lines? But the document
states that there is no naming convention on channel
bindings, and does not explain where the IANA allocated
values should be placed. But it may be that I'm missing
something and there is something in this document or
in earlier documents that defines how the values are
used.

If there is no such usage for the values, it
is better to just state that future IETF work on
channel bindings must satisfy some documentation
and review criteria, and leave IANA out of the loop.
IETF documents can state requirements for how
extensions of our protocols are developed. However,
such requirements must always be stated in a context
"if you extend TLS state machine..." "if you allocate
new values for the protocol number field in the IP
header..." etc. We cannot state requirements for
the use of a concept; someone might apply the concept
elsewhere in a completely unrelated issue.

[Ballot comment]
This document would be enhanced by additional information how these bindings should be
used. In particular, it needs to be clear that, when the channel itself does not provide a
means for authentication, (i.e. when not using end point channel bindings), one of the end
parties must authenticate to the other at the higher layer, and leverage this authentication
to send his value of the channel binding to the other party.  Neither party can verify that
the channel bindings at the end points match unless one or both of the end points are
authenticated at the higher layer.

The document alludes to this in the Recommendations in 2.1 ("Applications SHOULD use
mutual authentication at the application layer when using channel binding.")  However,
there is an apparent conflict in section 8, which says:

  Channel binding makes "anonymous" channels (where neither end-point
  is strongly authenticated to the other) useful.

I beleive the clarification wrt anonymous session or transport leveraging authentication
in the application layer would help clarify the intent...

[Ballot comment]
I feel that Chris Newman's Discuss must result in a document change
before this work should go forward.

> Note that the Extensible Authentication Protocol (EAP) [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.

Is there a word missing from here? This sentence is hard to
parse.

[Ballot comment]
> Note that the Extensible Authentication Protocol (EAP) [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.

Is there a word missing from here? This sentence is hard to
parse.

[Ballot comment]
I would put these as discusses but I think others already have them...

1) I think this should be a BCP. I have no idea how it would advance on the standards track. I have no problem with a BCP creating an IANA registry.

2) I think the document needs to refine the IANA rules. I am not a fan of authors as the change controllers. What happens if they can just not be found?

[Ballot comment]
I'm not sure this text about SASL will be true:
  ...  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.
outside the GS2 mechanism.  I suspect most future SASL mechanisms won't
offer a security layer at all, in which case the correct behavior is to
fail the authentication if the channel binding fails.

Another benefit of channel bindings that wasn't mentioned is the
ability to remove redundant complexity in our protocol stack.  Every
time we've attempted to roll out a security layer (IPsec, TLS, SSH, etc)
there have been lots of security problems at the design, implementation
and deployment stages of the protocol life.  It seems very difficult to
get a security layer "right" which suggests a better architecture would
have fewer places where such security layers occur.

[Ballot discuss]
This is a "please consider fixing this, but I might be convinced otherwise" DISCUSS.

----
      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
      there are too many trust anchors, or because some are of dubious
      repute).
----
I'm not sure exactly what this means but if it means what I think it
does, then it will be ignored in practice.  For example, if an
application uses both TLS and an application-layer authentication
mechanism, it will _use_ the TLS framework for server authentication at
but may rely on server authentication at the application layer because
the TLS layer tends to have too many trust anchors.  Some TLS
implementations don't offer the anonymous cipher suites so an
application depending on such an implementation has no choice but to
use TLS server authentication regardless of the trust anchor situation.

Also I'm uncomfortable with "MUST NOT" because relying on weak endpoint
channel bindings might be better than _no_ endpoint channel bindings
in some cases.  This seems more like a security consideration than a
2119 requirement.

FYI, I very much support this work so I can live with the present text
if the only alternative is a long delay.

[Ballot discuss]
IANA section

A real discuss DISCUSS:

I need to expand on Lars's discuss. What does defining this registry really provide? It seems that you have a need to define how you use each channel-binding to be able to utilize them. What does providing a unique name for each combination of upper and lower layers provide, that isn't solved within in each protocol that uses them? Are there any real usage for these identifiers?

[Ballot discuss]
I have two questions that I'd like to discuss. I fully expect to clear this DISCUSS before or during the telechat:

  Is Proposed Standard the appropriate category for this document?
  Wouldn't BCP be more suitable?

Section 7.1., paragraph 15:
>    and sending it via electronic mail to a list to be determined [note:
>    an ietf.org list for this is needed, say, channel-binding@ietf.org]
>    and carbon copying IANA at .  After allowing two weeks
>    for community input on the mailing list to be determined, an expert
>    will determine the appropriateness of the registration request and
>    either approve or disapprove the request with notice to the
>    requestor, the mailing list, and IANA.

  If community review of a request is desired, "Specification Required"
  or "IETF Consensus" from RFC2434 already have that. "Expert Review"
  would be another option. Do we really need to invent a new IANA
  procedure here? Also, who is the designated expert?

IANA Evaluation Comments:

IANA Has Questions:

Upon approval of this document, the IANA will
create the following registry "???" located at
http://www.iana.org/assignments/TBD

Registration Procedure: Expert Review
NOTE: Need to specify the Expert

Initial contents of this registry will be:

[Guess of table headers]

Name Binding Channel Secret? Usage Reference
Type Type
------- -------- ------- ------- ----- ----------

QUESTIONS:
1) What is the requested name of this new registry?
2) What information do you want stored in the registry,
specifically?

Do you want the full template stored, or only a
subset and a pointer to the reference?

We understand the above to be the only IANA Action
for this document.

IANA Additional Comments:

IANA received Nicolas's Comments.
"This draft is currently in IETF Last Call and one comment is
a request for an IANA registry. I believe we do have consensus
to add a registry and are merely awaiting consensus on new text."

Subject: AD Review for draft-williams-on-channel-bindings


Overall:

I think this i a good document.  However I also think it would benefit
from a pass by a good writer who is not familiar with channel
bindings.  There are a number of cases where the text would be
somewhat unclear to someone not familiar with channel bindings.  I'm
going to see if I can recruit someone to help.  I will not allow this
to delay us significantly.


In the introduction, you nneed to make it clear that while channel
bindings were originally introduced in GSS-API, they have proven
useful beyond that context.  The current text implies that while
channel bindings are useful for a number of lower layers they are only
useful for the GSS upper layer.



The following two chunks of text are particularly problematic:

  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].



  This document describes a solution: the use of "channel binding" (in
  the GSS-API [RFC2743] [RFC2744] sense)


I recommend removing the parenthetical from the second text and the
following reworking of the first.

  The GSS-API [RFC2743] has a concept of "channel binding" that allows
applications to ensure that the end-points of an underlying
  secure channel are the same
  at the GSS-API level and at a lower 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
both in the GSS-API context and in broader contexts ,
  primarily in leveraging hardware implementations of common
  cryptographic protocols, such as IPsec [RFC4301] [RFC4303] [RFC4302]
  and TLS [RFC4346].

  This document describes details necessary to implement channel
bindings in an interoperable manner and expands the concept beyond a
GSS-API facility to a general purpose mechanism usable by a variety of
authentication mechanisms and lower-layer channels.

Section 2:

You need to actually describe what the EAP concept of channel bindings
is and how it differs.
Section 2.1:
Lose the bracketed text claiming there is more work to do.

  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.



What do you mean here?  Perhaps something like Unique channel bindings
MUST bind to bothe keys exchanged to protect the channel and to any
parameters negotiated to set up the channel such as cipher and
integrity algorithms.
  o  Applications MUST use application-layer session protection
      services for confidentiality protection when the bound channel
      does not provide confidentiality protection.


What? Perhaps you mean that if an application desires confidentiality
protection and the channel does not provide it, then the application
must use an application layer confidentiality mechanism.  If so, this
is a statement of fact and not a requirement; you can point it out
using non-normative language.  This is probably the wrong section
though.

  o  The integrity of a secure channels MUST NOT be weakened should
s/integrity/integrity or confidentiality

      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).

Please reword to remove the however as you are not contradicting the
previous information.


  o  Authentication frameworks and mechanisms that support channel
      binding MUST communicate channel binding failure to applications.


What does this mean?


  o  Applications SHOULD use mutual authentication at the application
      layer when using channel binding.


Mutual authentication is not well defined.  What do you actually
require a a security guarantee here?


  o  A security mechanism MAY exchange integrity protected channel
      bindings.

True, but why is this a normative may?  What are you trying to imply
about the system?  Possibilities include that channel bindings are
potentially public.
If so, I think you already have that requirement above.

  o  A security mechanism MAY use channel bindings in key exchange,
      authentication or key derivation, prior to the exchange of
      "authenticator" messages.

What's an authenticator message.


Section 3:

In order to do this the application-layer
  authentication service must provide message protection services, at
  least integrity protection.

You also need to provide peer entity authentication or data origin authentication of the protected message.

Section 3.2

  SASL [RFC4422] does not yet provide for the use of channel binding
  during initialization of SASL contexts.

Add something like "but specific mechanisms may provide channel binding as a facility in addition to the basic SASL services.

Section 4: Point out that while this section is not normative, section
2 provides requirements that channel bindings specifications need to
meet.