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.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
