Subject: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Oct 2020 09:02:55 +0000

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.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Oct 2020 09:38:17 -0400

> 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.

  I agree.  It should be fine to make OCSP stapling optional.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Oct 2020 12:45:51 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > 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.

Is it:
   1) there is no need for mandatory certificate revocation checking
   2) there is no need to make OCSP checking the mandatory method for certificate revocation checking

Are you objecting to:
   a) mandatory certificate revocation checking
   b) mandatory OCSP
   c) mandatory OCSP *stapling* when using OCSP

I think, if you the client (who has no Internet yet), is going to be able to
do certificate revocation checking, then doing it via OCSP stapling is the
right way to go.  It can't do ONLINE CSP, because it has no Internet.

    > 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.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Oct 2020 07:35:03 +0000

Hi Michael,

Thanks for the question. I am objecting to the mandatory use of OCSP for TLS 1.3 in EAP-TLS.
I am fine with having it optional.

Mbed TLS is used in implementations of EAP-TLS and we have received little interest in OCSP support. The interest is so low that the proposed code was never merged.

Companies seem to use an alternative approach instead, namely to change certificates via a device management solution. After all, you will have to offer a solution anyway. You cannot just reject access to your backend authentication infrastructure and do nothing.

Do other EAP methods rely on OCSP?

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Wednesday, October 21, 2020 6:46 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

Is it:

Are you objecting to:

I think, if you the client (who has no Internet yet), is going to be able to do certificate revocation checking, then doing it via OCSP stapling is the right way to go.  It can't do ONLINE CSP, because it has no Internet.

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Thu, 22 Oct 2020 11:29:58 +0200

Hi to all,

as an operator of a EAP-TLS server for eduroam at the University Bremen
I just want to give some of my thoughts here, feel free to read or
ignore them ;)

The eduroam environment is heavily used for BYOD, so we don't have any
opportunity to change certificates via a Device Management.
Our clients are researchers, employees, students, ... so we can't (and
won't) control all devices logging in to our network.
We have to use either a private CA (which brings its own problems) or we
use a public trust anchor (e.g. T-Telesec with the DFN-Intermediate for
most German universities).
The deployment is done either manually by the users or with help of
tools like eduroam CAT (cat.eduroam.org).

I have done some research regarding the revocation of certificates in
EAP-TLS and have come to the conclusion that, if a private key gets
compromised, we have no possibility to effectively revoke the
certificate in a way the clients would notice.

This is the result of different problems:

