On 08/15/2014 01:37 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Fri, Aug 15, 2014 at 10:36 -0400:
On 08/08/2014 12:47 PM, Nico Williams wrote:
On Fri, Aug 08, 2014 at 12:09:37PM -0400, Brandon Williams wrote:
I have concerns (expressed in an earlier post to the list) about
binding the authenticators used for the data stream with
authenticators used for TCP. If I've understood the earlier
discussion on this thread and the content of RFC5056, you are
suggesting that such bindings should be supported but not required.
Is that correct?
Well, I think the TCP security protocol should have to support channel
binding in that it should support outputting CB data for applications to
use. Use of CB should be optional, of course.
Note that for any protocol using key agreement it's trivial to produce
channel bindings. We're not talking about an onerous requirement.
There's only a relatively minor considerations, which is that the
implementations can't keep large public keys around, so they need to be
hashed as soon as possible and the hashes used for the construction of
CB data -- like TLS Finished messages, for example. Of course, with
ECDH this isn't much of a concern anyways.
Also, I'm curious about how you would envision this working in the
case of, for example, a TCP optimization proxy where the endpoints
of the TCP connections are not the same as the endpoints of the
secure data stream. Do you think it's possible to design a channel
Each end-point has to trust its proxy and the proxy has to communicate
the correct CB to the local end-point.
Well, yes, it's clear that would be necessary. I don't see how that
would be accomplished if the proxy doesn't have direct access to the
data stream security context. Doesn't the CB have to be delivered on an
encrypted data channel in order to prevent an unauthorized MITM from
seeing and misusing it?
How can they misuse it?
If you're thinking someone MITM's the connection, well, then they'd
have to be using a trusted key to sign the CB data, and then the
failure is w/ the authentication, not w/ the CB, or are you thinking
of another misuse?
I think I'm just not expressing myself clearly enough, so I'll try again
from the beginning.
If I understand what I've read about channel binding, the idea is for
one layer in the protocol stack to delegate authority for some part of
its security requirements to another layer in the protocol stack that
has similar security properties. If you have a transport layer
optimization proxy that is trusted to terminate TCP connections but not
trusted to look into or modify the secure end-to-end data stream, how
does channel binding apply?
If the TCP header is not being authenticated, then channel binding
doesn't apply at all on the proxy because there are no security
requirements for TCP. If the TCP header is being authenticated, there
are security requirements for TCP, but they aren't shared with the
end-to-end data channel. The fact that a received header has been
authenticated doesn't mean anything for the data that was delivered in
the header, since the expectation is that data will have been unmodified
along the whole path. Authentication for the header and the data cannot
be combined in this case, because authentication for the data must show
that the data was unmodified end-to-end, while there is no such
expectation for the header. I don't see an opportunity for security
authority delegation that involves TCP.
--Brandon
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
