[Emu] Secdir last call review of draft-ietf-emu-eap-tls13-11

[Kyle Rose via Datatracker]

Reviewer: Kyle Rose
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document is ready with nits.

The purpose of this document is to update the TLS method of EAP to accommodate
the changes to TLS in 1.3: in this, it appears to be complete and to have been
thoroughly vetted. I have two nits and a high-level suggestion:

* The introduction at one point says "Privacy is mandatory". Later in the
document it becomes clear what is meant by this, but at this point in the
document "privacy" is somewhat of a Rorschach test. It clearly doesn't mean
that repeated EAP requests from the same IP will be unlinkable, for instance.
What appears to be meant here is that encryption of the client certificate
prevents linkability via passive surveillance. Say that instead.

* Expand NAI into "Network Access Identifiers", with the appropriate
informative reference, at its first use, not halfway through the document.

* My high-level suggestion for this document is to be forward-looking in how
you specify the relationship of EAP to TLS. Expect there to be a TLS 1.4 (or
2.0) and beyond, and specify this protocol using standardized TLS interfaces
only, with the rest of the protocol (including the specific handshake messages)
treated as a black box. This may or may not have been possible in the pre-TLS
1.3 era, but it is certainly possible to do so now. At best, no normative
changes will be required; at worst, the size of the update to the EAP RFC will
be minimized.


___
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,

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] Proposed Resolution to TEAP Errata 5770

[Joseph Salowey]

On Tue, Oct 27, 2020 at 12:23 AM Eliot Lear  wrote:

> Hi,
>
> >
> > [Joe] Yes I think it is fine to say EAP authentication method.   I have
> been convinced that the spec requires crypto-binding with the basic
> password authentication.   I'll need to add this in.
> >
>
> Keep in mind that there might not even be basic auth.  One case is that
> one just uses the OUTER auth, does some PKCS ops or extensions and then
> wants to conclude.  No inner in this case.  Which erratum is that covered
> by?
>
>
[Joe]  Erratum 5775 discusses how to generate key material when there is
no inner authentication method such as the case you describe.


> Eliot
>
>
___
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 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
>

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

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] Proposed Resolution to TEAP Errata 5770

[Eliot Lear]

Hi,

> 
> [Joe] Yes I think it is fine to say EAP authentication method.   I have been 
> convinced that the spec requires crypto-binding with the basic password 
> authentication.   I'll need to add this in. 
>  

Keep in mind that there might not even be basic auth.  One case is that one 
just uses the OUTER auth, does some PKCS ops or extensions and then wants to 
conclude.  No inner in this case.  Which erratum is that covered by?

Eliot

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