From: Badra
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 23, 2006
11:43 AM
To: Charles Clancy
Cc: Bernard Aboba; [email protected]
Subject: Re: [Emu] Tying EAP-TLS
method type to specific ciphersuites
On 10/23/06, Charles
Clancy <[EMAIL PROTECTED]>
wrote:
So that answers the questions from my last email. It sounds
like PKI vs
PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs
TLS credential negotiation, which I don't see as a big problem,
personally.
Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and
PSK)? Or
EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND
footprint
issues, perhaps something like ...
EAP-TLS-v1
EAP-TLS-v2-PSK
EAP-TLS-v2-PKI
... might be appropriate.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote:
> During the EMU BOF we talked about the high cost that would be imposed on
> customers by introducing new non-certificate ciphersuites during EAP-TLS.
>
> EAP-TLS is now ten years old, and has a very large installed base.
> Virtually all of these installations only support certificate-based
> authentication, since that is a requirement of RFC 2716, which states:
>
> If the EAP server is not resuming a previously
established
> session, then it MUST include a TLS
server_certificate handshake
> message, and a server_hello_done handshake message
MUST be the last
> handshake message encapsulated in this EAP-Request
packet....
>
> If the EAP server sent a certificate_request
message in the preceding
> EAP-Request packet, then
> the peer MUST send, in addition, certificate and
certificate_verify
> handshake messages.
>
> As a result of these and other specification requirements, an
> implementation
> that does not support certificate authentication is non-compliant with RFC
> 2716.
>
> During the BOF we also talked about the drawbacks of attempting to support
> both certificate and non-certificate modes in a single EAP
method. Such
> an
> approach would require embedded systems to take on the footprint of
> certificate handling even when all they really needed to do was to support
> pre-shared keys. It would also add new potential security
vulnerabilities
> to one of the few EAP methods that has provable security properties.
>
> In addition adding new non-certificate modes would impose large costs on
> customers. Today there are interoperability and conformance test suites
> for
> EAP-TLS that assume that only certificate-based authentication is
> supported.
> In addition, EAP-TLS has been approved for use within FIPS
140-2
> installations, based on support for certificate-base ciphersuites.
> Introducing new non-certificate modes would introduce confusion, and would
> force existing test suites to be re-written.
>
> For customers, deployment of EAP is difficult enough without introducing
> confusion, interoperability problems and new security vulnerabilities into
> the one EAP method that today is synonmous with high security.
>
>
>
> _______________________________________________
> Emu mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
