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

From: Yoav Nir <[email-masked]>
Date: Sun, 14 Oct 2007 17:01:24 +0200

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.

Comments are welcome.

Begin forwarded message:

> From: [email-masked]
> Date: October 14, 2007 4:00:02 PM IST
> To: [email-masked]
> Subject: I-D Action:draft-nir-tls-eap-02.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : TLS using EAP Authentication
> 	Author(s)       : Y. Nir, et al.
> 	Filename        : draft-nir-tls-eap-02.txt
> 	Pages           : 19
> 	Date            : 2007-10-14
>
> This document describes an extension to the TLS protocol to allow TLS
> clients to authenticate with legacy credentials using the Extensible
> Authentication Protocol (EAP).
>
> This work follows the example of IKEv2, where EAP has been added to
> the IKEv2 protocol to allow clients to use different credentials such
> as passwords, token cards, and shared secrets.
>
> When TLS is used with EAP, additional records are sent after the
> ChangeCipherSpec protocol message and before the Finished message,
> effectively creating an extended handshake before the application
> layer data can be sent.  Each EapMsg handshake record contains
> exactly one EAP message.  Using EAP for client authentication allows
> TLS to be used with various AAA back-end servers, such as RADIUS or
> Diameter.
>
> TLS with EAP may be used for securing a data connection such as HTTP
> or POP3.  We believe it has three main benefits:
> o  The ability of EAP to work with backend servers can remove that
>
> burden from the application layer.
> o  Moving the user authentication into the TLS handshake protects the
>
> presumably less secure application layer from attacks by
>
> unauthenticated parties.
> o  Using mutual authentication methods within EAP can help thwart
>
> certain classes of phishing attacks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nir-tls-eap-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> 	"get draft-nir-tls-eap-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-nir-tls-eap-02.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <2007-10-14095758.I-D\@ietf.org>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Oct 2007 19:02:57 +0200

> 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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Oct 2007 13:50:16 +0200

comments inline...

> How does your proposal compares with the proposal to support GSS- 

[YN] They're both proposals for integrating other-than-certificate  
authentication into TLS. Both make use of external authentication  
servers. In some ways they are competing proposals, but in practice,  
GSS-API and EAP really map to Kerberos and RADIUS/DIAMETER. Both  
kinds of infrastructure exist, and should be available for applications.

> end up negotiation the weak EAP mechanism even though Kerberos was

[YN] I'm not sure I buy this scenario as a protocol failure. I think  
the problem here is not some downgrade attack, but the fact that the  
application supports the weak EAP mechanism. If your infrastructure  
supports EAP-GTC for passwords, then you're going to be about as  
secure as the current "connect using TLS and type your password on a  
form" method of logging in.

> EAP-in-TLS.  It would be complex though.  Thoughts?

[YN] This can be done, but as far as I can tell, the EAP-GSSAPI  
effort was abandoned 5 years ago. The last version was http:// 
tools.ietf.org/html/draft-aboba-pppext-eapgss-12 . If it comes to the  
TLS WG choosing to take on either one document or another, I guess  
this effort would be resurrected so that both RADIUS/DIAMETER  
infrastructures and Kerberos can be accommodated.