subject:"\[Emu\] draft\-ietf\-emu\-eap\-tls13\-11"

Hi Hannes,

Thanks. I like the friendly banter. I could probably find the commit which says 
"SHOULD mitigate known attacks" and blame it on John. I will change it to MUST. 
:)

I have opened an issue to explain the relationship to RFC 7525: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/16.

Please be rest assured that I don't get any money for publishing RFCs. Let 
alone any extra payment based on the number of pages.

I did not write the code for session resumption but (together with my 
colleague) we have tested wpa_supplicant and freeRadius EAP-TLS resumption and 
it works. As said, Alan wanted the text. Here is one of the long discussion 
threads on this issue: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Notes%20on%20session%20resumption%20with%20TLS-based%20EAP%20methods

Let's wait and see what he has to say. We are happy to update once there is 
some consensus on how much of the text should stay.

--Mohit

On 11/2/20 11:37 AM, Hannes Tschofenig wrote:
Hi Mohit,

I have now read the email from Terry and he is not suggesting the original 
text. He is, in fact, correcting misleading text in your draft.

IMHO the entire text in Section 5.7 reads a bit like you are giving 
implementation guidance. That would be great if John or you had written such 
code. I don’t know whether you have.
You are given the reader the impression that there is a problem with session 
resumption. I don’t believe there is a problem and I gave you reasons in my 
email.

On the second topic. Here is my remark about the wrong reference and my 
suggestion to address it:

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

If you want to reference RFC 7525 you should say what recommendation you want 
to carry over. If you don’t do that then the text should not be in 
contradiction of what is said in eap-tls13.

Given your email with the dramatic title “Moving towards less security in 
2020”, I am surprised that the reference to known attacks and the deprecation 
of old TLS versions receives a “SHOULD” rather than a “MUST”. Feels out of 
balance to me and this makes me believe that the update to RFC 5216 has not 
been given too much thoughts by the group and by the authors. My guess is that 
most implementers use the latest version of TLS 1.2 code already anyway, which 
comes with sensible defaults. Do you have a different experience?

Ciao
Hannes

From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:59 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit
On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-11-02 Thread Hannes Tschofenig

Thanks, Mohit, for the quick turn-over.

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 12:21 PM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Done as suggested:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/8e158b5dc06ab5efd06c130ceffefe8c0cdff8e0

--Mohit
On 11/2/20 11:16 AM, Hannes Tschofenig wrote:
Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes

From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes

From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

___

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Done as suggested:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/8e158b5dc06ab5efd06c130ceffefe8c0cdff8e0

--Mohit

On 11/2/20 11:16 AM, Hannes Tschofenig wrote:
Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim’s email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the “SHOULD” statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

2020-11-02 Thread Hannes Tschofenig

Hi Mohit,

I have now read the email from Terry and he is not suggesting the original 
text. He is, in fact, correcting misleading text in your draft.

IMHO the entire text in Section 5.7 reads a bit like you are giving 
implementation guidance. That would be great if John or you had written such 
code. I don't know whether you have.
You are given the reader the impression that there is a problem with session 
resumption. I don't believe there is a problem and I gave you reasons in my 
email.

On the second topic. Here is my remark about the wrong reference and my 
suggestion to address it:

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

If you want to reference RFC 7525 you should say what recommendation you want 
to carry over. If you don't do that then the text should not be in 
contradiction of what is said in eap-tls13.

Given your email with the dramatic title "Moving towards less security in 
2020", I am surprised that the reference to known attacks and the deprecation 
of old TLS versions receives a "SHOULD" rather than a "MUST". Feels out of 
balance to me and this makes me believe that the update to RFC 5216 has not 
been given too much thoughts by the group and by the authors. My guess is that 
most implementers use the latest version of TLS 1.2 code already anyway, which 
comes with sensible defaults. Do you have a different experience?

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 9:59 AM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit
On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those 
because they are hidden in the document.
  3.  You are referencing the wrong documents.

If you look at this case as a working group chair then you might see the points 
I am trying to get across.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit
On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumptio

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-11-02 Thread Hannes Tschofenig

Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes


From: Mohit Sethi M 
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

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: Updates RFC 5216

Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit

On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those 
because they are hidden in the document.
  3.  You are referencing the wrong documents.

If you look at this case as a working group chair then you might see the points 
I am trying to get across.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit
On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don’t think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:

TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit

On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim’s email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the “SHOULD” statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

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
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-11-01 Thread Hannes Tschofenig

Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

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: Updates RFC 5216

2020-10-31 Thread Mohit Sethi M

Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit

On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don’t think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

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: Conformance with the TLS 13 Spec

