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

[Yoav Nir <ynir at checkpoint.com>]

comments inline...

On Oct 14, 2007, at 7:02 PM, Simon Josefsson wrote:

> 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?

[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.

> 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.

[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.

> 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?

[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.

> /Simon

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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