[TLS] Re: Fwd: I-D Action:draft-nir-tls-eap-02.txt

[Simon Josefsson <simon at josefsson.org>]

Yoav Nir <ynir at checkpoint.com> writes:

> Hi all.
>
> We've published the -02 iteration of the TEE draft. The aim is to
> leverage EAP-using infrastructure such as RADIUS and DIAMETER servers
> for the authentication of TLS sessions.
>
> Following comments expressed about version -01, we've added some text
> that explains why the EAP exchange needs to be integrated into the
> TLS handshake rather than be part of the application.

How does your proposal compares with the proposal to support GSS-API in
the TLS handshake?

It would be an interoperability failure if both EAP-in-TLS and
GSSAPI-in-TLS were standardized and there aren't applicability
statements for application protocols like HTTP, IMAP, SMTP.

There may also be security failures, if an implementation would support
both EAP-in-TLS and GSSAPI-in-TLS.  This is because there doesn't seem
to be any way for applications to negotiate the globally most secure
mechanism.  Consider if the application supports Kerberos via
GSSAPI-in-TLS and a weak EAP mechanism via EAP-in-TLS.  There doesn't
seem to be any way for the application to detect this situation?  It may
end up negotiation the weak EAP mechanism even though Kerberos was
supported.

I think EAP may make slightly more sense than GSS-API because (with the
exception of Kerberos) there are few widely deployed GSS-API mechanisms.
In contrast there are many deployed EAP mechanisms.  Instead of
GSSAPI-in-TLS we could define a EAP-GSSAPI mechanism, and use it in
EAP-in-TLS.  It would be complex though.  Thoughts?

/Simon


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls