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

[Hannes Tschofenig]

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



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

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

[Joseph Salowey]

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 ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>
>
>
> [Joe] No,  discusses handling large
> certificates not revocation.
>
>
>
> [Hannes] Here the problem description that motivates
> 
>
> “
>
> 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 
>
>
>
> 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 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; 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  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 
> 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 bu

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

[Hannes Tschofenig]

Hi Joe,

a few remarks below.


On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig 
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 ? IMHO this 
would make more sense given that  talks about large 
certificates and long certificate chains and any proposal to make those even 
larger should be evaluated in this context.


[Joe] No,  discusses handling large certificates not 
revocation.

[Hannes] Here the problem description that motivates 
“
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 

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 mailto:j...@salowey.net>>
Sent: Thursday, October 22, 2020 11:12 PM
To: Eliot Lear 
mailto:40cisco@dmarc.ietf.org>>
Cc: Hannes Tschofenig 
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 
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 
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 attachment

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

[Joseph Salowey]

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.


> 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 ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>

[Joe] No,  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 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; 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  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 
> 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.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Hannes Tschofenig]

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.

>> Wouldn’t this be a topic to address in ? IMHO 
>> this would make more sense given that  talks 
>> about large certificates and long certificate chains and any proposal to 
>> make those even larger should be evaluated in this context.

>  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

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

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

[Eliot Lear]

[Trimming]

> On 26 Oct 2020, at 16:26, Michael Richardson  wrote:
> 
> 
>>> 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.
> 
>> 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.

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.

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

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.


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


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


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Russ Housley]

Michael:

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

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

> I think that splitting the OCSP reponses to many locations might solve the
> 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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Russ Housley  wrote:
>>> 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.
>>
>> 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.

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   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Eliot Lear  wrote:
>> 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.

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

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

> Does anyone actually do that?

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

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

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

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

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

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Russ Housley]

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

> On 26 Oct 2020, at 15:19, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Eliot Lear  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.

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.


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

Does anyone actually do that?

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

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

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

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

Again, what threat are we protecting against?

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

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


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

John Mattsson  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).

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

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

Thanks, John.  Please see below:

> On 26 Oct 2020, at 13:58, John Mattsson 
>  wrote:
> 
> 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.
> 

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
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[John Mattsson]

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 
Date: Monday, 26 October 2020 at 13:16
To: John Mattsson 
Cc: "emu@ietf.org" 
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

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 
>  wrote:
> 
> 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
> 
> ___
> 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

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

[Eliot Lear]

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 
>  wrote:
> 
> 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
> 
> ___
> 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

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

[John Mattsson]

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Alan DeKok]

On Oct 23, 2020, at 3:37 AM, Hannes Tschofenig  
wrote:
> 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 ? IMHO this 
> would make more sense given that  talks about 
> large certificates and long certificate chains and any proposal to make those 
> even larger should be evaluated in this context. 

  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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Hannes Tschofenig]

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 ? IMHO this 
would make more sense given that  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 
Sent: Thursday, October 22, 2020 11:12 PM
To: Eliot Lear 
Cc: Hannes Tschofenig ; 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 
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 
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.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

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?
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Joseph Salowey  wrote:
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear 

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

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.


>> Eliot
>>
>> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
>> 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
>>

> 
> Alternatives:

> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear 
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 
> 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
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Hannes Tschofenig  wrote:
> 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.

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

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

Eliot

> On 21 Oct 2020, at 11:02, Hannes Tschofenig  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

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

[Jan-Frederik Rieckers]

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



signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Hannes Tschofenig]

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 
Sent: Wednesday, October 21, 2020 6:46 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling


Hannes Tschofenig  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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
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

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

[Michael Richardson]

Hannes Tschofenig  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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Alan DeKok]

On Oct 21, 2020, at 5:02 AM, Hannes Tschofenig  
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.
>  
> 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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu