On Tue, Oct 27, 2020 at 11:27 AM Hannes Tschofenig < hannes.tschofe...@arm.com> wrote:
> Hi Joe, > > > > a few remarks below. > > > > > > On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig < > 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? > > > [Joe] If the server is offering an expired or revoked certificate then that needs to be remedied on the server. > > > 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? > [Joe] the document under consideration is EAP-TLS 1.3. In my opinion any document that deals with certificates ought to have some discussion on revocation. In particular, EAP is deployed into an environment where some revocation mechanisms may not work as expected because there is no network access available to do out of band checks. > > > Ciao > > Hannes > > > > Ciao > > Hannes > > > > *From:* Joseph Salowey <j...@salowey.net> > *Sent:* Thursday, October 22, 2020 11:12 PM > *To:* Eliot Lear <lear=40cisco....@dmarc.ietf.org> > *Cc:* Hannes Tschofenig <hannes.tschofe...@arm.com>; 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> 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> > 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 > https://www.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > 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
