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

From: John Mattsson <[email-masked]>
Date: Mon, 26 Oct 2020 12:08:26 +0000

Hi,

When this was discussed in the group, it was decided to not only mandate revocation checking, but to also mandate OCSP stapling as is it often the only viable solution to let an offline peer check the revocation status of the server. We had a discussion on must-staple, and the decision was to mandate stapling in the draft instead of waiting for support of the X.509 must-staple extension. OCSP and OCSP stapling are quite well supported already and should be even more well-supported in a few years:

1. Basically all TLS implementations support OSCP, and a majority support OSCP stapling (Certificate Status Request). Mbed is an exception rather than the rule.

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

2. All browsers (desktop and mobile) support OCSP stapling.

https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).

3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the Certificate Status Request extension (i.e. OCSP stapling).

- I do not think there is any wiggle room at all in the current version of the draft:

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

  Note that in the current draft it is unspecified how the server checks the revocation status of the client's certificate:
  
  "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 X.509 must-staple extension (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant for server certificates in the current EAP-TLS 1.3 draft as stapling is already a must. OSCP stapling is not very useful for client certs. I do not know if the X.509 must-staple extension is well supported or not. It could become relevant for server certs if the requirements are softened.

- My view is that OSCP stapling is a very good fit for EAP in particular and is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 from the start avoids having to rely on the X.509 must-staple extension. Any implementation not supporting OCSP stapling should implement it together with TLS 1.3. I do not think the requirent should be softened, but if it is, my view is that is should be softened as little as possible.

Cheers,
John

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 13:16:00 +0100

Hi John,

My question is one of pragmatics.  In an offline industrial environment, what is expected of the server to accomplish the stapling?  Especially if the request is nonced.

Eliot

> On 26 Oct 2020, at 13:08, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: John Mattsson <[email-masked]>
Date: Mon, 26 Oct 2020 12:58:00 +0000

Hi Eliot,

The EAP server is expected to frequently request a OCSP response from the OCSP responder (a server typically run by the certificate issuer). The OCSP response is then added to the Servers Certificate message as long as it is valid. Before the OCSP response is close to expiring, the EAP server requests a new OCSP response from the OCSP responder.

I assume you mean the client is offline? If use cases where none of the entities can contact the OCSP responder is in scope, OCSP stapling does not work.

OCSP Nonce does not work with OCSP stapling. If you want you revocation data to be real-time you need to make an online OCSP request-response to the OCSP responder.

John

-----Original Message-----
From: Eliot Lear <lear=[email-masked]>
Date: Monday, 26 October 2020 at 13:16
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

Hi John,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 14:42:41 +0100

Thanks, John.  Please see below:

> On 26 Oct 2020, at 13:58, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi Eliot,
> 

Right.  What this is saying is that a local deployment MUST run an OCSP responder.  If that OCSP responder is unavailable, then what?  Now imagine we are discussing critical infrastructure where the responder is not in the same room, and there are network connectivity problems.  The device joining the network needs local access and that is it.  Does that mean it should not use EAP-TLS?  Or are we saying that they MUST use naked public keys?

> I assume you mean the client is offline? If use cases where none of the entities can contact the OCSP responder is in scope, OCSP stapling does not work.

Right.  So then what?  Fail?

For many devices the manufacturers will be unable to predict whether a device will or will not have direct access to anything.  It specific to deployment circumstances.  Also, running an OCSP server is something that will be very new for many enterprises.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2020 10:06:25 -0400

John Mattsson <john.mattsson=[email-masked]> wrote:
    > 1. Basically all TLS implementations support OSCP, and a majority
    > support OSCP stapling (Certificate Status Request). Mbed is an
    > exception rather than the rule.

Is this for server and client certificates, or just server certificates?
It seems that getting the client certificate staple would be difficult for
offline clients :-)

    > https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

Also, consider that an mbedtls EAP client could just not process the OCSP+Staple
for now.  That would be non-compliant, but it would work.
(The opposite for the server is not the case)

    > 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of
    > the Certificate Status Request extension (i.e. OCSP stapling).

    > Note that in the current draft it is unspecified how the server checks
    > the revocation status of the client's certificate:

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

So, OCSP would comply work, but insisting on stapling would be dumb.

    > - My view is that OSCP stapling is a very good fit for EAP in
    > particular and is well-supported enough to be mandated. Mandating
    > stapling for EAP-TLS 1.3 from the start avoids having to rely on the
    > X.509 must-staple extension. Any implementation not supporting OCSP
    > stapling should implement it together with TLS 1.3. I do not think the
    > requirent should be softened, but if it is, my view is that is should
    > be softened as little as possible.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2020 10:19:54 -0400

Eliot Lear <lear=[email-masked]> wrote:
    >> The EAP server is expected to frequently request a OCSP response from
    >>the OCSP responder (a server typically run by the certificate
    >>issuer). The OCSP response is then added to the Servers Certificate
    >>message as long as it is valid. Before the OCSP response is close to
    >>expiring, the EAP server requests a new OCSP response from the OCSP
    >>responder.

    > Right.  What this is saying is that a local deployment MUST run an OCSP
    > responder.  If that OCSP responder is unavailable, then what?  Now
    > imagine we are discussing critical infrastructure where the responder
    > is not in the same room, and there are network connectivity problems.
    > The device joining the network needs local access and that is it.  Does
    > that mean it should not use EAP-TLS?  Or are we saying that they MUST
    > use naked public keys?

