On Nov 14, 2018, at 9:04 AM, John Mattsson <john.matts...@ericsson.com> wrote: > draft-ietf-emu-eap-tls13-03 adds: > > "The use of Certificate Status Requests to determine the current status of > the EAP server's certificate is RECOMMENDED."
I think that's good. > For EAP-TLS where the peer often does not have internet connection OCSP > stapling is often by far the most appropriate mechanism. Is it time to make > Certificate Status Requests (OCSP stapling) mandatory to implement for > EAP-TLS with TLS 1.3? > > My view would be yes, OSCP stapling is solving a lot of issues with > revocation, especially for EAP-TLS. I think OCSP stapling should be mandatory > to support and maybe also mandatory to use... I don't see major issues with it. > - Fragmentation due to large certificates > ------------------------------------------------------ > > draft-ietf-emu-eap-tls13-03 says: > > "EAP-TLS peers and servers SHOULD support and use the Cached Information > Extension as specified in [RFC7924]." > > draft-ms-emu-eaptlscert-01 says: > > "The extension however necessitates a successful full handshake before any > caching. This extension can be useful when, for example, when a successful > authentication between an EAP peer and EAP server has occurred in the home > network." > > As fragmentation of large certificates is a large problem in EAP-TLS > deployments, would it make sense to mandate support and or use of RFC 7924 > when TLS 1.3 is used? I would tend to agree. The only caveat is that RFC 7924 requires the completion of a full certificate exchange before caching can take place. This requirement means that the handshake may not, in fact, complete, unless some other mechanism enables it. The alternative is for the full handshake to work in one location, and then when a user moves locations and the certs change, it becomes impossible to authenticate. For some systems, the cached certificates can be pre-provisioned. That means the full handshake is always avoided. > Also, in IETF 102 we discussed cached information and the possibility for the > client to cache the server's certificate from a dropped handshake. I though > more about this and I cannot see any cryptographic problems with the client > caching the server's certificate from a dropped handshake. The client can > verify the certificate anyway, but the server may not have time to prove > possession of the private key before the handshake is dropped. Getting > certificates out-of-band is common in many cases. The only problem I can see > is that an attacker could try to fill the peer's memory storage by sending > certificates to the client, but this does not give any amplification and > could easily be mitigated by the client only caching a single or very few > certificates. That concern can be mitigated by requiring a short lifetime for certs cached due to partial handshakes. e.g. minutes, not days. And, ensuring that the total number of certificates cached per site is limited to a small number, like 16. > As fragmentation of large certificates is a large problem in EAP-TLS, my view > would be that we should specify that the peer can cache certificates from a > dropped handshake. With this change is it likely almost always possible to do > EAP-TLS even if the authenticator drops the connection after 40-50 packages. > If we decide to do this, we should tell the TLS working group that we are > planning this and ask for their view. My larger worry is that underlying SSL implementations may not support caching of certs from dropped handshakes. It may be hard to add features to SSL libraries which are used only by EAP-TLS. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
