This is the third message in my response to Sam's long post. This topic: channel bindings.
Sam Hartman wrote: > I'll note that a lot of use cases such as channel binding where the > tunnel method is considered without certificate verification are > entirely inappropriate if the inner method is terminated at a different > place than the tunnel method. How do we want to solve that problem? The current crypto bindings tie the inner tunnel authentication to the TLS MSK. We can't use the TLS MSK to sign the channel binding data, as a MITM server could just sign it, and never send it to the home server. The only solution I can think of is to tie the channel binding data to the authentication credentials. This could be done by using an HMAC over the channel binding data, using a key derived from the users authentication credentials. The client could then sign the channel binding data using this HMAC. The home server could verify it, and sign its response using the same method. The client would then verify the response. This method still allows MITM attacks, but ensures that the home server has seen the channel binding data. We could also key the HMAC using a key derived from *both* the TLS MSK and from the users authentication credentials. This would ensure that MITM attacks are impossible. I'm interested in seeing a wider discussion of these topics. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
