So what Joe did propose is the appropriate way: assign different EAP
method types to different types of ciphersuites.
method types to different types of ciphersuites.
Do people see the need to limit the types of ciphersuites that can be
negotiated within EAP-TLS?
I think it is better to keep TLS ciphersuite negotiation as it is.
Best regards,
Badra
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
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu