Subject: RE: [Emu] Identity Protection in EAP-TLS

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 8 Jun 2006 12:40:23 -0700

I agree that we need to determine what we can get away with and still be
backward compatible.  I think a big issue is whether TLS extensions are
allowed within RFC2716bis.  It may be that extensions will need to be
left for an enhanced EAP-TLS (which the working group needs to define).

Do we know what the client and server implementation problems with TLS
extensions are? 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Sunday, June 04, 2006 11:41 AM
> To: [email-masked]
> Subject: Re: [Emu] Identity Protection in EAP-TLS
> 
> >Clearly using this within eap-tls would require some specification
> >work, but I think would be preferable to your approach.
> 
> The EMU WG charter states:
> "Backwards compatibility with RFC 2716 is a requirement."
> 
> So I'd like to understand which approach (if any) is backward 
> compatible 
> with existing RFC 2716 implementations.
> 
> EAP-TLS server implementations always request a certificate.  
>  If the client 
> desires privacy, it can choose not to respond to the 
> certificate request.  
> An EAP-TLS server supporting privacy would then bring up the 
> TLS channel and 
> request the certificate again, and a client supporting 
> privacy would comply. 
> However, existing EAP-TLS servers will terminate the connection if a 
> certificate is not provided in response to the first request, 
> so an uplevel 
> client talking to a downlevel server would have to choose between 
> connectivity and privacy, at least on the first attempt.  On 
> subsequent 
> attempts, the uplevel client could choose whether it is 
> willing to hand over 
> its certificate in cleartext and if so, it could connect 
> using the RFC 
> 2716-specified sequence.
> 
> The backward compatibility of the client extension approach 
> depends on the 
> server's reaction to the offering of client extensions.  
> There seems to be 
> an assumption that a downlevel server will ignore the 
> extensions and that 
> therefore the conversation would complete as in RFC 2716.  
> This would allow 
> a client supporting privacy extensions but willing to connect without 
> privacy to successfully authenticate on the first attempt.  
> However, I'm not 
> clear whether the underlying assumption of extension backward 
> compatibliity 
> is actually true or not -- as I understand it, some EAP-TLS server 
> implementations do not react well to extensions.
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Jun 2006 18:45:07 -0700

>Do we know what the client and server implementation problems with TLS 

At IETF 65, Yngve Petterson gave a presentation relating to TLS 
interoperability issues:
http://www3.ietf.org/proceedings/06mar/slides/tls-6.pdf

Slide 3 states:

Many SSL/TLS server implementations are broken with respect to forward 
compatibility:

SSLv3 servers will not talk to TLS 1.0 clients.
TLS 1.0 servers will not accept TLS extensions.
TLS 1.0 servers will not talk to TLS 1.1 clients.
TLS 1.0 servers using the wrong protocol field to negotiate version.

If anything, our own test results indicate that the problem is even worse 
than what Yngve indicates.  For example, we seen TLS 1.0 servers that cannot 
talk to TLS 1.0 clients when a ciphersuite other than RC4 (e.g. 3DES) is 
negotiated.