2020-10-31 Thread Mohit Sethi M

Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit

On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

2020-10-31 Thread Mohit


Hi Hannes,

Thanks. I have opened several issues on github based on your review: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues


--Mohit

On 10/21/20 11:55 AM, Hannes Tschofenig wrote:


Hi all,

Roman asked me to look at draft-ietf-emu-eap-tls13-11.

I have carefully read through the document and I will post my reviews 
in separate emails.


There are still lots of room for improvement.

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

2020-10-27 Thread 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

2020-10-27 Thread 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

2020-10-27 Thread 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

2020-10-27 Thread 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

2020-10-27 Thread 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

[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

2020-10-26 Thread 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

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


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

2020-10-26 Thread 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



> 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

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


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

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

2020-10-26 Thread 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

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

2020-10-26 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-22 Thread 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

2020-10-22 Thread 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

2020-10-22 Thread 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

2020-10-22 Thread 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

2020-10-22 Thread 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

2020-10-22 Thread 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

2020-10-21 Thread 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

2020-10-21 Thread 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

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

2020-10-21 Thread Alan DeKok

On Oct 21, 2020, at 5:00 AM, Hannes Tschofenig  
wrote:
> the draft says it updates the earlier EAP-TLS version and claims that the 
> updates are related to
>  
> * Section 5.6 Authorization
> * Section 5.7 Resumption
>  
> The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
> to all EAP methods. I don't think it even belongs in an EAP method document.

  The second paragraph is generic to all EAP methods.  But it's explanatory, 
and doesn't offer specific security advice.

  The third paragraph is relevant to EAP-TLS, even if the first part true for 
all EAP methods.  However, the second part refers to the PSK used for 
resumption, and is specific to EAP-TLS.  As such, I believe that the text 
should stay.  

> The content of Section 5.7 claims that there are aspects of resumptions that 
> are not described in the earlier version of EAP-TLS. The focus is then on the 
> way how the cached data is stored, an implementation-specific aspect, that is 
> not specific to EAP-TLS because the concept of caching is used by other EAP 
> methods too.

  That's nice, but I don't recall any other document which discusses cached 
data with respect to EAP.  Since we're updating EAP-TLS here, I think it's 
relevant.

  i.e. if we could refer to another document, that would be preferred.  Since 
no other document exists, we need to discuss security considerations with 
respect to EAP-TLS.  Even if the discussion is _also_ relevant to non-TLS EAP 
methods.

> Then, there is a threat presented whereby the authorization information 
> changes between the full handshake and the resumption handshake. I believe 
> that this is not a threat that is unique to EAP-TLS because this can happen 
> even when there is no resumption.

  Yes.

  However, the identity used for authentication changes when doing resumption.  
This change means that authorization based on identities is more difficult than 
with "normal" authentication.  As such, there are attacks unique to resumption 
which must be mitigated.

  Perhaps this point could be made more clear.  i.e. instead of the focus being 
on cached data, the focus could be on changing identities, and how cached data 
can help detect and address that change.

> Nothing prevents you from checking authorization again when you do resumption 
> though and even during an ongoing session. I would argue that there is a lot 
> of text in there that has nothing to do with EAP-TLS but rather concerns the 
> whole system in which EAP is used. If this is indeed a problem, I believe it 
> should be covered in a separate document.

  Given the time frame and the need to update EAP-TLS for TLS 1.3, I disagree.  
It is a problem, and it should be addressed here.

> I don’t think it is a problem because extensions for RADIUS and Diameter have 
> been developed to address this issue to revoke authorization during the 
> lifetime of a session.

  This document should give guidance on how to implement EAP-TLS securely.  
RADIUS and Diameter don't help with issues such as the identity changing for 
resumption.

> Here is where it gets confusing. The introduction says "This document defines 
> how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS 
> is used with older versions of TLS." To me, this does not sound like an 
> update.

 It doesn't not change earlier versions of EAP-TLS.  But it gives new guidance. 
 Perhaps this could be clearer.

> At a minimum, I would clarify in the introduction what the updates to RFC 
> 5216 are. This will help those implementers that focus on a variant of 
> EAP-TLS that uses version 1.2.

  I agree.

> As mentioned above, I don't believe Sections 5.6 and 5.7 belong to this 
> document. Leave it in there if someone in the group gets paid by the number 
> of published pages.

  Or if the authors wish to give practical, timely, advice to implementors of 
EAP-TLS.

  Alan DeKok.

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

[Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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] draft-ietf-emu-eap-tls13-11: Repetition of Text

Hi all,

the draft contains a number of cases where text from the TLS 1.3 specification 
or other specifications is repeated. Often, only fragments are used, which can 
easily fool the reader into believing that the omitted parts do not apply. 
Hence, I would avoid the repetition where not strictly necessary.

Here are two examples:

Section 2.1.6:

"
   As noted in Section 4.1.4 of [RFC8446],
   the server MUST provide the supported_versions extensions and SHOULD
   contain the minimal set of extensions necessary for the client to
   generate a correct ClientHello pair.  A HelloRetryRequest MUST NOT
   contain any extensions that were not first offered by the client in
   its ClientHello, with the exception of optionally including the
   cookie extension.
"

Section 2.1.9:

"
To avoid fragmentation, it
   is RECOMMENDED to keep the sizes of client, server, and trust anchor
   certificates small and the length of the certificate chains short.
   In addition, it is RECOMMENDED to use mechanisms that reduce the
   sizes of Certificate messages.

   While Elliptic Curve Cryptography (ECC) was optional for earlier
   version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
   [RFC8446]).  To avoid fragmentation, the use of ECC in certificates,
   signature algorithms, and groups are RECOMMENDED when using EAP-TLS
   with TLS 1.3 or higher.  At a 128-bit security level, this reduces
   public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE)
   and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA).
   An EAP-TLS deployment MAY further reduce the certificate sizes by
   limiting the number of Subject Alternative Names.

   Endpoints SHOULD reduce the sizes of Certificate messages by omitting
   certificates that the other endpoint is known to possess.  When using
   TLS 1.3, all certificates that specifies a trust anchor may be
   omitted (see Section 4.4.2 of [RFC8446]).  When using TLS 1.2, only
   the self-signed certificate that specifies the root certificate
   authority may be omitted (see Section 7.4.2 of [RFC5246]).  EAP-TLS
   peers and servers SHOULD support and use the Cached Information
   Extension as specified in [RFC7924].  EAP-TLS peers and servers MAY
   use other extensions for reducing the sizes of Certificate messages,
   e.g. certificate compression [I-D.ietf-tls-certificate-compression].

   For a detailed discussion on reducing message sizes to prevent
   fragmentation, see [I-D.ietf-emu-eaptlscert].
