On Tue, May 10, 2011 at 6:03 PM, David McGrew <[email protected]> wrote: > "Finally, applications that perform authentication can obtain end-to-end > confidentiality and integrity guarantees by tying authentication to tcpcrypt > Session ID values." This seems like a potentially useful feature, though it > seems similar to channel binding (RFCs 5056 and 5929).
That's exactly what it would, well, depending on the security properties of those session ID values. I would prefer that the channel binding data for tcpcrypt be derived as a keyed PRF taken over the key exchange messages, with the key being derived from the session key. This approach has the benefit of strongly binding the entire negotiation (e.g., of algorithms, ...) and also being defined independently of the key exchange algorithm (which is nice because you propose using key transport, but I can imagine that some will want key agreement). I'll review the I-D in detail later. Nico --
