On Fri, Aug 15, 2014 at 10:36:35AM -0400, Brandon Williams wrote: > >>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?
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" == 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? > [...]. 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. [...] Answered separately. > [...]. 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". 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). > 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. Probably in the KITTEN WG list archives from a few years ago. The subject was trusted HTTP proxies, not meddlesome untrusted middleboxes. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