"

This entire text should be replaced by a reference to 
[I-D.ietf-emu-eaptlscert], which offers a more detailed discussion.
It makes no sense to just copy a fragment of the text here, particularly when 
we are talking about a document from the same working group written by the same 
authors.

An small error in the text above: trust anchors are not exchanged in the TLS 
handshake.

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] draft-ietf-emu-eap-tls13-11: Fuzzy statements

Hi all,

There are plenty of places in the draft where statements are made in a somewhat 
sloppy manner.

Section 5.1:

" TLS 1.3 increases the number of
  cryptographic parameters that are negotiated in the handshake.
"

Increases the number of parameters compared to what?

Section 5.1:

"
TLS 1.3 forbids all algorithms with known
   weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3
   only supports cryptographic algorithms offering at least 112-bit
   security, see [RFC8446].
"

Most of those algorithms have been depreciated also with TLS 1.2
I would instead say that TLS 1.3 only uses AEAD ciphers.

 Section 2.5:

"
The Commitment Message is
   an encrypted TLS record with application data 0x00 (i.e. a TLS record
   with TLSPlaintext.type = application_data, TLSPlaintext.length = 1,
   and TLSPlaintext.fragment = 0x00).
"

Adding the note about TLSPlaintext.type, TLSPlaintext.length, and 
TLSPlaintext.fragment is not helpful given that both plaintext TLS records as 
well as encrypted TLS records use these structures. There is also a mistake in 
there because the TLSInnerPlaintext.type contains the application_data type (of 
course the TLSCiphertext.opaque_type also contains the application_data).

Introduction:
"
Privacy is mandatory ...
"

It depends what you call "privacy". TLS 1.3 offers a range of features that 
increase privacy protection but not all of them are mandatory to use. Example: 
record padding

In Section 2.1.8 you talk about privacy and say:

"
   TLS 1.3 significantly improves privacy when compared to earlier
   versions of TLS by forbidding cipher suites without confidentiality
   and encrypting large parts of the TLS handshake including the
   certificate messages.
"

This list is not exhaustive when it comes to the privacy features in TLS 1.3, 
as you know. If you think it is worthwhile to highlight the privacy features 
then why not list all of them?


Section 2.1.1:

"
SessionID is deprecated in TLS 1.3 and the EAP
   server SHALL ignore the legacy_session_id field if TLS 1.3 is
   negotiated.
"