No.  There are several steps before we get to raw public keys.

The first is that the duration of the Staples could be lengthed to accomodate
anticipated down time for the (now) critical OCSP responder.
A second part is that perhaps staples could be provisioned in advance for the
server to cover for planned maintenance periods.  I don't imagine this is in
any protocol, but could be added.

The second is, I think, that the EAP server (Authentication Server), would run
an OCSP responder locally so that it can mint it's own staples.
AFAIK, each certificate can point to a different OCSP signer.
While this degenerate case of Authentication Server + OCSP Signer on the same
machine is kinda dumb from a overall security point of view, it's still
better than raw public keys.  If the OCSP signer is moved to some TPM then
there is a win.  Not all TPMs can provide the performance required to handle
the server certificate, but resigning an OCSP Staple once every ten minutes
or something shouldn't be a problem.

The third is, I think, that the EAP server runs an entirely self-contained
private CA.  The OCSP responder is now clearly an integral part of the local
system.

Do we need to write an Operational Considerations document here?

    > For many devices the manufacturers will be unable to predict whether a
    > device will or will not have direct access to anything.  It specific to
    > deployment circumstances.  Also, running an OCSP server is something
    > that will be very new for many enterprises.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 15:31:19 +0100

> On 26 Oct 2020, at 15:19, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

But to what end?  We don’t even know if these devices can reasonably deal with any secure notion of time.  Even checking cert expiry is a bit questionable in some cases, especially if the cert has been seen before, and the device is of someone critical value.  And it’s not clear what the value is with a lengthy expiry.

> AFAIK, each certificate can point to a different OCSP signer.

Does anyone actually do that?

> better than raw public keys.

Yes.  Let’s think about who OCSP is protecting in this case.  It’s protecting the client from the Authentication Server, in theory.

> If the OCSP signer is moved to some TPM then

If this is the case, then a public key could be moved into the the TPM just as easily.

> private CA.  The OCSP responder is now clearly an integral part of the local

Again, what threat are we protecting against?

Eliot

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 2020 10:45:48 -0400

> Does anyone actually do that?

I am aware of some places that generate an OCSP response for the entire population of certificates, and those responsed are distributed to many locations.  I am not aware of anyone that distributes the OCSP responder signature private key to multiple locations.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2020 11:26:57 -0400

> But to what end?  We don’t even know if these devices can reasonably
    > deal with any secure notion of time.  Even checking cert expiry is a
    > bit questionable in some cases, especially if the cert has been seen
    > before, and the device is of someone critical value.  And it’s not
    > clear what the value is with a lengthy expiry.

okay, but this is clearly a problem regardless.
Devices without known good time can't do very many useful things, and
probably just could ignore the staple.
But, laptops and mobiles do have good time, and they can do the right thing.

    > Does anyone actually do that?

I dunno, but it is possible as far as I can tell.

    > Yes.  Let’s think about who OCSP is protecting in this case.  It’s
    > protecting the client from the Authentication Server, in theory.

Yes, from compromises of the Authentication Server via loss of control of private key.

    > If this is the case, then a public key could be moved into the the TPM just as easily.

If the TPM can accomodate thousands of signatures per minute, which fTPMs
probably can accomodate (same CPU, just different context), then sure.
Many older, i2c interfaced physical-TPMs do not accomodate that rate.

    > Again, what threat are we protecting against?

The self-contained CA might have a passphrase, so there is some accomodation
updating the signing key for new algorithms, etc.  while the trust anchor
which is distributed is appropriate pessimistic.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2020 11:30:01 -0400

> I am aware of some places that generate an OCSP response for the entire
    > population of certificates, and those responsed are distributed to many
    > locations.  I am not aware of anyone that distributes the OCSP
    > responder signature private key to multiple locations.

Does anyone put different OCSP signers into different certificates?
I.e. shard the work?

I think that splitting the OCSP reponses to many locations might solve the
industrial situation well.
I think that there is also some significant space to tune the validity
periods.

But, I agree with Eliot: the OCSP responder is new.

It seems that maybe SHOULD would appropriate on OCSP.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 2020 13:00:01 -0400

> Does anyone put different OCSP signers into different certificates?

This could be done by including different AIA certificate extensions, but I am not aware of anyone that does so.

> industrial situation well.

One could put multiple id-ad-ocsp entries in the AuthorityInfoAccess extension, but this could lead to a relying party trying each one in turn, resulting in a long timeout interval.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 18:34:43 +0100

[Trimming]

> On 26 Oct 2020, at 16:26, Michael Richardson <[email-masked]> wrote:
> 
> 

And so the authentication server and OCSP signer being on the same device itself represents both a scaling problem and a security problem.  Just imagine having to manage all of that.

> Many older, i2c interfaced physical-TPMs do not accomodate that rate.

I’ll admit to only secondary interest in performance.  That is- one can optimize around this.  But managing naked public keys of servers themselves is not scalable from a key management perspective.

> which is distributed is appropriate pessimistic.

I guess the issue I’m having is that stapling is requiring more connectivity than may be present, and making it a MUST means that we are making very VERY broad deployment assumptions.  It is WAY too early for that.

Eliot