In some discussions recently its become clear to me that the properties of crypto binding in TEAP may not be clear to everyone. TEAP crypto bindings main prevent a MiTM attack when an inner method is allowed both inside and outside the tunnel (the Asokan attack). The crypto binding does not necessary protect from a MitM attack the inner method is run inside an authenticated tunnel and the TLS server certificate is not checked by the client. THis is because the crypto binding relies upon the TLS master secret. With some commonly used TLS ciphers (RSA key transport) the master secret is entirely in control of the client an attacker can insert himself in the middle and force both sides to negotiate the same TLS master secret that he knows. TLS ciphersuites that are based on ephemeral Diffie-Hellman (RSA-DHE) prevent a MitM from forcing the TLS secret on client and server to be the same as long as the DH parameters are validated correctly.
I think we should clarify this in the security considerations section: Add to section 7.4.3: "TEAP crypto binding does not guarantee man-in-the-middle protection if the client does not validate the server's certificate. If the TLS ciphersuite derives the master secret solely from the contribution of secrets from one side of the conversation (such as RSA key transport based ciphersuites) then an attacker can insert themselves in the conversation if the server certificate is not verified even if a strong inner method is executed within the tunnel. If the TLS ciphersuite derives the master secret from the contribution of secrets from both sides of the conversation (such as in Diffie-Hellman based cipher suites) then crypto binding can detect an attacker in the conversation if a strong inner method is used. " Currently we have TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA as MUST implement. Perhaps we should just make TLS_DHE_RSA_WITH_AES_128_CBC_SHA a MUST implement and leave the RSA suite as SHOULD or MAY. Thanks, Joe _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
