Subject: [Emu] WGLC for draft-ietf-emu-eaptlscert (corrected)

From: Joseph Salowey <[email-masked]>
Date: Sun, 1 Mar 2020 21:46:58 -0800

Hi Folks,

This is the working group last call for the "Large Certificates in
TLS-based EAP Methods" draft available at
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ (
https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-00). Please review
the document and send your comments to the list by 2359 UTC on 16 March
2020.

Note the draft has expired, the authors will resubmit after this call to
address any comments and refresh the draft.  The GH repo for this draft can
be found at: https://github.com/emu-wg/eaptls-longcert.

Thanks,

Joe

---

From: Alan DeKok <[email-masked]>
Date: Mon, 2 Mar 2020 08:32:34 -0500

My $0.02 of nits:

1. 

	... Also,
   from deployment experience, EAP peers typically have longer
   certificate chains than servers.  ...

  It may be good to explain why?

	... Therefore, EAP-TLS authentication
   usually involve significantly more bytes than when TLS is used as
   part of HTTPS. ...

  suggest "data" or "octets" instead of "bytes".  And elsewhere in the document.

	... As the EAP fragment size in typical deployments are just 1000 - 1500
   bytes, ...

  RFC 3748 Section 4 says that the minimum MTU is 1020 octets.  It would be good to make this text agree with RCC 3748.  There are multiple such uses in the document.

  It may be worth mentioning that some implementations support EAP over Ethernet "Jumbo" frames.  i.e. 8-9K.  Larger packets will help lower the number of round trips.  However, deployment shows that these jumbo frames are not always implemented correctly (I've run into this in the field).  Also, EAP is typically transported over RADIUS, which can generally transport only a bit under 4K of EAP data.

  ... or example, many EAP authenticator
   (access point) implementations will drop an EAP session if it hasn't ...

 nit: avoid contractions here, and elsewhere in the document.

2.
	... 
   Readers are expected to be familiar with the terms and concepts used
   in EAP-TLS [RFC5216] and TLS [RFC8446].

  suggest: adding EAP [RFC3748]

	...    Can contain multiple object identifiers (OID) that indicate the
      permitted uses of the certificate.  For example, Windows requires
      certain OID's in the certificates for EAP-TLS to work...

  Suggest referencing RFC 5216 5.3 instead of "Windows", and perhaps adding a note that these checks are widely implemented, and enforced.

  It would be good to add a section 4.2.5, "using fewer intermediate certificates".

  I've seen situations where there are many, many, intermediate certificates.  The reasons are generally that the certificate chain mirrors the organizational hierarchy of the business which is using it.  Such organizations also tend to fill each certificate field with large amounts of information, further bloating the certificate chain.

  It would be good to note that the certificate chains do *not* have to mirror the hierarchy of the organization.

  It would be good to note that most certificate chains should be 2-4 certs, and that there are few good reasons for using more than 6.

  It may be good to add a section 4.2.6 "putting less information into each certificate".  See comments above.

  There are few good reasons to put full postal addresses into every intermediate cert.  When a company needs 6 certs to match their organizational hierarchy, those intermediate certs could just use "Department 42, Building 6" instead of a full postal / street address.

  i.e. the certs should contain sufficient information to determine who issued them, and how to contact the issuer.  This information is often site-specific, and can use site-specific terms.  The site-specific information does *not* need to be understandable by random members of the general public.

4.3
	...  Vendors making new authenticators should consider increasing the
   number of round-trips allowed before denying the EAP authentication
   to complete....

  Is there a suggestion here?  Should this number be configurable?

  i.e FreeRADIUS hard-codes this number to 50, and it is not configurable.  wpa_supplicant hard-codes this to 100 (it was 40-50 for quite a while).  wpa_supplicant allows it to be changed at compile time, but it is not configurable.   I took quick look at "iwd", and I can't find any limits there.  Which seems wrong.

  It would be good to suggest that EAP peers examine their certificate chains, and make rough calculations as to how many round trips will be required.  e.g. take the total length of all certs, and divide by 1020.  That is the *mimimum* number of round trips required to do a full certificate exchange.  EAP peers MUST allow at least that many round trips, otherwise authentication will be impossible.

  Perhaps suggest EAP implementations use an upper limit of 100.  And then explain that the limit should not be exceeded, either in practice, or in future standards.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 5 Mar 2020 15:08:27 +0000

Hi Alan,

Thanks for your careful and detailed reviews. They are extremely helpful. We have submitted a new version addressing your feedback.

Please see in-line for specific actions taken. Here you can see the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-01.

--Mohit

On 3/2/20 3:32 PM, Alan DeKok wrote:

  My $0.02 of nits:

1.

        ... Also,

Added info that peer chain often reflects organizational hierarchy.

Changed to octects everywhere except when describing the key lengths of RSA, ECC, etc.

Fixed all of them.

Added. Thanks again for your valuable deployment experience and insight.

Makes sense. I think I removed all occurrences.

2.
        ...

Added.

Fixed as suggested.

Added a new subsection.

I added this info to the existing subsection on "Guidelines for certificates".

4.3

Added text :

   Administrators responsible for deployments using TLS-based EAP
   methods can examine the certificate chains and make rough
   calculations about the number of round trips required for successful
   authentication.  For example, dividing the total size of all the
   certificates in the peer and server certificate chain by 1020 will
   indicate the minimum number of round trips required.  If this number
   exceeds 50, then, administrators can expect failures with many common
   authenticator implementations.

and

At the same time, administrators
   responsible for EAP deployments should ensure that this 100 roundtrip
   limit is not exceeded in practice.

Mohit, John, and Sean.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu