[Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Using EAP-TLS with TLS 1.3
Authors : John Preuß Mattsson
  Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-12.txt
Pages   : 30
Date: 2020-11-02

Abstract:
   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-12
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Michael Richardson]

Eliot Lear  wrote:
> Consider the scenario when you have the CA sitting off somewhere in the
> distance, and a power failure or other service interruption has
> occurred.  Should the client refuse to come up because stapling didn’t
> happen?  Should old stapling information be retained, and what does
> that mean in the context of the nonce extension?  I had thought we said
> that this risk is mitigated by the choice of the deployment to include
> the OCSP extension information in the cert- or not.  At that point the
> deployment can make the decision.

Eliot,

1) it seems that if the CA hasn't put stapling information in, then it won't be 
needed.

2) if you still want stapling, then it seems to me that there are lifetimes in 
the
   staple which can be adjusted to deal with anticipated service
   interruptions in connectivity to the CA.


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

[Alan DeKok]

On Nov 2, 2020, at 4:37 AM, Hannes Tschofenig  wrote:
> 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.

  There is a problem with session resumption.  RFC 5216 is silent on security 
issues with respect to session resumption.  That's a major flaw in the 
specification.

  I had given reasons for this position earlier, in my original post 
recommending changes to this document.  And again in my earlier reply to your 
message.

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

  I believe that an EAP-TLS document should discuss security, implementation, 
and deployment issues with respect to EAP-TLS.

  You have a point in that many of these issues are applicable to other 
TLS-based EAP methods, too.  Updates to those methods can reference this 
document.  There's no need for a separate document.

  Alan DeKok.

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

Re: [Emu] Proposed TEAP Errata Resolution Summary

[Eliot Lear]

Joe,

Thanks for all your work on this.  On the “discuss”es, would you mind giving 
some time for them at the meeting?

Thanks,

Eliot

> On 1 Nov 2020, at 23:33, Joseph Salowey  wrote:
> 
> Below is the summary of the TEAP errata resolutions.  The text that will be 
> sent to the AD is in the linked emails.  The GitHub PR is provided to make it 
> easier to review the revision in context.  Anything that is marked for final 
> review will be sent to the AD next week if there are no objections raised.  
> Ones marked discuss should have some discuss to verify the resolution (5765, 
> 5767, 5775, 5844). 
> 
> Thanks,
> 
> Joe
> 
> Errata ID: 5127
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/R5uypu9Kna8vTpyV5BlIXDm-Mdk/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/2 
> 
> 
> Errata ID: 5128
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/fYBuPgWa7xiH7JmoHfP5yrU7HV0/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/4 
> 
> 
> Errata ID: 5765
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/Ga8evJZzLG8lCML-kkxV6G_JS0E/ 
> 
> Mail: https://mailarchive.ietf.org/arch/msg/emu/676S5r51SkmxtzLZH9FqNFB6aOQ/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/18 
> 
> 
> Errata ID: 5767
> Status: Hold For Document Update - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/QIOT258m2LNCnmCGKgpjCYVFLWE/ 
> 
> 
> Errata ID: 5768
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/r-nAObtWmZ6tt1Dd0fmc7cHEBNs/ 
> 
> PR for section 5 is: https://github.com/emu-wg/teap-errata/pull/8 
> 
> PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7 
> 
> 
> Errata ID: 5770
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/mXzpSGEn86Zx_fa4f1uULYMhMoM/ 
> 
> PR for section 5: https://github.com/emu-wg/teap-errata/pull/13 
> 
> 
> Errata ID: 5775
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/u96Oxo2oFnsntJUFRFgiPENDcYQ/ 
> 
> Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12 
> 
> Section 5 PR - https://github.com/emu-wg/teap-errata/pull/11 
> 
> 
> Errata ID: 5844
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/1ceqDbGP3mozqbzZ40xo48zFiDo/ 
> 
> 
> PR Section 5: https://github.com/emu-wg/teap-errata/pull/19 
> 
> PR section 3: https://github.com/emu-wg/teap-errata/pull/22 
> 
> PR section 3: https://github.com/emu-wg/teap-errata/pull/23 
> 
> PR section 4: https://github.com/emu-wg/teap-errata/pull/24 
> 
> 
> Errata ID: 5845
> Status: Verified - Final review
> Type: Technical Mail: 
> https://mailarchive.ietf.org/arch/msg/emu/Ucy2tg7UyZFry99k3oGOY_aS6mk 
> 
> The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20 
> 
> 
> Errata ID: 6157
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/t1HhhUL0QFgBmgAFYRMRkKXWXaA/ 
> 
> PR:https://github.com/emu-wg/teap-errata/pull/21 
> 
> ___
> 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] Robert Wilton's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-emu-eaptlscert-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/



--
COMMENT:
--

Thank you for this document.  I found it informative, easy to read, and
enlightening on a problem that I wasn't aware of.

I agree with Barry comment that it would be useful to talk about whether this
should be a BCP or Informational.

Regards,
Rob



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

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

[Mohit Sethi M]

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 

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 

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

FWIW there is a public Mbed TLS virtual workshop tomorrow (see 
https://www.trustedfirmware.org/meetings/mbed-tls-workshop/).
Those who care about any of these security features could join, and ask for the 
support of x, y and z.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 12:36 PM
To: Hannes Tschofenig ; Mohit Sethi M 
; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less 
security in 2020 - OCSP


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


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.

You are probably right here. This is the unfortunate reality for many open 
source projects. While writing some code with openssl, I (and others) had 
requested a feature to export x25519 public keys: 
https://github.com/openssl/openssl/pull/5520#issuecomment-391088904. Not sure 
how far that has come along.

--Mohit



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

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] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Mohit Sethi M]

Hi Hannes,

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


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.

You are probably right here. This is the unfortunate reality for many open 
source projects. While writing some code with openssl, I (and others) had 
requested a feature to export x25519 public keys: 
https://github.com/openssl/openssl/pull/5520#issuecomment-391088904. Not sure 
how far that has come along.

--Mohit



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

[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 

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 

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

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] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

I agree with you, Eliot.

I don’t understand for what certificates we would be using OCSP in the EAP-TLS 
context, and what would happen if OCSP checks fail.

Ciao
Hannes

From: Eliot Lear 
Sent: Monday, November 2, 2020 12:27 PM
To: Hannes Tschofenig 
Cc: Mohit Sethi M ; emu@ietf.org
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less 
security in 2020 - OCSP

Hi Hannes,

My concern is not about implementation.  At least for the sake of discussion, 
let us assume that we can get the code to where it needs to be.  The question 
is more about what happens when an OCSP server is unavailable, either to the 
client or to the server (stapled or otherwise).  What is expected of server 
behavior in such a case, and what is expected of client behavior?

Consider the scenario when you have the CA sitting off somewhere in the 
distance, and a power failure or other service interruption has occurred.  
Should the client refuse to come up because stapling didn’t happen?  Should old 
stapling information be retained, and what does that mean in the context of the 
nonce extension?  I had thought we said that this risk is mitigated by the 
choice of the deployment to include the OCSP extension information in the cert- 
or not.  At that point the deployment can make the decision.

Are we now saying otherwise?

Eliot

On 2 Nov 2020, at 09:08, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Mohit,


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED 
that EAP-TLS peers and servers use OCSP stapling for verifying the status of 
server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an 
EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, 
it MUST use Certificate Status Requests for the server's certificate chain and 
it MUST treat a CertificateEntry (except the trust anchor) without a valid 
CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of 
Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org
Subject: [Emu] Moving towards less security in 2020 - OCSP

Dear all,
Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.
EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.
Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of

   [RFC3280].  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366].  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by 

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Eliot Lear]

Hi Hannes,

My concern is not about implementation.  At least for the sake of discussion, 
let us assume that we can get the code to where it needs to be.  The question 
is more about what happens when an OCSP server is unavailable, either to the 
client or to the server (stapled or otherwise).  What is expected of server 
behavior in such a case, and what is expected of client behavior?

Consider the scenario when you have the CA sitting off somewhere in the 
distance, and a power failure or other service interruption has occurred.  
Should the client refuse to come up because stapling didn’t happen?  Should old 
stapling information be retained, and what does that mean in the context of the 
nonce extension?  I had thought we said that this risk is mitigated by the 
choice of the deployment to include the OCSP extension information in the cert- 
or not.  At that point the deployment can make the decision.

Are we now saying otherwise?

Eliot

