On the Use of Channel Bindings to Secure Channels
RFC 5056

Note: This ballot was opened for revision 04 and is now closed.

(Sam Hartman) Yes

(Chris Newman) (was Discuss) Yes

Comment (2007-07-30)
No email
send info
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

(Jari Arkko) (was Discuss) No Objection

Comment (2007-07-05)
No email
send info
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/

(Ron Bonica) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

(Cullen Jennings) No Objection

Comment (2007-07-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2007-07-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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...

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection