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?
binding solution that supports an authorized MITM while at the same
time mitigating the risk of an unauthorized MITM without requiring
the client-side application (at least) to know whether an authorized
MITM is in use?
Yes. See above.
This is not the first time that we've discussed CB in the context of
proxies. We've talked about it endlessly in the context of HTTP
proxies, and it's clear how to handle it.
Not supporting CB means that applications that want authenticated
security can't use this protocol unless this protocol provides that
authentication. But applications tend to have different authentication
requirements at their layers than lower layers do -- retrofitting
authentication into TCP would quickly develop all the problems that TLS
user authentication has, and then some (because the typical
user-mode<->kernel-mode barrier will tend to limit API complexity).
Having worked this out for an application layer proxy scenario doesn't
automatically mean that it will work for a transport layer proxy. All of
the CB binding examples I can find appear to delegate security
responsibility downward in the protocol stack ... typically application
layer protocols binding to a lower layer secure channel like IPSec, TLS,
or SSHv2. My question is specifically about delegating security
responsibility upward; using the security context of an end-to-end
authenticated and encrypted channel to authenticate the TCP headers for
connections that are not end-to-end. How would this be done in a way
that doesn't allow a MITM that is authorized to terminate the TCP
connection from making unauthorized changes to the secure end-to-end
data stream?
If you've got a document or archived e-mail thread that you can point me
at that discusses this, I'll be happy to just read up on the problem. I
haven't been able to find such a document yet.
--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