> On 2 Nov 2020, at 09:08, Hannes Tschofenig  > wrote:
> 
> Hi Mohit, 
>  
> I think it is a reasonable compromise for servers to implement OCSP stapling. 
> Clients can implement and use it, but they would be compliant even if they 
> don't. So the updated text would be (as Joe wrote in his email):
> “ 
> EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
> (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is 
> RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying 
> the status of server certificates as specified in Section 4.4.2.1 of 
> [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of 
> the EAP-TLS server, it MUST use Certificate Status Requests for the server's 
> certificate chain and it MUST treat a CertificateEntry (except the trust 
> anchor) without a valid CertificateStatus extension as invalid and abort the 
> handshake with an appropriate alert.
> “
>  
> This sounds like a good compromise for me. 
>  
> Ciao
> Hannes
>  
> PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
> looking forward to see OCSP supported added to EDHOC by John.
>  
> From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of 
> Mohit Sethi M
> Sent: Saturday, October 31, 2020 2:15 PM
> To: emu@ietf.org 
> Subject: [Emu] Moving towards less security in 2020 - OCSP
>  
> Dear all,
> 
> Sorry for the radio silence. I have over-committed myself to too many things. 
> I think I have now read the entire discussion on OCSP.
> 
> EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
> whatever the working group wants. The authors and contributors are at the 
> service of the working group. Obviously it is easy for us to simply change 
> all MUSTs to MAYs, make everyone happy, and hand over the document to the 
> IESG. 
> 
> Yet, I think as a conscientious security person and individual contributor, I 
> am saddened by the discussion thus far. To begin with, I assume that everyone 
> knows the difference between OCSP and OCSP stapling. I also hope that 
> everyone has read RFC 5216 (the previous EAP-TLS specification). In 
> particular I hope that the working group has actually read section 5.4 on 
> "Certificate Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4 
> ). I copy the relevant text 
> here for your convenience:
> 
>EAP-TLS peer and server implementations MUST support the use of
>Certificate Revocation Lists (CRLs); for details, see Section 3.3 of 
> 
>    [RFC3280] .  EAP-TLS peer 
> and server implementations SHOULD also
>support the Online Certificate Status Protocol (OCSP), described in
>"X.509 Internet Public Key Infrastructure Online Certificate Status
>Protocol - OCSP" [RFC2560 ].  OCSP 
> messages are typically much smaller
>than CRLs, which can shorten connection times especially in
>bandwidth-constrained environments. 
> and 
>For this reason, EAP-TLS peers and servers SHOULD implement
>Certificate Status Request messages, as described in "Transport Layer
>Security (TLS) Extensions", Section 3.6 of [RFC4366] 
> .  To enable
>revocation checking in situations where servers do not support
>Certificate Status Request messages and network connectivity is not
>available prior to authentication completion, peer implementations
>MUST also support checking for certificate revocation after
>authentication completes and network connectivity is available, and
>they SHOULD utilize this capability by default.
> 
> So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
> published. And now 12/13 years later, some people in the working group are 
> suggesting to make the security 

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

[Mohit Sethi M]

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 

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 

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

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

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 

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

Hi Mohit,


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.



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

[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 

Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
; 
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 

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

[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 

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

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

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

[Mohit Sethi M]

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 

Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
; 
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 mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. 

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

[Mohit Sethi M]

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 

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

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

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

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Mohit Sethi M]

Et voilà, we seem to be moving towards a consensus!

--Mohit

PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
high time. There have been several requests for this already for a few years: 
https://github.com/ARMmbed/mbedtls/issues/880

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


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED 
that EAP-TLS peers and servers use OCSP stapling for verifying the status of 
server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an 
EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, 
it MUST use Certificate Status Requests for the server's certificate chain and 
it MUST treat a CertificateEntry (except the trust anchor) without a valid 
CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu  On Behalf Of 
Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org
Subject: [Emu] Moving towards less security in 2020 - OCSP


Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of

   [RFC3280].  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366].  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
published. And now 12/13 years later, some people in the working group are 
suggesting to make the security stance weaker. For what? Some speculative 
insecure future deployments? Please note that EAP-TLS is currently implemented 
in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid 
of the text on OCSP. He wrote "I do not understand certificate revocation 
checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you 
see, RFC 5216 has quite detailed guidelines on certificate revocation checking 
with CRLs and OCSP so I don't see any sensible reason on why an update to it 
should not contain relevant text. Michael wrote " we are under no additional 
compulsion to support revocation than we were before." Do you see the problem 
here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their views, we also saw feedback 
from Janfred explaining the situation without OCSP in a live network 

[Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

Hi Mohit,


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED 
that EAP-TLS peers and servers use OCSP stapling for verifying the status of 
server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an 
EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, 
it MUST use Certificate Status Requests for the server's certificate chain and 
it MUST treat a CertificateEntry (except the trust anchor) without a valid 
CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu  On Behalf Of Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org
Subject: [Emu] Moving towards less security in 2020 - OCSP


Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of

   [RFC3280].  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366].  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
published. And now 12/13 years later, some people in the working group are 
suggesting to make the security stance weaker. For what? Some speculative 
insecure future deployments? Please note that EAP-TLS is currently implemented 
in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid 
of the text on OCSP. He wrote "I do not understand certificate revocation 
checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you 
see, RFC 5216 has quite detailed guidelines on certificate revocation checking 
with CRLs and OCSP so I don't see any sensible reason on why an update to it 
should not contain relevant text. Michael wrote " we are under no additional 
compulsion to support revocation than we were before." Do you see the problem 
here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their views, we also saw feedback 
from Janfred explaining the situation without OCSP in a live network like 
eduroam: 
https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends 
his email with

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.