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
