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

["Anoop Kumar Pandey" <[e-mail]>]

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


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

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" generic IP traffic over EAP.

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

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

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:[e-mail]] 
Sent: 06 May 2019 05:00 PM
To: Anoop Kumar Pandey <[e-mail]>
Cc: [e-mail]
Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02

On May 6, 2019, at 6:47 AM, Anoop Kumar Pandey <[e-mail]> 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.



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