Subject: [Emu] Review of draft draft-ms-emu-eaptlscert-02

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Mon, 6 May 2019 16:17:01 +0530

Draft Review (draft-ms-emu-eaptlscert-02)
Title: Handling Large Certificates and Long Certificate Chains in TLS-based
EAP Methods
URL: https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 

Description: 
The draft talks about large TLS certificates with long certificate chains.
This may result in fragmentation into smaller packet as EAP fragment size is
typically is just 1000-1500 bytes. The fragmentations could cause latency
and in some cases EAP authenticator implementations may drop the EAP session
after 40-50 packets. The draft gives an overview of methods and tools for
overcoming the deployment challenges induced by large certificates.

Review: 

Section 3 talks about various reasons for a certificate being large. Subject
Alternative Name field is typically used for multi-domain or wildcard
certificates (fb.com, *.facebook.om, facebook.net, messenger.com) where all
domains are protected by same certificate. I doubt that SAN will be a reason
in IoT world for larger certificate. 

Similarly key size and signature field is in bits (e.g. 2048 bit key, 2048
bit signature, 224 bit key if ECC is used). So this also shouldn't
contribute to a larger certificate.

The same can be said about OID and user groups. Key usage is limited to
digital signature (80) [just one usage] in an end device certificate.  

Section 4.1 claims RSA key sizes and digital signature size to be 384 bytes
which is wrong. The RSA key size is 1K to 4K (1024 bit to 4096 bit)
practically and corresponding ECC key will range from 160 bits to 256 bits.
The size mentioned by the authors is the size of the entire certificate.
Authors may refer (
<https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptogr
aphy-standards/documents/presentations/session2-ford-warwick.pdf>
https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptogra
phy-standards/documents/presentations/session2-ford-warwick.pdf) for further
optimizations pertaining to ECC adoption. 

Section 4.1.1 talks about shortening or avoid certain fields in the
certificate. Mostly the changes are marginal and the authors have not
presented quantitatively, how much saving in certificate size could be
achieved with it and will it be sufficient.