This is misleading because the EAP server does not look into the TLS handshake 
messages.
Additionally, the session ID is not deprecated - it is a legacy feature that is 
used in the backwards compatibility mode.
FWIW you are not saying anything about the backwards compatibility mode and 
hence I believe you are not using it. That's something that has to be made more 
explicit.

Section 2.1.3:

"
The TLS PSK identity is typically derived by
   the TLS implementation and may be an opaque blob without a routable
   realm.  The TLS PSK identity is therefore in general unsuitable for
   deriving a NAI to use in the Identity Response.
"

There is no requirement in the TLS 1.3 spec that a PSK identity has to be in a 
NAI format. Hence, most implementations will not produce one in a NAI format. 
It can still be used to derive a NAI in an Identity Response if you stick a 
@realm to it at a different layer.

Section 2.1.6:

"
   TLS 1.3 [RFC8446] defines that TLS servers can send a
   HelloRetryRequest message in response to a ClientHello if the server
   finds an acceptable set of parameters but the initial ClientHello
   does not contain all the needed information to continue the
   handshake.
"

The TLS specification also says that this message can be used for DDoS 
mitigation. I think that DDoS mitigation is a valid use case in an EAP-based 
deployment.

Section 2.1.7:

"
  Many client certificates
   contains an identity such as an email address, which is already in
   NAI format.  When the client certificate contains a NAI as subject
   name or alternative subject name, an anonymous NAI SHOULD be derived
   from the NAI in the certificate, see Section 2.1.8.
"

>From where do you get the impression that "many client certificates" contain 
>an identity, such as an email address?
Why does it matter whether the NAI is contained in the subject name or in the 
alt subject name?
You refer to Section 2.1.8 regarding how to derive a anonymous NAI from the 
certificate and I couldn't find the text.


"
   As the certificate messages in TLS 1.3 are encrypted, there is no
   need to send an empty certificate_list and perform a second handshake
   for privacy (as needed by EAP-TLS with earlier versions of TLS).
"

Most readers are probably not familiar with the problem you are describing here.
Also, this issue is not specific to EAP-TLS; the same approach has been used in 
TLS (prior to 1.3) in general.

"   When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
   and EAP-TLS server SHALL follow the processing specified by the used
   version of TLS.
"

This statement is obvious and does not say much. What else do you want to do?

"
   For TLS 1.3 this means that the EAP-TLS peer only
   sends an empty certificate_list if it does not have an appropriate
   certificate to send, and the EAP-TLS server MAY treat an empty
   certificate_list as a terminal condition.
"

In

[Emu] draft-ietf-emu-eap-tls13-11: Editorial

Hi all,

there are lots of editorial bugs in the text. I noticed many missing commas, 
missing articles, etc.

I know that the RFC Editor does a great job in correcting all of those errors 
but we have to do our work as well.

It would also be good to be consistent with the terms. How do you want to want 
to distinguish between EAP-TLS based on RFC 5216 and EAP-TLS with TLS 1.3? 
Sometimes it is possible to understand this from the context because certain 
features are not available in TLS 1.2 or have different names but it will help 
those who are less familiar with the history of TLS to be precise.

The terms EAP-TLS peer, EAP-TLS, and EAP peer seem to be used interchangeably. 
It would be good to use the terms consistently.

Here is an example from Section 5.8:

"
EAP peers SHOULD use record padding, see
   Section 5.4 of [RFC8446] to reduce information leakage of certificate
   sizes.
"

In this example the reader is asked to understand that we are not talking about 
the EAP layer, nor about EAP-TLS with RFC 5216 but about the client and the 
server of EAP-TLS with TLS 1.3.

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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

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] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don't think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

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] draft-ietf-emu-eap-tls13-11: Commitment Message

Hi all,



in an earlier email on this topic John wrote "I don't see why anybody would get 
the impressions that the application data would be unencrypted, all application 
data in TLS 1.3 is encrypted."



Even in the latest version of the draft (version -11) I can still find text 
that says the contrary.



Section 2.4:



"

   While EAP-TLS does not protect any application data, the negotiated

   cipher suites and algorithms MAY be used to secure data as done in

   other TLS-based EAP methods.

"



Section 2.1.1:



"

   After the TLS handshake has completed

   and all Post-Handshake messages have been sent, the EAP server sends

   EAP-Success.

"



Even the figure that follows this statement shows that this is not true because 
there is still the Commitment Message.



Can you see how this is confusing?



I had suggested to add a note to the introduction to make it clear that the 
Commitment Message is one of the two things that changed with this draft. (The 
other aspect is the changed key exporting.)



Currently, the important information on how the Commitment Message works is 
buried in a section called EAP State Machines when nothing in the draft can 
possibly change the EAP state machine.



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] draft-ietf-emu-eap-tls13-11