On the Use of Channel Bindings to Secure Channels
RFC 5056
Yes
(Sam Hartman)
No Objection
Lars Eggert
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Tim Polk)
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert
(was Discuss)
No Objection
Chris Newman Former IESG member
(was Discuss)
Yes
Yes
(2007-07-30)
Unknown
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
Sam Hartman Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
(2007-07-04)
Unknown
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?
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2007-07-05)
Unknown
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/
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2007-07-05)
Unknown
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...