Section 4.2.1 talks about pre-distributing and omitting CA certificate. It
will require constant update of CA certificates whenever new CAs are
licensed or license of existing CA is revoked. Large chain validation can be
avoided by using cross CA validation also instead of hierarchical
validation. A common certificate repository (like Google Certificate
Transparency
<https://transparencyreport.google.com/https/certificates?hl=en>
https://transparencyreport.google.com/https/certificates?hl=en) could also
be used and chain validation may not be required in this case. 

Section 4.2.2 will only work if at least one successful authentication has
occurred. If any certificate change happens (expiry, revocation, key
change), then again this method will fail.

Section 4.2.3 talks about compressing the certificate. This is achievable,
however the capability to compress, decompress and performing ECC
certificate validation within a small IoT device is questionable. 

P.S: In EAP-TLS, isn't there clear direction on how many packets exchange
are allowed before dropping EAP session. Why do some implementations drop
session after 40-50 packets itself? 

In the standard of EAP-TLS, can the no. of exchange packets be increased? If
yes, apart from latency, what other impact could it have?

Regards,

Anoop Kumar Pandey

Principal Technical Officer

C-DAC Bangalore

India

------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 May 2019 07:29:36 -0400

On May 6, 2019, at 6:47 AM, Anoop Kumar Pandey <[email-masked]> wrote:
> Section 3 talks about various reasons for a certificate being large. Subject Alternative Name field is typically used for multi-domain or wildcard certificates (fb.com, *.facebook.om, facebook.net, messenger.com) where all domains are protected by same certificate. I doubt that SAN will be a reason in IoT world for larger certificate. 

  EAP-TLS certificates are used in areas other than IoT.

> Similarly key size and signature field is in bits (e.g. 2048 bit key, 2048 bit signature, 224 bit key if ECC is used). So this also shouldn’t contribute to a larger certificate.
> 
> The same can be said about OID and user groups. Key usage is limited to digital signature (80) [just one usage] in an end device certificate.  

  No.  Key usage is in every intermediate certificate.  i.e. if we have CA1 - > CA2 - > CA3 -> certs, then all intermediate certs will have OIDs that allow them to sign subsequent certificates.

> Section 4.1.1 talks about shortening or avoid certain fields in the certificate. Mostly the changes are marginal and the authors have not presented quantitatively, how much saving in certificate size could be achieved with it and will it be sufficient.

  I agree more quantitative numbers would help here.

  The reality is that there are some organizations who treat certificates as a dumping ground for information.  Every intermediate cert has names, address, and anything else they can think of.  Then, the CA chain mirrors the corporate reporting chain.

  The result is a large certificate chain.  This happens in the real world:

http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035621.html

  ... We are testing
WPA2/EAP-TLS authentication, with large certificate chains (just under
64K in PEM format).  Some individual cert sizes in the chain approach
10K in DER format.

  The solution there was "don't use large chains".

> Section 4.2.3 talks about compressing the certificate. This is achievable, however the capability to compress, decompress and performing ECC certificate validation within a small IoT device is questionable. 

 Again, this applicability is not just for IoT.

> P.S: In EAP-TLS, isn’t there clear direction on how many packets exchange are allowed before dropping EAP session. Why do some implementations drop session after 40-50 packets itself? 

  From the above thread, Jouni Malinen (hostap / wpa_supplicant) responds:

http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035654.html

The main (well, more or less, the only) reason for that limit on
number of round trips is to work around issues where the EAP peer and
server ended up in an infinite loop ACKing their messages. I would
prefer to change that to be based on whether any real progress has
been made during the last round trip or two, i.e., to remove the hard
limit and allow as many round trips as it takes to get through the
authentication (or whatever else one adds into EAP, e.g., TNC)

  10 years later, the implementation still just counts exchanges.  It's fine, it works.

  And additional reason to forbid longer exchanges is that it could potentially be used for bulk data transfer.  If the exchange is unlimited, then a client and home server can collude to "tunnel" generic IP traffic over EAP.

  But the biggest reason to limit the exchanges is that there is simply no reason to allow them.  Even in the above situation (64K certificate chain), there's no *technical* reason for such large chains.

> In the standard of EAP-TLS, can the no. of exchange packets be increased? If yes, apart from latency, what other impact could it have?

  Realistically, it can't be increased.  There are probably tens of millions of access points and switches in production.  They are the de-facto standard.  If you publish a new RFC saying "allow up to 128 packets", it won't affect those legacy devices.  The new standard *might* start showing up in new devices, once the standard is published.  Or it might not.  I've seen standards take 10+ years to *start* getting adopted.

  Allowing more packets wouldn't generally increase latency, because 99.99999999% of authentications won't need more packets.

  And realistically, if you can't authenticate someone after exchanging 50K of data, you're likely doing something wrong.

  Alan DeKok.

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Wed, 8 May 2019 16:46:40 +0530

> The reality is that there are some organizations who treat certificates as a dumping ground for information.

3 Tier chained certificate with organization validated certificate in DER encoded Binary mode has a size of just 1588 byte (1.55 KB) [Attached].  It has a lot of Information including SANs and OIDs. 

You need to show quantitatively with example the effect of the fields that are responsible for the larger certificate.
(Cross certification and certificate transparency could also help in keeping the chain small or irrelevant)

 >Again, this applicability is not just for IoT.

The applicability may not be <just> for IoT but may <also> be for IoT and in that case for EAP-TLS to work with certificate compression and ECC, the device should have such capability. 

>The main (well, more or less, the only) reason for that limit on number of round trips is to work around issues where the EAP peer and server ended up in an infinite loop ACKing their messages. I would prefer to change that to be based on whether any real progress has been made during the last round trip or two, i.e., to remove the hard limit and allow as many round trips as it takes to get through the authentication (or whatever else one adds into EAP, e.g., TNC)

> 10 years later, the implementation still just counts exchanges.  It's fine, it works.

Agreed

>And additional reason to forbid longer exchanges is that it could potentially be used for bulk data transfer.  If the exchange is unlimited, then a client and home server can collude to "tunnel" gen…

The protocol designer need to take care of such situation.

>But the biggest reason to limit the exchanges is that there is simply no reason to allow them.  Even in the above situation (64K certificate chain), there's no *technical* reason for such large chai…

Practically large chain certificates are there (though I still haven't come across a 64K certificate), so we can't ignore them. Guidelines can be provided for limiting the information as mentioned in the draft section 4.1.1

 >>Realistically, it can't be increased.  There are probably tens of millions of access points and switches in production.  They are the de-facto standard.  If you publish a new RFC saying "allow up…

This limitation would be with any protocol. If we ask everyone to use ECC or certificate caching or certificate compression, that will also take time. Or if the customer insists or reports, OEM will have to provide firmware upgrade or device replacement with new protocol implemented. 

Regards,
Anoop

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: 06 May 2019 05:00 PM
To: Anoop Kumar Pandey <[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02

  ... We are testing
WPA2/EAP-TLS authentication, with large certificate chains (just under 64K in PEM format).  Some individual cert sizes in the chain approach 10K in DER format.

The main (well, more or less, the only) reason for that limit on number of round trips is to work around issues where the EAP peer and server ended up in an infinite loop ACKing their messages. I would prefer to change that to be based on whether any real progress has been made during the last round trip or two, i.e., to remove the hard limit and allow as many round trips as it takes to get through the authentication (or whatever else one adds into EAP, e.g., TNC)

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 May 2019 08:20:41 -0400

> You need to show quantitatively with example the effect of the fields that are responsible for the larger certificate.

  I did.  64K certificate chains contain large certs.  Which fields contribute to that size is less important.

  If you really care, it's trivial to dump large strings into a certificate.  1K octet email addresses aren't *technically* forbidden.  Similar arguments go for physical addresses.

  The point here is that no, I *don't* have to quantitatively demonstrate which fields are responsible for larger certificates.  The specs don't forbid large values in any field, so therefore the fields can contain large values.  QED.

  My argument is that we need to explain to administrators *why* such practices are wrong.  Right now, admins who have poor practices discover that the certificates don't work, for unknown reasons.  So to fix it, people poke at the certs until they work.

  I'm suggesting that explicit guidance is better than random guesses.

> The protocol designer need to take care of such situation.

  They didn't.  Therefore, the implementors chose to enforce a limit.  And that limit is 40-50 packets.

  We now have to live with that, and bake it into the spec as best practices for "here's what will work".

> This limitation would be with any protocol. If we ask everyone to use ECC or certificate caching or certificate compression, that will also take time.

  These are upgrades to end user devices.

> Or if the customer insists or reports, OEM will have to provide firmware upgrade or device replacement with new protocol implemented. 

  Those are upgrades to WiFi access points and switches.

  There are tens of millions, if not hundreds of millions of WiFi access points out there.  For many, the vendor is out of business.  For others, the vendor no longer supports that product, maybe due to losing the source.  For others, the admins don't know the passwords to the devices.  For most, admins don't have the time, budget, or inclination to upgrade our replace them when the devices already work.

  I'm not sure what the disagreement is here.  I'm saying that the practical limits are ~50 round trips, and maybe ~64K certificate chains.  You're not disagreeing, but you're asking me to justify my position, and are arguing against it.  I'm not clear what point you're trying to make.

  Alan DeKok.