[Emu] EAP TLS with large certificates and long certificate chains

[Mohit Sethi]

Dear all,

A few of us would be participating in the IETF hackathon. We plan to 
test EAP-TLS implementations with large certificates and long 
certificate chains. We will use open source wpa_supplicant/hostapd 
implementations and we will have a D-Link enterprise access point 
available on-site.


Our goal is to collect statistics of EAP-TLS authentication with 
different types of certificates and certificate chains. This would serve 
as input to the EAP Method Update (EMU) working group which has recently 
been re-chartered: https://datatracker.ietf.org/wg/emu/charter/


We look forward to your contributions. The project description is also 
available in the hackathon wiki:
https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon 



--Mohit

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-TLS with large certificates

[Jim Schaad]

There are already a couple of things in TLS 1.3 that can be used to address 
some of these issues

 

From: Emu [mailto:emu-boun...@ietf.org] On Behalf Of Bernard Aboba
Sent: Friday, January 19, 2018 9:46 AM
To: emu@ietf.org
Subject: Re: [Emu] EAP-TLS with large certificates

 

Alan DeKok said: 

 

" It may also be worth re-examining EAP-TLS. Modern certificates are getting 
large, and people are using longer certificate chains. The result can be that 
initial EAP-TLS authentication takes many packets. This has issues not just for 
latency, but also access point implementations. Most implementations will drop 
an EAP session if it hasn't finished after 40-50 packets.

  I've seen people run into this issue with large certificates and long 
certificate chains. It would be good to find a way to allow this use-case."

 

[BA] I have encountered this problem in a number of situations, particularly in 
enterprise deployments with several levels of intermediate CAs.  Since the 
certificate hierarchy is relatively static, this seems like a problem that 
could be addressed via caching. 

 

[JLS] There is already a way to say that you have a specific set of 
certificates and CRLs  in RFC 7924 – TLS Cached Information Extension.  There 
is also a new TLS 1.3 extension that is being looked at for compressions of 
certificates.  This seems to get some decent compressions, but it is still up 
in the air just how good it is going to be.

 

For example, if client A has previously authenticated to server B and has 
cached the certificate chain, why does it need to be transmitted again? 
Similarly, if server B has already cached certificates from intermediate CAs, 
why does the client need to transmit that information again? 

 

Seems like this could be addressed by a small extension to TLS. 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu