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, from deployment experience, EAP peers typically have longer certificate chains than servers. ... It may be good to explain why? Added info that peer chain often reflects organizational hierarchy. ... 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. Changed to octects everywhere except when describing the key lengths of RSA, ECC, etc. ... 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. Fixed all of them. 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. Added. Thanks again for your valuable deployment experience and insight. ... 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. Makes sense. I think I removed all occurrences. 2. ... Readers are expected to be familiar with the terms and concepts used in EAP-TLS [RFC5216] and TLS [RFC8446]. suggest: adding EAP [RFC3748] Added. ... 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. Fixed as suggested. 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. Added a new subsection. 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 added this info to the existing subsection on "Guidelines for certificates". 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. 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 Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
