Hello, The tunnel method draft indicates that an anonymous TLS ciphersuite should only be used in accordance with the server unauthenticated provisioning mode described in RFC 5422. This is unfortunate because the technique described in RFC 5422 requires changes to an existing EAP method, which is unnecessarily confusing, and it is also susceptible to attack.
I propose we fix this problem by defining a server unauthenticated provisioning mode in the draft itself, something similar to the technique used by TEAM. To do this there are a couple places that need to get touched. - Section 3.2 says, "Other ciphersuites MAY be supported. It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [RFC5422]." I suggest it say, "Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in <new section>." - Adding a new section to describe the technique. I suggest making this a new 3.4 and bumping 3.4-7 to 3.5-8. New section should read: "3.4 Server Unauthenticated Provisioning Mode "In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in phase 1 and the peer and server negotiate an EAP method in phase 2 that supports mutual authentication and key derivation that is resistant to dictionary attack. This provisioning mode enables the bootstrapping of peers when the peer lacks a strong credential usable for mutual authentication with the server during phase 1. "Upon successful completion of the EAP method in phase 2, the peer and server exchange a Crypto-Binding TLV to bind the inner method with the outer method and ensure that a man-in-the-middle attack has not been attempted. "Support for the Server Unauthenticated Provisioning Mode is optional but to ensure interoperability, an implementation that does support Server Unauthenticated Provisioning Mode MUST support TLS_DH_anon_WITH_AES_128_CBC_SHA as a TLS ciphersuite and MUST support EAP-pwd [RFC 5931] as a phase 2 method. "Other anonymous ciphersuites MAY be supported. Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, key generation, and be resistant to dictionary attack." regards, Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu