Dear all, Sorry for the radio silence. I have over-committed myself to too many things. I think I have now read the entire discussion on OCSP.
EAP-TLS with TLS 1.3 is a working group document so the text will reflect whatever the working group wants. The authors and contributors are at the service of the working group. Obviously it is easy for us to simply change all MUSTs to MAYs, make everyone happy, and hand over the document to the IESG. Yet, I think as a conscientious security person and individual contributor, I am saddened by the discussion thus far. To begin with, I assume that everyone knows the difference between OCSP and OCSP stapling. I also hope that everyone has read RFC 5216 (the previous EAP-TLS specification). In particular I hope that the working group has actually read section 5.4 on "Certificate Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the relevant text here for your convenience: EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs); for details, see Section 3.3 of [RFC3280]<https://tools.ietf.org/html/rfc3280#section-3.3>. EAP-TLS peer and server implementations SHOULD also support the Online Certificate Status Protocol (OCSP), described in "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" [RFC2560<https://tools.ietf.org/html/rfc2560>]. OCSP messages are typically much smaller than CRLs, which can shorten connection times especially in bandwidth-constrained environments. and For this reason, EAP-TLS peers and servers SHOULD implement Certificate Status Request messages, as described in "Transport Layer Security (TLS) Extensions", Section 3.6 of [RFC4366]<https://tools.ietf.org/html/rfc4366#section-3.6>. To enable revocation checking in situations where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default. So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was published. And now 12/13 years later, some people in the working group are suggesting to make the security stance weaker. For what? Some speculative insecure future deployments? Please note that EAP-TLS is currently implemented in billions of devices and used in many high security deployments. It is very surprising to see Hannes wanting to water down security and get rid of the text on OCSP. He wrote "I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you see, RFC 5216 has quite detailed guidelines on certificate revocation checking with CRLs and OCSP so I don't see any sensible reason on why an update to it should not contain relevant text. Michael wrote " we are under no additional compulsion to support revocation than we were before." Do you see the problem here given the text in RFC 5216 shown above? While Elliot and Hannes have been vocal about their views, we also saw feedback from Janfred explaining the situation without OCSP in a live network like eduroam: https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends his email with All in all, I definitely think that making OCSP Stapling optional will have a benefit on small devices, but especially for the diverse environment of eduroam, making OCSP Stapling mandatory will increase the overall security of this federation. Maybe it might be a good idea to make OCSP Stapling mandatory for EAP-TLS Servers? So where we are with the current draft. The current draft (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4) says, "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation status of the certificates in the client's certificate chain.". It doesn't mandate any specific technique. You are free to use whatever propriety (potentially insecure) method you want. The revocation checking could use the following pseudocode for checking the revocation status of client certificates: fun check_revocation { return success; } and you would comply with specification. Naturally, using CRLs or locally-configured OCSP responder on the server (for revocation checking of client certificates) will get you better security. The current text in the draft does mandate OCSP stapling for clients to verify the revocation status of server certificates. Given the resistance in the working group, I think it is a reasonable compromise for servers to implement OCSP stapling. Clients can implement and use it, but they would be compliant even if they don't. So the updated text would be (as Joe wrote in his email): EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use Certificate Status Requests for the server's certificate chain and it MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert. Note that this is also compliant with the NIST SP 800-52 Rev. 2. --Mohit
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
