Hi Joe, a few remarks below.
On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: Hi Joe, I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS. [Joe] TLS 1.3 discusses OCSP and (SCT). OCSP stapling is a revocation mechanism that will work when the EAP-TLS client does not have connectivity yet, which is a common case in EAP-TLS deployments. The way the draft is written now it mandates that this mechanism be used and implements. TLS 1.3 does not require this. [hannes] It is also common to give network access to devices that need a software update or configuration changes. What do you expect to happen if the device finds out that the certificate offered by the server has expired? If this topic is important to the group then why isn’t this a generic recommendations for all EAP methods that use public key based authentication? [Joe] Certificate revocation is specific to the use of certificates. [Hannes] Many EAP methods use certificates but they do not mandate the use of OCSP. Wouldn’t this be a topic to address in <draft-ietf-emu-eaptlscert>? IMHO this would make more sense given that <draft-ietf-emu-eaptlscert> talks about large certificates and long certificate chains and any proposal to make those even larger should be evaluated in this context. [Joe] No, <draft-ietf-emu-eaptlscert> discusses handling large certificates not revocation. [Hannes] Here the problem description that motivates <draft-ietf-emu-eaptlscert> “ Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round-trips is a major deployment problem. This document looks at the this problem in detail and describes the potential solutions available. “ OCSP information travels alongside the certificates and therefore increases the problem outlined by <draft-ietf-emu-eaptlscert> EAP-TLS is the right place to discuss revocation issues. It seems there are several questions that need to be answered: 1. Should the document mandate that OCSP stapling be used? [Hannes] No. 2. Should the document mandate that OCSP stapling be implemented? [Hannes] No. 3. What should the document say in the security sections with respect to OCSP stapling and other mechanisms? [Hannes] IMHO TLS 1.3 says the relevant solution parts. OCSP stapling is available for use in TLS 1.3 and it is one suitable mechanism for certificate revocation. Do any of these recommendations also apply to EAP-TLS with TLS 1.2 as well (since it also offers OCSP stapling)? Would the recommendations also apply to EAP methods that use TLS under the hood, such as TEAP, EAP-FAST, or EAP-TTLS? Would they apply to methods like EAP-IKEv2 or the recently suggested EAP-EDHOC, which are also methods that use certificates? Ciao Hannes Ciao Hannes From: Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> Sent: Thursday, October 22, 2020 11:12 PM To: Eliot Lear <lear=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> Cc: Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear <lear=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: +1. How does anyone even do OCSP without having first gotten onto the network? [Joe] THat is what OCSP stapling is supposed to solve since the OCSP messages are sent in the TLS handshake. I believe there are some EAP-TLS implementations that support OCSP, but I am not sure if it is actually deployed. Eliot On 21 Oct 2020, at 11:02, Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: Hi all, this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I believe this is a problem for implementations. This extra burden is IMHO unjustified. For the type of deployments where EAP is used there is no need for a mandatory certificate revocation checking with OCSP. Having it optional, like the use of many other TLS extensions, is fine for me. FWIW even TLS 1.3, which is used in a more generic environment, does not mandate the use of OCSP stapling. This requirement will make the problem described in draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this fact since they are also co-authors of draft-ietf-emu-eaptlscert. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