* Clients don't support OCSP Stapling
The only client platform with default OCSP Stapling enabled in the
Client Hello (that I'm aware of) is currently Apple devices.

* Servers don't support OCSP Stapling
FreeRADIUS 3.0 does not support OCSP Stapling (but FreeRADIUS 4.0 will
have support for it)
This is probably the software mostly used for eduroam.

* Clients don't support the MustStaple Certificate extension
I don't have enough knowledge about TLSv1.3 yet, but for <=TLSv1.2 OCSP
won't add much security, since the OCSP Stapling is not mandatory.
I will look into TLSv1.3 and MustStaple in near future, maybe someone
can give me a hint if MustStaple is also active for TLSv1.3?

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?

Greetings
Janfred

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Oct 2020 17:08:23 +0200

+1.  How does anyone even do OCSP without having first gotten onto the network?

Eliot

> On 21 Oct 2020, at 11:02, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all, 
>  
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Oct 2020 17:02:48 -0400

> I am fine with having it optional.

okay, so it's not about the stapling, at all for you, it's about the OCSP itself.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 22 Oct 2020 14:12:06 -0700

> +1.  How does anyone even do OCSP without having first gotten onto the
[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.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Oct 2020 20:13:43 -0400

> implementations that support OCSP, but I am not sure if it is actually

I think that it should say, if you do OCSP, then you must staple.
But, the intro suggests that revocation checking is mandatory with TLS 1.3.
(I didn't double check if that's MUST, SHOULD, or what)

Since CRLs won't be fresh and can't be retrieved until online, then it seems
that OCSP is needed if one is going to revocation checking.

What I read in section 5.4 is that servers have to support OCSP stapling
requests.  I see a tiny bit of wiggle room as to whether the peer actually
must USE it :-)
Maybe that wiggle room can be made official for Hannes.

The document currently says: (1.0)

   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and simplified with OCSP stapling,

and:

5.4.  Certificate Revocation

   This section updates Section 5.4 of [RFC5216].

   While certificates may have long validity periods, there are a number
   of reasons (e.g. key compromise, CA compromise, privilege withdrawn,
   etc.) why client, server, or sub-CA certificates have to be revoked
   before their expiry date.  Revocation of the EAP server's certificate
   is complicated by the fact that the EAP peer may not have Internet
   connectivity until authentication completes.

   EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
   Status Requests (OCSP stapling) as specified in [RFC6066] and
   Section 4.4.2.1 of [RFC8446].  When EAP-TLS is used with TLS 1.3, the
   peer and server MUST use Certificate Status Requests [RFC6066] for
   the server's certificate chain and the EAP peer MUST treat a
   CertificateEntry (except the trust anchor) without a valid
   CertificateStatus extension as invalid and abort the handshake with
   an appropriate alert.  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.

   The OCSP status handling in TLS 1.3 is different from earlier
   versions of TLS, see Section 4.4.2.1 of [RFC8446].  In TLS 1.3 the
   OCSP information is carried in the CertificateEntry containing the
   associated certificate instead of a separate CertificateStatus
   message as in [RFC4366].  This enables sending OCSP information for
   all certificates in the certificate chain.

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Oct 2020 08:24:48 +0200

So I’m a client and include a certificate status request.  The EAP server isn’t talking to the CA at the moment.  Does a nonce have to be used?  If so… #fail.  If not, what prevents a replay?  And if the answer is nothing, what is the threat model we are addressing?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Oct 2020 07:37:56 +0000

Hi Joe,

I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS.

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?

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.

Ciao
Hannes

From: Joseph Salowey <[email-masked]>
Sent: Thursday, October 22, 2020 11:12 PM
To: Eliot Lear <lear=[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear <lear=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 23 Oct 2020 08:54:05 -0400

> I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS.

  It's not.

  However, in the absence of another specification, we need to say *something* for EAP-TLS.

> 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?

  I believe it should be.  I can update draft-ietf-emu-tls-eap-types to clarify this.  Basically "almost everything else in EAP-TLS applies to all other TLS-based EAP types, too".

> 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…

  I think that the topics are related.  But draft-ietf-emu-eap-tls13 is more about the protocol, and draft-ietf-emu-eaptlscert is more about deployment considerations.

  For me, this means that security issues such as certificate revocation checking belong in the protocol specification, not in a deployment guide.

  Alan DeKok.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Oct 2020 09:33:50 +0000

Hi Alan,

>  However, in the absence of another specification, we need to say *something* for EAP-TLS.

Why doesn't the group write that other document? There are several other EAP methods that use certificates as well.

>  I think that the topics are related.  But draft-ietf-emu-eap-tls13 is more about the protocol, and draft-ietf-emu-eaptlscert is more about deployment considerations.

The scope of draft-ietf-emu-eaptlscert is whatever you want it to be. Currently, it is a mixture of deployment suggestions and the use of TLS extensions.
Maybe that scope is wrong but has probably grown organically.

Ciao
Hannes

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 27 Oct 2020 10:48:58 -0700

> 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.

> 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.

> 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.  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?
2. Should the document mandate that OCSP stapling be implemented?
3. What should the document say in the security sections with respect to
OCSP stapling and other mechanisms?

> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey <[email-masked]>
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear <lear=[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; [email-masked]
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear <lear=
> [email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Oct 2020 18:27:07 +0000

Hi Joe,

a few remarks below.

On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joe,

[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?

[Hannes] Many EAP methods use certificates but they do not mandate the use of OCSP.

[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.

[Hannes] No.

[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 <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 22, 2020 11:12 PM
To: Eliot Lear <lear=[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

Eliot

Hi all,

Ciao
Hannes

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 27 Oct 2020 11:53:22 -0700

On Tue, Oct 27, 2020 at 11:27 AM Hannes Tschofenig <
[email-masked]> wrote:

> [hannes] It is also common to give network access to devices that need a
> software update or configuration changes.
>
>
>
[Joe] If the server is offering an expired or revoked certificate then that
needs to be remedied on the server.

> OCSP information travels alongside the certificates and therefore
> increases the problem outlined by <draft-ietf-emu-eaptlscert>
>
>
>
> [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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Oct 2020 19:10:11 +0000

Hi Joe,

Thanks for the quick response.

[Joe] If the server is offering an expired or revoked certificate then that needs to be remedied on the server.

Where do you believe the value of OCSP comes into the picture for this EAP-TLS use case and what actions need to be taken when a notification of a revoked/expired certificate shows up?

[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.

draft-ietf-emu-eap-tls13 also makes changes to TLS 1.2 in EAP-TLS. It updates the content of the original RFC. This was surprising to me as well.
In that spirit it wouldn’t be unnatural to also require OCSP there and to apply that to all EAP methods that use TLS.

Note that I am not recommending it but it shows the inconsistency in the approach being taken today.

Ciao
Hannes