On 08/18/2014 04:33 PM, Nico Williams wrote:
On Fri, Aug 15, 2014 at 10:36:35AM -0400, Brandon Williams wrote:
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?
Generally "yes", but for some systems the network between them and the
proxy might be considered secure (e.g., physically, or perhaps using
IPsec). In any case, this protocol should be composable for the proxy
case: tcpcrypt to the proxy, proxy tcpcrypts to the server (or server's
proxy, which then might tcpcrypt to the server).
This approach does not meet the security requirements that I'm
interested in: MITM is authorized to reframe the data stream for
transport optimization purposes, but is not authorized to decrypt or
inject data. Splitting transport layer authentication at the TCP
termination points could be done without violating the security policy,
but splitting tcpcrypt could not, at least not as it's currently defined.
[... "this" == CB with trusted proxies in the path ...]
Having worked this out for an application layer proxy scenario
doesn't automatically mean that it will work for a transport layer
proxy. [...]
Why wouldn't it?
An application layer proxy is authorized to view and modify decrypted
data. A transport layer proxy does not necessarily have this authorization.
[...]. 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?
Well now, TCP headers are supposed to be end-to-end. If middleboxes
must be able to mess with those headers then the protocol design has to
be more careful but it can still be made to work because what we're
after isn't "integrity protection for headers" but "integrity (and
confidentiality) protection for [two paired] octet streams".
The data stream is end-to-end, but the TCP connections are not, which is
why the security requirements at the transport layer are distinctly
different from the security requirements at the higher layers.
Once you cast the problem in that mold it is easier to see that a
requirement for CB doesn't interfere with the trusted middleboxes nor
middleboxes that are not trusted but which are allowed to do things like
reframe the streams (if indeed such middleboxes must be tolerated).
The question of whether such boxes must be tolerated is the one that I'm
primarily trying to answer.
--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
