EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3
draft-ietf-emu-eap-tls13-21

[Ballot comment]
Updating my ballot position from Discuss to No Objection in light of the
discussion that we had at the telechat today.

Previous Discuss position:
======================================================================
Many thanks for the updates since the -13, the last version I reviewed.
I'm happy to report that the structural issues I noted in that version
have been addressed, and my new Discuss point is a fairly mundane one.

In several sections, we say that the text "updates Section X of
[RFC5216] by amending it with the following text", but I'm quite unclear
on exactly what that is intended to mean.  Are we adding to the end,
prepending to the beginning, replacing wholesale, replacing in part, or
doing something else to the indicated text of RFC 5216?  I expect that
just tweaking a few words can resolve the ambiguity, but am not sure
which ones yet.

It is also interesting to contrast the "amending" language with what we
say in Sections 2.1.4 and 2.3 about "replacing" text from RFC 5216 and
the various places where we report a "new section when compared to
[RFC5216]".
======================================================================

The discussion helped shed some light on the process the WG took to get
to the current state of having an amalgamation of new and existing text
where the new text amends the existing text in a way that has the reader
perform their own synthesis, avoiding a need for specification authors to
engage in a tedious exercise of going sentence-by-sentence to check all
the details.

I would suggest to make a change of the form:

OLD:
updates Section X of [RFC5216] by amending it with the following text

NEW:
updates Section X of [RFC5216] by amending it in accordance with the following
discussion


Original COMMENT section retained unchanged:
======================================================================
I echo the sentiments of other reviewers that constructing EAP-TLS 1.3
as something of a diff against RFC 5216 will make it harder to
eventually deprecate/obsolete/etc RFC 5216 and makes it somewhat
challenging to read the EAP-TLS 1.3 specification as a whole.  That
said, this is just the comment section, so I am not strenuously
objecting to it.

As another general note, in many places the phrasings used to describe
TLS 1.3 behaviors feel rather un-idiomatic to me, based on my experience
with TLS and TLS specifications.  That said, the behavior seems
well-specified as is, so I don't propose to make any changes in response
to this comment.  If there is demand, I could probably be persuaded to
suggest alternative text, but I don't expect much demand at this stage
in the document's lifecycle.

I made a github PR with some editorial suggestions:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/92

Section 2.1

  This section updates Section 2.1 of [RFC5216] by amending it with the
  following text.
  [...]
  TLS 1.3 changes both the message flow and the handshake messages
  compared to earlier versions of TLS.  Therefore, much of Section 2.1
  of [RFC5216] does not apply for TLS 1.3.  Except for Sections 2.2 and
  5.7 this document applies only when TLS 1.3 is negotiated.  When TLS
  1.2 is negotiated, then [RFC5216] applies.

There is perhaps some philosophical question of what "this document"
means in the context of an updated collection of text that includes RFC
5216 and the text that is being amended as directed here.  I hope that
the RFC Editor will have some thoughts on this matter, but perhaps
s/this document/[RFCXXXX]/ would reduce ambiguity.  If this change is
made, there would be similar/corresponding changes later on as well,
e.g., whenever the amended text includes a section reference to this
document, it would be "Section 2.1.3 of [RFCXXXX]".

Also, I think that both Sections 5.6 and 5.7 (not just 5.7) are marked
as applying to EAP-TLS in general.

  *  Early Data MUST NOT be used in EAP-TLS.  EAP-TLS servers MUST NOT
      send an early_data extension and clients MUST NOT send an
      EndOfEarlyData message.

Personally, I wouldn't include the last sentence, as both requirements
follow naturally from the previous requirement.  It feels a little
surprising to make reference to the specific message-level requirements
on the TLS stack, though I won't object to keeping this text if the
authors/WG find it important.

  *  Servers MUST NOT request post-handshake client authentication.

Do we want to make any statement about the client (not) sending the
"post_handshake_auth" extension (which the client must do as a
prerequisite of the server requesting post-handshake client
authentication)?

Section 2.1.1

                                            After the EAP-TLS server
  has sent an EAP-Request containing the TLS application data 0x00 and
  received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the
  EAP-TLS server sends EAP-Success.

I think in some sense the EAP-Server also needs to not have additional
TLS data do send in order to declare success and send EAP-Success.

Section 2.1.3

  full handshake.  In the case a full handshake is required, the
  negotiation proceeds as if the session was a new authentication, and
  resumption had never been requested.  [...]

I put a suggested alternative phrasing in my editorial PR, but wanted to
note the reasoning for the change in my ballot comment here.
"Had never been requested" is perhaps problematic in that the request
for resumption is encoded in the ClientHello, and to say that it had
never happened seems a little like suggesting that the ClientHello is
modified (which is not what happens).

  Figure 3 shows an example message flow for a subsequent successful
  EAP-TLS resumption handshake where both sides authenticate via a PSK
  provisioned via an earlier NewSessionTicket and where the server
  provisions a single new ticket.

I would suggest indicating that the TLS ClientHello includes the
"pre_shared_key" extension to help differentiate the resumption
handshake from the full handshake depicted in Figures 1/2.

  When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
  that key leakage does not compromise any earlier connections.  [...]

It's probably worth saying which key is leaked to trigger the "key
leakage" scenario being described.

Section 2.1.8

I might consider noting that the "hello_request" message doesn't exist
in TLS 1.3, so the RFC 5216 procedures are inherently inapplicable with
TLS 1.3.  On the other hand, that might be covered by the blanket
statement in §2.1, and thus unneeded here.

Section 2.2

  The EAP peer identity provided in the EAP-Response/Identity is not
  authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
  used for accounting purposes or to give authorization.  [...]

There's some analogous text in 5216 that talks about use for "accounting
purposes" or "access control" (at the SHOULD NOT level) -- is there a
reason to use/not use the same phrasing that 5216 did?

  (SAN) extension in the server certificate.  If any of the configured
  names match any of the names in the SAN extension then the name check
  passes.  [...]

It would be "more secure" in a specific technical sense if the
implementation could tie the configured acceptable name to the specific
CA (or CAs) that should have issued it, but I don't think current
implementations make this easy, and I also don't expect it to make a
practical difference in most real-world scenarios.  So the most I would
suggest would be to mention the possibility in the security
considerations section, and I'm not even sure that it's worth doing
that.

Section 2.3

  which provides a public API for the exporter.  Note that EAP-TLS with
  TLS 1.2 [RFC5216] can be used with the TLS exporter since the public
  exporter was defined in [RFC5705].

Is the intent to say that the TLS exporter-based formulae above will
produce the same result as (and thus, interoperate with) the PRF-based
formulae from RFC 5216?  I did not thoroughly check the equivalence, but
a quick check suggests that it exists.  If that is indeed the intent, I
would strongly suggest rephrasing to explicitly indicate the achieved
compatibility.

Section 2.5

  is not useful and not expected in EAP-TLS.  After sending TLS
  Finished, the EAP-TLS server may send any number of post-handshake
  messages in separate EAP-Requests.

I don't think there's a fundamental requirement that each post-handshake
message goes in a separate EAP-Request, as this text seems to imply.
For example, a TLS stack that produces two NewSessionTicket messages
after the handshake completes would release them at the same time, and
(size permitting) EAP could easily carry them in a single EAP-Request.

Section 5.1

We might incorporate the security considerations of RFC 8446 by
reference, though it's probably not critical to do so.

  [3] Cryptographic strength: TLS 1.3 only defines strong algorithms
  without major weaknesses and EAP-TLS with TLS 1.3 always provides
  forward secrecy, see [RFC8446].  Weak algorithms such as 3DES, CBC
  mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated.

I don't see anything in RFC 8446 to support the claim that 3DES cannot
be negotiated -- ciphers at the 112-bit strength level are permitted,
see D.5.  (But I also think I said this last time I balloted, so maybe I
just forgot what the response to my comment was...)

Section 5.3

The corresponding section of RFC 5216 does not reference RFC 6125 (which
is not surprising, given that it didn't exist at the time).  While I
don't see a strong need to provide an extensive analysis of how the RFC
6125 procedures relate to EAP usage, it does seem that RFC 6125 provides
some useful information for performing server certificate validation,
and that a brief reference might be appropriate.

Section 5.4

  To enable revocation checking in situations where EAP-TLS peers do
  not implement or use OCSP stapling, and where network connectivity is
  not available prior to authentication completion, EAP-TLS peer
  implementations MUST also support checking for certificate revocation
  after authentication completes and network connectivity is available.

I just want to confirm that both "peer[s]"s are intended to be "peer"s,
here.  I think it still makes sense this way, but "in cases where X do
not implement or use Y ... X implementations MUST also" is not a common
construction with both "X"es the same, so I wanted to check.

Section 5.7

  [RFC8446], where the EAP-TLS server avoids storing information
  locally and instead encapsulates the information into a ticket or PSK
  which is sent to the client for storage.  This ticket or PSK is
  encrypted using a key that only the EAP-TLS server knows.  Note that

I put this into my github PR, but just to note here: I don't think that
the "or PSK" is accurate in this scenario.

  If any authorization, accounting, or policy decisions were made with
  information that has changed between the initial full handshake and
  resumption, and if change may lead to a different decision, such
  decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
  accounting, and policy decisions are reevaluated based on the
  information given in the resumption.  [...]

Up in §2.2 we say that "unauthenticated information MUST NOT be used
for [...] authorization".  I'm not sure what scenarios you have in mind
where there is authenticated information that is changing between the
initial full handshake and the resumption -- when resumption succeeds,
won't basically all the authenticated information be from the original
full handshake?

Section 5.8

  static RSA based cipher suites without privacy.  This implies that an
  EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
  server sends an EAP-TLS/Request with a TLS alert message in response
  to an empty certificate message from the peer.

Is it really "continue the [TLS] handshake" or "continue the [EAP]
authentication attempt"?  My understanding was that the vulnerability
occurs when the peer initiates a new TLS handshake without attempting to
use privacy, which would otherwise be the behavior in response to the
described alert.

Section 5.10

  summarizes the attacks that were known at the time of publishing and
  BCP 195 [RFC7525] provides recommendations for improving the security

I'm not sure what the best XML syntax is for this, but BCP 195 also
includes RFC 8996, now (which we do cite, separately, at the end of this
paragraph).

Section 6.1

RFC 8126 could probably be classified as informative -- while we do say
that what we specify is compliant to it, the reader does not need to
read 8126 and validate that claim.

Why is RFC 8996 normative but RFC 7525 (the other half of BCP 195) only
informative?

Appendix A

I agree with the other reviewer that noted the different section
numbering between the old and new references; some acknowledgment of the
need to check section numbers seems in order.

[Ballot comment]
Thanks for working on this specification. This is certainly an important improvement.

I will have to acknowledge the observations form other reviewers about the diff style updates in the specifications and the potential consequences of that. However, I believe the working group have considered other alternatives and made a decision that suits better for the purpose.

I also support Francesca's observation about appendix A. It would be good be clear about the reference updates.

One nit - both Wi-Fi and WiFi are used in this document. I would suggest to stick with Wi-Fi.

[Ballot discuss]
Many thanks for the updates since the -13, the last version I reviewed.
I'm happy to report that the structural issues I noted in that version
have been addressed, and my new Discuss point is a fairly mundane one.

In several sections, we say that the text "updates Section X of
[RFC5216] by amending it with the following text", but I'm quite unclear
on exactly what that is intended to mean.  Are we adding to the end,
prepending to the beginning, replacing wholesale, replacing in part, or
doing something else to the indicated text of RFC 5216?  I expect that
just tweaking a few words can resolve the ambiguity, but am not sure
which ones yet.

It is also interesting to contrast the "amending" language with what we
say in Sections 2.1.4 and 2.3 about "replacing" text from RFC 5216 and
the various places where we report a "new section when compared to
[RFC5216]".

[Ballot comment]
I echo the sentiments of other reviewers that constructing EAP-TLS 1.3
as something of a diff against RFC 5216 will make it harder to
eventually deprecate/obsolete/etc RFC 5216 and makes it somewhat
challenging to read the EAP-TLS 1.3 specification as a whole.  That
said, this is just the comment section, so I am not strenuously
objecting to it.

As another general note, in many places the phrasings used to describe
TLS 1.3 behaviors feel rather un-idiomatic to me, based on my experience
with TLS and TLS specifications.  That said, the behavior seems
well-specified as is, so I don't propose to make any changes in response
to this comment.  If there is demand, I could probably be persuaded to
suggest alternative text, but I don't expect much demand at this stage
in the document's lifecycle.

I made a github PR with some editorial suggestions:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/92

Section 2.1

  This section updates Section 2.1 of [RFC5216] by amending it with the
  following text.
  [...]
  TLS 1.3 changes both the message flow and the handshake messages
  compared to earlier versions of TLS.  Therefore, much of Section 2.1
  of [RFC5216] does not apply for TLS 1.3.  Except for Sections 2.2 and
  5.7 this document applies only when TLS 1.3 is negotiated.  When TLS
  1.2 is negotiated, then [RFC5216] applies.

There is perhaps some philosophical question of what "this document"
means in the context of an updated collection of text that includes RFC
5216 and the text that is being amended as directed here.  I hope that
the RFC Editor will have some thoughts on this matter, but perhaps
s/this document/[RFCXXXX]/ would reduce ambiguity.  If this change is
made, there would be similar/corresponding changes later on as well,
e.g., whenever the amended text includes a section reference to this
document, it would be "Section 2.1.3 of [RFCXXXX]".

Also, I think that both Sections 5.6 and 5.7 (not just 5.7) are marked
as applying to EAP-TLS in general.

  *  Early Data MUST NOT be used in EAP-TLS.  EAP-TLS servers MUST NOT
      send an early_data extension and clients MUST NOT send an
      EndOfEarlyData message.

Personally, I wouldn't include the last sentence, as both requirements
follow naturally from the previous requirement.  It feels a little
surprising to make reference to the specific message-level requirements
on the TLS stack, though I won't object to keeping this text if the
authors/WG find it important.

  *  Servers MUST NOT request post-handshake client authentication.

Do we want to make any statement about the client (not) sending the
"post_handshake_auth" extension (which the client must do as a
prerequisite of the server requesting post-handshake client
authentication)?

Section 2.1.1

                                            After the EAP-TLS server
  has sent an EAP-Request containing the TLS application data 0x00 and
  received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the
  EAP-TLS server sends EAP-Success.

I think in some sense the EAP-Server also needs to not have additional
TLS data do send in order to declare success and send EAP-Success.

Section 2.1.3

  full handshake.  In the case a full handshake is required, the
  negotiation proceeds as if the session was a new authentication, and
  resumption had never been requested.  [...]

I put a suggested alternative phrasing in my editorial PR, but wanted to
note the reasoning for the change in my ballot comment here.
"Had never been requested" is perhaps problematic in that the request
for resumption is encoded in the ClientHello, and to say that it had
never happened seems a little like suggesting that the ClientHello is
modified (which is not what happens).

  Figure 3 shows an example message flow for a subsequent successful
  EAP-TLS resumption handshake where both sides authenticate via a PSK
  provisioned via an earlier NewSessionTicket and where the server
  provisions a single new ticket.

I would suggest indicating that the TLS ClientHello includes the
"pre_shared_key" extension to help differentiate the resumption
handshake from the full handshake depicted in Figures 1/2.

  When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
  that key leakage does not compromise any earlier connections.  [...]

It's probably worth saying which key is leaked to trigger the "key
leakage" scenario being described.

Section 2.1.8

I might consider noting that the "hello_request" message doesn't exist
in TLS 1.3, so the RFC 5216 procedures are inherently inapplicable with
TLS 1.3.  On the other hand, that might be covered by the blanket
statement in §2.1, and thus unneeded here.

Section 2.2

  The EAP peer identity provided in the EAP-Response/Identity is not
  authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
  used for accounting purposes or to give authorization.  [...]

There's some analogous text in 5216 that talks about use for "accounting
purposes" or "access control" (at the SHOULD NOT level) -- is there a
reason to use/not use the same phrasing that 5216 did?

  (SAN) extension in the server certificate.  If any of the configured
  names match any of the names in the SAN extension then the name check
  passes.  [...]

It would be "more secure" in a specific technical sense if the
implementation could tie the configured acceptable name to the specific
CA (or CAs) that should have issued it, but I don't think current
implementations make this easy, and I also don't expect it to make a
practical difference in most real-world scenarios.  So the most I would
suggest would be to mention the possibility in the security
considerations section, and I'm not even sure that it's worth doing
that.

Section 2.3

  which provides a public API for the exporter.  Note that EAP-TLS with
  TLS 1.2 [RFC5216] can be used with the TLS exporter since the public
  exporter was defined in [RFC5705].

Is the intent to say that the TLS exporter-based formulae above will
produce the same result as (and thus, interoperate with) the PRF-based
formulae from RFC 5216?  I did not thoroughly check the equivalence, but
a quick check suggests that it exists.  If that is indeed the intent, I
would strongly suggest rephrasing to explicitly indicate the achieved
compatibility.

Section 2.5

  is not useful and not expected in EAP-TLS.  After sending TLS
  Finished, the EAP-TLS server may send any number of post-handshake
  messages in separate EAP-Requests.

I don't think there's a fundamental requirement that each post-handshake
message goes in a separate EAP-Request, as this text seems to imply.
For example, a TLS stack that produces two NewSessionTicket messages
after the handshake completes would release them at the same time, and
(size permitting) EAP could easily carry them in a single EAP-Request.

Section 5.1

We might incorporate the security considerations of RFC 8446 by
reference, though it's probably not critical to do so.

  [3] Cryptographic strength: TLS 1.3 only defines strong algorithms
  without major weaknesses and EAP-TLS with TLS 1.3 always provides
  forward secrecy, see [RFC8446].  Weak algorithms such as 3DES, CBC
  mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated.

I don't see anything in RFC 8446 to support the claim that 3DES cannot
be negotiated -- ciphers at the 112-bit strength level are permitted,
see D.5.  (But I also think I said this last time I balloted, so maybe I
just forgot what the response to my comment was...)

Section 5.3

The corresponding section of RFC 5216 does not reference RFC 6125 (which
is not surprising, given that it didn't exist at the time).  While I
don't see a strong need to provide an extensive analysis of how the RFC
6125 procedures relate to EAP usage, it does seem that RFC 6125 provides
some useful information for performing server certificate validation,
and that a brief reference might be appropriate.

Section 5.4

  To enable revocation checking in situations where EAP-TLS peers do
  not implement or use OCSP stapling, and where network connectivity is
  not available prior to authentication completion, EAP-TLS peer
  implementations MUST also support checking for certificate revocation
  after authentication completes and network connectivity is available.

I just want to confirm that both "peer[s]"s are intended to be "peer"s,
here.  I think it still makes sense this way, but "in cases where X do
not implement or use Y ... X implementations MUST also" is not a common
construction with both "X"es the same, so I wanted to check.

Section 5.7

  [RFC8446], where the EAP-TLS server avoids storing information
  locally and instead encapsulates the information into a ticket or PSK
  which is sent to the client for storage.  This ticket or PSK is
  encrypted using a key that only the EAP-TLS server knows.  Note that

I put this into my github PR, but just to note here: I don't think that
the "or PSK" is accurate in this scenario.

  If any authorization, accounting, or policy decisions were made with
  information that has changed between the initial full handshake and
  resumption, and if change may lead to a different decision, such
  decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
  accounting, and policy decisions are reevaluated based on the
  information given in the resumption.  [...]

Up in §2.2 we say that "unauthenticated information MUST NOT be used
for [...] authorization".  I'm not sure what scenarios you have in mind
where there is authenticated information that is changing between the
initial full handshake and the resumption -- when resumption succeeds,
won't basically all the authenticated information be from the original
full handshake?

Section 5.8

  static RSA based cipher suites without privacy.  This implies that an
  EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
  server sends an EAP-TLS/Request with a TLS alert message in response
  to an empty certificate message from the peer.

Is it really "continue the [TLS] handshake" or "continue the [EAP]
authentication attempt"?  My understanding was that the vulnerability
occurs when the peer initiates a new TLS handshake without attempting to
use privacy, which would otherwise be the behavior in response to the
described alert.

Section 5.10

  summarizes the attacks that were known at the time of publishing and
  BCP 195 [RFC7525] provides recommendations for improving the security

I'm not sure what the best XML syntax is for this, but BCP 195 also
includes RFC 8996, now (which we do cite, separately, at the end of this
paragraph).

Section 6.1

RFC 8126 could probably be classified as informative -- while we do say
that what we specify is compliant to it, the reader does not need to
read 8126 and validate that claim.

Why is RFC 8996 normative but RFC 7525 (the other half of BCP 195) only
informative?

Appendix A

I agree with the other reviewer that noted the different section
numbering between the old and new references; some acknowledgment of the
need to check section numbers seems in order.

[Ballot comment]
Thank you for the work on this document. I only have one minor comment and a nit. Neither require replies strictly speaking, please feel free to address as you see fit.

Francesca

## minors

1. -----

  All the following references in [RFC5216] are updated as specified
  below when EAP-TLS is used with TLS 1.3.

  All references to [RFC2560] are updated with [RFC6960].

  All references to [RFC3280] are updated with [RFC5280].

  All references to [RFC4282] are updated with [RFC7542].

FP: I just want to double check everybody is ok with doing this type of update to the references: as the table of contents of these documents are not exactly the same, strictly speaking this could lead to some inaccuracies - for example RFC 5216 states:

  as a server certificate.  Implementations SHOULD use the Extended Key
  Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that

Section 4.2.1.13 of RFC 3280 is

                  4.2.1.13. CRL Distribution Points ..................45

Section 4.2.1.13 of RFC 5280 is

  4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40

This is not a big issue because the table of contents are mostly the same, but still requires the reader to be able to backtrack the right section (in this case, it would be 4.2.1.14)
(This is only an example, I haven't checked all occurrences of those references in RFC 5216).

## nits

2. -----

FP: s/shepard/shepherd

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1.4. , paragraph 4, nit:
-      server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and
-      no data from the EAP-TLS peer, follwed by EAP-Success from the
+      server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and
+                  +
+      no data from the EAP-TLS peer, followed by EAP-Success from the
+                                          +

Section 2.1. , paragraph 5, nit:
> t encrypt significant amounts of data so this functionality is not needed. I
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 2.1.7. , paragraph 3, nit:
> ods can use the TLS exporter in a similar fashion, see [I-D.ietf-emu-tls-eap-
>                              ^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 2.1.7. , paragraph 3, nit:
> o truncate the output by requesting less data from the TLS-Exporter function
>                                    ^^^^
Did you mean "fewer"? The noun data is countable.

Section 2.2. , paragraph 5, nit:
>  in EAP-TLS with TLS 1.3 is stronger as authentication with revoked certific
>                                      ^^
Comparison requires "than", not "then" nor "as".

Section 2.5. , paragraph 2, nit:
> ovide integrity and replay protection but MAY be unauthenticated. Protected f
>                                      ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 2.5. , paragraph 6, nit:
> dresses, IP addresses, port numbers, WiFi SSID, etc.). EAP-TLS servers implem
>                                      ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 4. , paragraph 4, nit:
>  layer. To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS
>                              ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.1. , paragraph 5, nit:
> e the session ID or PSK identity to lookup this information during resumption
>                                    ^^^^^^
The word "lookup" is a noun. The verb is spelled with a white space.

Section 5.1. , paragraph 6, nit:
> ached data cannot be retrieved in a secure way, resumption MUST NOT be done.
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.4. , paragraph 1, nit:
> e without access to cached data. Therefore systems which expect to perform a
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 5.4. , paragraph 6, nit:
>  do not contain any cleartext privacy sensitive information. Tracking of use
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.5. , paragraph 3, nit:
>  typically visible. How much privacy sensitive information the domain name l
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.6. , paragraph 3, nit:
> a cryptographically secure way so that that it is computationally infeasible
>                                  ^^^^^^^^^
Possible typo: you repeated a word.

Reference [RFC2560] to RFC2560, which was obsoleted by RFC6960 (this may be on
purpose).

Reference [RFC4282] to RFC4282, which was obsoleted by RFC7542 (this may be on
purpose).

Reference [RFC4346] to RFC4346, which was obsoleted by RFC5246 (this may be on
purpose).

Reference [RFC2246] to RFC2246, which was obsoleted by RFC4346 (this may be on
purpose).

Reference [RFC5077] to RFC5077, which was obsoleted by RFC8446 (this may be on
purpose).

Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Reference [RFC3280] to RFC3280, which was obsoleted by RFC5280 (this may be on
purpose).

Document references draft-ietf-tls-md5-sha1-deprecate-08, but -09 is the latest
available revision.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-emu-eap-tls13-20. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

two new registrations are to be made as follows:

Value: EXPORTER_EAP_TLS_Key_Material
DTLS-OK: N
Recommended: Y
Reference: [ RFC-to-be ]
Note:

Value: EXPORTER_EAP_TLS_Method-Id
DTLS-OK: N
Recommended: Y
Reference: [ RFC-to-be ]
Note:

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-20):

From: The IESG
To: IETF-Announce
CC: Joseph Salowey , draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, joe@salowey.net, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Extensible Authentication Protocol (EAP), defined in RFC 3748,
  provides a standard mechanism for support of multiple authentication
  methods.  This document specifies the use of EAP-Transport Layer
  Security (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 (EAP-TLS
  1.3) further improves security and privacy by always providing
  forward secrecy, never disclosing the peer identity, and by mandating
  use of revocation checking.  This document also provides guidance on
  authentication, authorization, and resumption for EAP-TLS in general
  (regardless of the underlying TLS version used).  This document
  updates RFC 5216.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document came back to the working group after some additional
reviews. The working group discussed, clarified and revised sections of the
document based on feedback from reviewers and implementers. 
There is in good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol.
At least two public implementations of the protocol are available:
wpa_supplicant - https://w1.fi/cgit/hostap/
free radius - https://github.com/FreeRADIUS/freeradius-server

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document had a lot of review and discussion.  There is in general
good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol.
At least two public implementations of the protocol are available:
wpa_supplicant - https://w1.fi/cgit/hostap/
free radius - https://github.com/FreeRADIUS/freeradius-server

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA

Based on comments and discussions from IESG review (https://mailarchive.ietf.org/arch/msg/emu/3ZFWAx0of-67P6yhtMIdmx9BLNs/), and in consultation with the WG chairs, this document is being returned back to the WG for issue resolution.

Based on comments and discussions from IESG review (https://mailarchive.ietf.org/arch/msg/emu/3ZFWAx0of-67P6yhtMIdmx9BLNs/), and in consultation with the WG chairs, this document is being returned back to the WG for issue resolution.

[Ballot comment]
As previously balloted in a discuss, I believe that the structure of this document will make it hard to obsolete RFC 5216 in the future, particularly when RFC 5246 eventually becomes historic.  Retrospectively, it would probably have been better to structure this document such that the specification replaces and obsoletes RFC 5246.

However, after discussion with the responsible AD, I agree that this would be a significant change to make at this late stage, and probably can be mitigated in future.

Regards,
Rob

[Ballot comment]
Section 2.1.3:

    “When NAI reuse can be done without privacy implications,
  it is RECOMMENDED to use the same anonymous NAI in the resumption, as
  was used in the original full authentication.  E.g. the NAI @realm
  can safely be reused, while the NAI ZmxleG8=@realm cannot.”

I think it would help to make this recommendation more specific. Does “without privacy implications” mean without the username part? Or does it mean something else?

Should this text reference RFC 7542 for further context?

Section 5.7:

“Where a good decision is unclear” —> “Where the decision is in doubt” (or something like that; it isn’t obvious what a “good” decision is)

[Ballot discuss]
Thank you for updating EAP to support TLS 1.3.

This document is outside my area of expertise, and others will be able to give a better technical review.

However, I do think that it would be useful to have a brief discussion with the authors/ADs about the structure of the document.  I.e., this document leaves RFC 5216 as an active updated RFC, although that RFC depends on TLS version 1.2 (RFC 5246) that is obsoleted by TLS 1.3.

I also note that this document contains 30 pages of updates to an RFC that is only 32 pages long.

Taking both of these into consideration, I think that it would be better (and longer term probably an easier reference) if this document could stand on its own, by obsoleting RFC 5216 and including any text from RFC 5216 that is still relevant when using EAP with TLS 1.3.

I appreciate that this would be a significant change and hence would welcome input from the authors and other ADs as to whether this change would be worth the effort.

Regards,
Rob

[Ballot comment]
[[ nits ]]

[ section 1 ]

* s/and and/and/

[ section 2.1.7 ]

* "Many client certificates contains" -> "Many client certificates contain"

[ section 5.4 ]

* s/EAP--TLS/EAP-TLS/

[ section 5.9 ]

* "In the context EAP-TLS" -> "In the context of EAP-TLS"?

[Ballot comment]
Some of these comments are a bit rough, as I did not do my full editing pass
since I plan to defer the ballot.  I'm including them anyway as they still
seem likely to be useful even in this form.

I strongly suggest that the option for the server to send an alert
instead of HelloRetryRequest in the case of missing "key_share" be
removed; see my comments on Section 2.1.3.  As far as I can tell this
option is flat-out bad practice and should not be allowed.

I also strongly suggest that the WG make the simple modification to the
key schedule that I suggest in my comments on Sections 2.3 and 5.5, that
would have the effect of achieving the property anticipated by Section
5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into
the key derivation formula prevents a type of packet modification
attack.

Abstract

  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

I agree with the secdir reviewer that some indication of what is meant
by (EAP) "privacy" here is likely in order.

Section 1

  In addition to the improved security and privacy offered by TLS 1.3,
  there are other significant benefits of using EAP-TLS with TLS 1.3.
  Privacy is mandatory and achieved without any additional round-trips,

(ditto)

Section 2.1.1

  for resumption.  SessionID is deprecated in TLS 1.3 and the EAP-TLS
  server SHALL ignore the legacy_session_id field if TLS 1.3 is
  negotiated.  TLS 1.3 introduced early application data which is not

(nit) we could perhaps quibble about whether "SHALL ignore" is
consistent with the RFC 8446 requirement to echo the legacy_session_id
value from the ClientHello in the ServerHello, though I'm not going to
make a big deal about it.

  used in EAP-TLS.  A EAP-TLS server which receives an "early_data"
  extension MUST ignore the extension or respond with a
  HelloRetryRequest as described in Section 4.2.10 of [RFC8446].

It's probably better to place restrictions on the indication that early
data might be possible, than to (just) place restrictions on accepting
it.  That is, if the server is forbidden from generating a
NewSessionTicket message that includes the "early_data" extension, then
the client is also forbidden from sending "early_data" in a ClientHello.
[ed. we do do this in §2.1.2]

Section 2.1.3

  full handshake.  It is left up to the EAP-TLS peer whether to use
  resumption, but it is RECOMMENDED that the EAP-TLS server accept
  resumption as long as the ticket is valid.  However, the EAP-TLS

But the EAP-TLS server sets how long the ticket is valid :)
Should we give some guidance on how long that should be (noting that it
must say within the RFC 8446-mandated 7 day maximum).

  was used in the original full authentication.  E.g. the NAI @realm
  can safely be reused, while the NAI ZmxleG8=@realm cannot.  The TLS

(Does base64("flexo") have enough randomness to be reflective of a good
privacy NAI?)

  A subsequent authentication using resumption, where both sides
  authenticate successfully (without the issuance of more resumption
  tickets) is shown in Figure 3.

(It's slightly surprising to show an example of resumption without
issuing additional resumption tickets, since such issuance is basically
necessary in order to comply with the recommendation from earlier in the
section to follow the client tracking prevention mechanisms in Appendix
C.4 of RFC 8446.  Though I guess draft-ietf-tls-ticketrequests is
potentially relevant for just how necessary it is going to be in
practice.)

  back to a full handshake.  If the EAP-TLS peer did not supply a
  "key_share" extension when attempting resumption, the EAP-TLS server
  needs to reject the ClientHello and the EAP-TLS peer needs to restart
  a full handshake.  The message flow in this case is given by Figure 4
  followed by Figure 1.

  Also during resumption, the EAP-TLS server can respond with a Hello
  Retry Request (see Section 2.1.6) or issue a new ticket (see
  Section 2.1.2)

I don't understand why the "alert plus fresh handshake" flow is even
listed as an option -- AFAICT the HelloRetryRequest (note: no spaces)
flow is uniformly superior.  There is no benefit in round-trip count to
starting a fresh handshake, and HelloRetryRequest allows the initial
interaction to be authenticated by the continued handshake transcript.
Aborting and starting over is analogous to the dreaded "downgrade dance"
that has periodically plagued the TLS ecosystem, and I'm confused that
we would consider encouraging it to return.  I would instead say that
the server "needs to send HelloRetryRequest to signal that additional
information is needed to complete the handshake, and the EAP-TLS peer
needs to send a second ClientHello containing that information" (or
similar), and drop the "Figure 4 followed by Figure 1" sentence.  (The
final paragraph would then become a bit redundant, but perhaps there is
still some information that should be persisted.)

Section 2.1.4

  The two paragraphs below replaces the corresponding paragraphs in
  Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
  higher.  The other paragraphs in Section 2.1.3 of [RFC5216] still
  apply with the exception that SessionID is deprecated.

      If the EAP-TLS peer authenticates successfully, the EAP-TLS server
      MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.  The message
      flow ends with the EAP-TLS server sending an EAP-Success message.

      If the EAP-TLS server authenticates successfully, the EAP-TLS peer
      MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.

Just to walk through the various scenarios here; if the last message of
the TLS handshake for a given TLS version is sent by the TLS client, that
will go in an EAP-Response, so the server is then able to send
EAP-Success directly.  On the other hand, if the last TLS handshake
message is sent by the server, that will have to go in an EAP-TLS
EAP-Request, and so the peer will have to send an empty EAP-TLS response
in order for the server to be able to wend EAP-Success?  Do we need to
have any text here to handle that empty EAP-TLS Eap-Request case?

  In the case where the EAP-TLS server rejects the ClientHello with a
  fatal error, the conversation will appear as shown in Figure 4.  The

Should we perhaps say that these examples are with TLS 1.3, even if the
actual normative protocol is no longer tied to a specific TLS version?

Section 2.1.5

In some sense, this figure depicting the no-peer-authentication case is
just an example specific to TLS 1.3 and is not necessarily
representative of the generic EAP-TLS case for potential future versions
of TLS.  Should we make that more clear from the prose?

Section 2.1.6

  the handshake.  One use case is if the EAP-TLS server does not
  support the groups in the "key_share" extension, but supports one of

I'd consider adding a parenthetical "(or there is no "key_share"
extension)".

Section 2.1.8

  username in cleartext in the Identity Response.  Following [RFC7542],
  it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
  other constructions such as a fixed username (e.g. anonymous@realm)
  or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note

(I note that YmVuZGVy is just base64("bender"); does that really count
as "encrypted"?)

Section 2.3

The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
is rather unusual; per RFC 8446 this value is intended to be a
"per-association context value provided by the application using the
exporter" per RFC 5705 -- this value is not a per-association value but
rather a global one.

Section 2.4

  While EAP-TLS does not protect any application data except for the
  Commitment Message, the negotiated cipher suites and algorithms MAY
  be used to secure data as done in other TLS-based EAP methods.

This makes me uncomfortable -- is this other data being secured going to
live in the same "namespace" as the Commitment Message?

Section 2.5

  and TLSPlaintext.fragment = 0x00).  Note that the length of the
  plaintext is greater than the corresponding TLSPlaintext.length due

(This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is
more clear?  But we shouldn't be saying this at all, per the Discuss.)

Section 5.1

  [2] Confidentiality: The TLS 1.3 handshake offers much better
  confidentiality than earlier versions of TLS by mandating cipher
  suites with confidentiality and encrypting certificates and some of
  the extensions, see [RFC8446].  When using EAP-TLS with TLS 1.3, the

I note that there exist codepoints for TLS 1.3 ciphersuites that do not
provide confidentiality protection.  Please point to the part of RFC
8446 that mandates this behavior.

  [3] Key strength: TLS 1.3 forbids all algorithms with known
  weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3

Where does RFC 8446 forbid 3DES?  CBC is forbidden by the requirement to
be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for
SHA-1 is more subtle.  Please reword this sentence to be accurate.

Section 5.4

  When EAP-TLS is used with TLS 1.3, the revocation status of all the
  certificates in the certificate chains MUST be checked.

What does this mandatory checking entail when a certificate contains
neither a CRL Distribution Point nor an OCSP responder URL?  (See also
the recent thread on the LAMPS WG list with Subject: "The
id-ce-noRevAvail extension".)

  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

RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be
preferred.  (RFC 4366 would then become an unused reference, I believe.)

  To enable revocation checking in situations where EAP-TLS peers do
  not implement or use OCSP stapling, and where network connectivity is
  not available prior to authentication completion, EAP--TLS 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.

If it's RECOMMENDED to use OCSP stapling, what does it mean that they
"SHOULD utilize this capability by default" (as well)?

(Also, nit: only one '-' in EAP-TLS.)

Section 5.5

It seems like there may be some scope for improvements on the RFC 5216
behavior here.  For example, what if we used the EAP Type field as the
TLS Exporter 'context' argument, instead of the literal 0x0D?  That
seems like it would prevent the modification from successfully causing a
different TLS-based EAP method to be used, by using a different
key-derivation formula, exactly as postulated by RFC 5126.

Section 5.7

  and the authorizations of the other party may have been reduced.  If
  the cached revocation is not sufficiently current, the EAP-TLS peer
  or EAP-TLS server MAY force a full TLS handshake.

nit: s/cached revocation/cached revocation data/

  in the certificate chain has been revoked or has expired.  In all
  such cases, resumption results in a full TLS handshake instead.

nit: s/resumption results/an attempt at resumption results/ (or similar)

  If any authorization, accounting, or policy decisions were made with
  information that have changed between the initial full handshake and
  resumption, and if change may lead to a different decision, such
  decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
  accounting, and policy decisions are reevaluated based on the
  information given in the resumption.  [...]

I'm not sure I understand how these two sentences fit together.  Is it
trying to say that "if there could be a different decision, you
definitly have to re-check, and we recommend just always re-checking
since that's timpler"?

  Where a good decision is unclear, EAP-TLS servers SHOULD reject the
  resumption.

I suggest "reject the assumption and continue with a full handshake".

  Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
  considerations for resumption.

I'm curious why specifically § 8.1 and 8.2 were selected, given that §8
as a whole is about "0-RTT and Anti-Replay", which is a more specific
topic than just resumption.

Section 5.8

  Tracking of users by eavesdropping on identity responses or
  certificates is a well-known problem in many EAP methods.  When EAP-
  TLS is used with TLS 1.3, all certificates are encrypted, and the
  username part of the identity response is always confidentiality
  protected (e.g. using anonymous NAIs).  [...]

As written this applies to server certificates as well as TLS client
certificates.  For which the statement is technically true, but with the
caveat that it is typically easy to persuade the server to (re-)send
those same certificates encrypted to a key known to the attacker, so the
protection provided by the encryption is limited.  (The server has been
fairly strongly authenticated by the time the EAP peer makes the
decision to send its certificate, so there the reverse situation is
different.)

  and only using the pseudo-random usernames a single time.  Note that
  the privacy-friendly usernames also MUST NOT include substrings that
  can be used to relate the identity to a specific user.  Similarly,
  privacy-friendly username SHOULD NOT be formed by a fixed mapping
  that stays the same across multiple different authentications.

I think that violating the SHOULD NOT would intrinsically violate the
preceding MUST NOT ... so should they both be MUST NOTs?

  static RSA based cipher suites without privacy.  This implies that an
  EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
  server responds to an empty certificate message with a TLS alert
  message.

Just to check my understanding, this "response" would be an EAP-TLS
response containing a new ClientHello (that would proceed to do a
handshake including the client certificate in the unprotected initial
handshake)?  That is, it would be a response at the EAP layer but not at
the TLS layer.

Section 5.9

  Pervasive monitoring refers to widespread surveillance of users.  In
  the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS

nit: "context of"

Section 5.10

  summarizes the attacks that were known at the time of publishing and
  [RFC7525] provides recommendations for improving the security of
  deployed services that use TLS.  However, many of the attacks are

Using BCP195 as the slug is probably preferred, since any RFCs
associated with the BCP are going to be relevant and topical.

[Ballot discuss]
I'm going to defer this document's evaluation because I think there are
several interrelated subtle issues that merit closer consideration than
has been given so far.  I will also invite the TLS WG to provide input
on these issues, since they relate to rather fundamental issues of the
operation of the TLS sub-protocols.

Most of them concern the Commitment Message, in terms of what goals it
aims to achieve, how it is specified, and what mechanism is used to
effectuate it.

To start with the easy one: currently the way in which the structure of
the Commitment Message is described makes reference to many fields of
TLS Record Layer structures in order to specify what is fundamentally a
message on the TLS Application Data stream.  This is a layering
violation; I don't see any reason to say more than what was suggested in
https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ :
"the commit[ment] message is a single byte of [value] 0 in the application data
stream".  All the bits about cryptographic protection and expansion of the
plaintext in prepararation for record protection are just adding noise,
and the interface between the TLS stack and the application is supposed
to be a data-stream abstraction, not a record abstraction.

Next, the whole reason for the existence of a Commitment Message seems
under-justified -- the only mention I could find in the document is that
it serves "to decrease the uncertainty for the EAP-TLS peer".  What harm
would be caused by a lack of certainty in this area?  Why does waiting
for an EAP-Success or EAP-Failure not provide a similar level of
certainty?

The document also suggests in several places that the Commitment Message
can or should be sent at 0.5-RTT data in the same flight as the server
Finished.  The intent, as determined from the mailing list archive,
seems to be to save a round-trip compared to a typical full message flow
where the server does not send application data until after the client's
Finished (and any application data alongside it) is received.  In
particular, this came out during discussion of how a TLS "close_notify"
alert would be unsuitable for the role of the Commitment Message, since
sending the "close_notify" in 0.5-RTT would prevent sending an alert if
the client authentication failed, and the diagnostic value of such
alerts is significant.  This is where the issues start to become
interrelated -- the Commitment Message as a new application-data
construct is for the objective of reducing the number of round trips.
However, TLS session resumption is also designed to reduce the number of
round-trips (including by no longer needing to send potentially large
TLS Certificate messages that get fragmented at the EAP layer, with the
cost of a round trip per fragment), and there is a nasty interaction
between the two mechanisms.  Specifically, TLS 1.3 session resumption
requires the use of a NewSessionTicket message, which is associated with
a resumption secret; the resumption secret, in turn, is not available in
the key schedule until the client Finished (and client authentication
messages, if any) is available.  While it is possible in many Web
scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this
is because the server can precompute what the valid client Finished
would be and use that in the key schedule to precompute the resumption
secret.  If the client is to be authenticated, as is the case for the
vast majority of EAP exchanges, then such precomputation is impossible,
and the session ticket cannot be issued until the extra round trip is
completed.  The document contains no discussion of the inherent tradeoff
between sending the commitment message in 0.5-RTT and using resumption,
and this tradeoff seems to call into question the merits of choosing
this mechanism to implement the commitment message, since...

The commitment message as specified seems to itself be a layering
violation.  The TLS protocol itself consists of a few sub-protocols,
e.g., the handshake protocol, record protocol, and alert protocol.  The
operation of the handshake protocol is supposed to be completely
independent of the application-data record protocol (except to the
extent that the handshake protocol supplies the keys used for
cryptographic protection of application data records).  In particular,
there should not be any interaction between the handshake state machine
and the application data.  If there is to be a commitment made about the
operation of the TLS handshake protocol, that more properly belongs in
the handshake layer itself, or perhaps the alert layer if it relates to
the overall operation of the TLS connection.  It seems inappropriate and
unsustainable to expect that an application-data message would affect
the operation of the handshake layer.

The use of application data for the commitment message also may have
unfortunate interactions with other TLS-using EAP methods, which is very
briefly mentioned as a possibility but not explored at all:

  While EAP-TLS does not protect any application data except for the
  Commitment Message, the negotiated cipher suites and algorithms MAY
  be used to secure data as done in other TLS-based EAP methods.

If we are to expect this construction of commitment message to become
the de facto standard for using TLS 1.3 with EAP, I think we need to
consider whether other EAP methods that do need to actually protect
application data with the TLS connection will be affected by this
proposal to insert the EAP commitment message into the application data
stream.  This is worth particular consideration given that we require
that "EAP-TLS peer implementations MUST accept any application data as a
Commitment Message from the EAP-TLS server to not send any more
handshake messages" -- these seem like new semantics that might be quite
unexpected if applied to other EAP methods.

There's also a few internal inconsistencies that raise to a
discuss-level and will need to be resolved before publication:

The body text around Figure 3 indicates that mutual authentication
should be depicted, but the figure shows only normal server-only
authentication.

The example in Figure 8 needs a TLS CertificateRequest in there in order
for the rest of the flow to make sense.

Section 2.1.4 says that "TLS warning alerts generally mean that the
connection can continue normally and does not change the message flow."
but this is no longer true with TLS 1.3 -- the only alerts sent at
warning level are "close_notify" and "user_cancelled", both of which
indicate that the connection is not going to continue normally.

Section 2.1.9 claims that the largest size of a TLS record is 16387
octets, but by my count a TLSCiphertext can get up to 16643, since the
length field "MUST NOT exceed 2^14 + 256 bytes" (and there's the other 3
bytes of header).

Please also check the statements made about RFC 8446 that I note in my
comments on Section 5.1.

[Ballot comment]
I strongly suggest that the option for the server to send an alert
instead of HelloRetryRequest in the case of missing "key_share" be
removed; see my comments on Section 2.1.3.  As far as I can tell this
option is flat-out bad practice and should not be allowed.

I also strongly suggest that the WG make the simple modification to the
key schedule that I suggest in my comments on Sections 2.3 and 5.5, that
would have the effect of achieving the property anticipated by Section
5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into
the key derivation formula prevents a type of packet modification
attack.

Abstract

  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

I agree with the secdir reviewer that some indication of what is meant
by (EAP) "privacy" here is likely in order.

Section 1

  In addition to the improved security and privacy offered by TLS 1.3,
  there are other significant benefits of using EAP-TLS with TLS 1.3.
  Privacy is mandatory and achieved without any additional round-trips,

(ditto)

Section 2.1.1

  for resumption.  SessionID is deprecated in TLS 1.3 and the EAP-TLS
  server SHALL ignore the legacy_session_id field if TLS 1.3 is
  negotiated.  TLS 1.3 introduced early application data which is not

(nit) we could perhaps quibble about whether "SHALL ignore" is
consistent with the RFC 8446 requirement to echo the legacy_session_id
value from the ClientHello in the ServerHello, though I'm not going to
make a big deal about it.

  used in EAP-TLS.  A EAP-TLS server which receives an "early_data"
  extension MUST ignore the extension or respond with a
  HelloRetryRequest as described in Section 4.2.10 of [RFC8446].

It's probably better to place restrictions on the indication that early
data might be possible, than to (just) place restrictions on accepting
it.  That is, if the server is forbidden from generating a
NewSessionTicket message that includes the "early_data" extension, then
the client is also forbidden from sending "early_data" in a ClientHello.
[ed. we do do this in §2.1.2]

Section 2.1.3

  full handshake.  It is left up to the EAP-TLS peer whether to use
  resumption, but it is RECOMMENDED that the EAP-TLS server accept
  resumption as long as the ticket is valid.  However, the EAP-TLS

But the EAP-TLS server sets how long the ticket is valid :)
Should we give some guidance on how long that should be (noting that it
must say within the RFC 8446-mandated 7 day maximum).

  was used in the original full authentication.  E.g. the NAI @realm
  can safely be reused, while the NAI ZmxleG8=@realm cannot.  The TLS

(Does base64("flexo") have enough randomness to be reflective of a good
privacy NAI?)

  A subsequent authentication using resumption, where both sides
  authenticate successfully (without the issuance of more resumption
  tickets) is shown in Figure 3.

(It's slightly surprising to show an example of resumption without
issuing additional resumption tickets, since such issuance is basically
necessary in order to comply with the recommendation from earlier in the
section to follow the client tracking prevention mechanisms in Appendix
C.4 of RFC 8446.  Though I guess draft-ietf-tls-ticketrequests is
potentially relevant for just how necessary it is going to be in
practice.)

  back to a full handshake.  If the EAP-TLS peer did not supply a
  "key_share" extension when attempting resumption, the EAP-TLS server
  needs to reject the ClientHello and the EAP-TLS peer needs to restart
  a full handshake.  The message flow in this case is given by Figure 4
  followed by Figure 1.

  Also during resumption, the EAP-TLS server can respond with a Hello
  Retry Request (see Section 2.1.6) or issue a new ticket (see
  Section 2.1.2)

I don't understand why the "alert plus fresh handshake" flow is even
listed as an option -- AFAICT the HelloRetryRequest (note: no spaces)
flow is uniformly superior.  There is no benefit in round-trip count to
starting a fresh handshake, and HelloRetryRequest allows the initial
interaction to be authenticated by the continued handshake transcript.
Aborting and starting over is analogous to the dreaded "downgrade dance"
that has periodically plagued the TLS ecosystem, and I'm confused that
we would consider encouraging it to return.  I would instead say that
the server "needs to send HelloRetryRequest to signal that additional
information is needed to complete the handshake, and the EAP-TLS peer
needs to send a second ClientHello containing that information" (or
similar), and drop the "Figure 4 followed by Figure 1" sentence.  (The
final paragraph would then become a bit redundant, but perhaps there is
still some information that should be persisted.)

Section 2.1.4

  The two paragraphs below replaces the corresponding paragraphs in
  Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
  higher.  The other paragraphs in Section 2.1.3 of [RFC5216] still
  apply with the exception that SessionID is deprecated.

      If the EAP-TLS peer authenticates successfully, the EAP-TLS server
      MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.  The message
      flow ends with the EAP-TLS server sending an EAP-Success message.

      If the EAP-TLS server authenticates successfully, the EAP-TLS peer
      MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
      TLS records conforming to the version of TLS used.

Just to walk through the various scenarios here; if the last message of
the TLS handshake for a given TLS version is sent by the TLS client, that
will go in an EAP-Response, so the server is then able to send
EAP-Success directly.  On the other hand, if the last TLS handshake
message is sent by the server, that will have to go in an EAP-TLS
EAP-Request, and so the peer will have to send an empty EAP-TLS response
in order for the server to be able to wend EAP-Success?  Do we need to
have any text here to handle that empty EAP-TLS Eap-Request case?

  In the case where the EAP-TLS server rejects the ClientHello with a
  fatal error, the conversation will appear as shown in Figure 4.  The

Should we perhaps say that these examples are with TLS 1.3, even if the
actual normative protocol is no longer tied to a specific TLS version?

Section 2.1.5

In some sense, this figure depicting the no-peer-authentication case is
just an example specific to TLS 1.3 and is not necessarily
representative of the generic EAP-TLS case for potential future versions
of TLS.  Should we make that more clear from the prose?

Section 2.1.6

  the handshake.  One use case is if the EAP-TLS server does not
  support the groups in the "key_share" extension, but supports one of

I'd consider adding a parenthetical "(or there is no "key_share"
extension)".

Section 2.1.8

  username in cleartext in the Identity Response.  Following [RFC7542],
  it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
  other constructions such as a fixed username (e.g. anonymous@realm)
  or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note

(I note that YmVuZGVy is just base64("bender"); does that really count
as "encrypted"?)

Section 2.3

The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
is rather unusual; per RFC 8446 this value is intended to be a
"per-association context value provided by the application using the
exporter" per RFC 5705 -- this value is not a per-association value but
rather a global one.

Section 2.4

  While EAP-TLS does not protect any application data except for the
  Commitment Message, the negotiated cipher suites and algorithms MAY
  be used to secure data as done in other TLS-based EAP methods.

This makes me uncomfortable -- is this other data being secured going to
live in the same "namespace" as the Commitment Message?

Section 2.5

  and TLSPlaintext.fragment = 0x00).  Note that the length of the
  plaintext is greater than the corresponding TLSPlaintext.length due

(This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is
more clear?  But we shouldn't be saying this at all, per the Discuss.)

Section 5.1

  [2] Confidentiality: The TLS 1.3 handshake offers much better
  confidentiality than earlier versions of TLS by mandating cipher
  suites with confidentiality and encrypting certificates and some of
  the extensions, see [RFC8446].  When using EAP-TLS with TLS 1.3, the

I note that there exist codepoints for TLS 1.3 ciphersuites that do not
provide confidentiality protection.  Please point to the part of RFC
8446 that mandates this behavior.

  [3] Key strength: TLS 1.3 forbids all algorithms with known
  weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3

Where does RFC 8446 forbid 3DES?  CBC is forbidden by the requirement to
be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for
SHA-1 is more subtle.  Please reword this sentence to be accurate.

Section 5.4

  When EAP-TLS is used with TLS 1.3, the revocation status of all the
  certificates in the certificate chains MUST be checked.

What does this mandatory checking entail when a certificate contains
neither a CRL Distribution Point nor an OCSP responder URL?  (See also
the recent thread on the LAMPS WG list with Subject: "The
id-ce-noRevAvail extension".)

  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

RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be
preferred.  (RFC 4366 would then become an unused reference, I believe.)

  To enable revocation checking in situations where EAP-TLS peers do
  not implement or use OCSP stapling, and where network connectivity is
  not available prior to authentication completion, EAP--TLS 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.

If it's RECOMMENDED to use OCSP stapling, what does it mean that they
"SHOULD utilize this capability by default" (as well)?

(Also, nit: only one '-' in EAP-TLS.)

Section 5.5

It seems like there may be some scope for improvements on the RFC 5216
behavior here.  For example, what if we used the EAP Type field as the
TLS Exporter 'context' argument, instead of the literal 0x0D?  That
seems like it would prevent the modification from successfully causing a
different TLS-based EAP method to be used, by using a different
key-derivation formula, exactly as postulated by RFC 5126.

Section 5.7

  and the authorizations of the other party may have been reduced.  If
  the cached revocation is not sufficiently current, the EAP-TLS peer
  or EAP-TLS server MAY force a full TLS handshake.

nit: s/cached revocation/cached revocation data/

  in the certificate chain has been revoked or has expired.  In all
  such cases, resumption results in a full TLS handshake instead.

nit: s/resumption results/an attempt at resumption results/ (or similar)

  If any authorization, accounting, or policy decisions were made with
  information that have changed between the initial full handshake and
  resumption, and if change may lead to a different decision, such
  decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
  accounting, and policy decisions are reevaluated based on the
  information given in the resumption.  [...]

I'm not sure I understand how these two sentences fit together.  Is it
trying to say that "if there could be a different decision, you
definitly have to re-check, and we recommend just always re-checking
since that's timpler"?

  Where a good decision is unclear, EAP-TLS servers SHOULD reject the
  resumption.

I suggest "reject the assumption and continue with a full handshake".

  Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
  considerations for resumption.

I'm curious why specifically § 8.1 and 8.2 were selected, given that §8
as a whole is about "0-RTT and Anti-Replay", which is a more specific
topic than just resumption.

Section 5.8

  Tracking of users by eavesdropping on identity responses or
  certificates is a well-known problem in many EAP methods.  When EAP-
  TLS is used with TLS 1.3, all certificates are encrypted, and the
  username part of the identity response is always confidentiality
  protected (e.g. using anonymous NAIs).  [...]

As written this applies to server certificates as well as TLS client
certificates.  For which the statement is technically true, but with the
caveat that it is typically easy to persuade the server to (re-)send
those same certificates encrypted to a key known to the attacker, so the
protection provided by the encryption is limited.  (The server has been
fairly strongly authenticated by the time the EAP peer makes the
decision to send its certificate, so there the reverse situation is
different.)

  and only using the pseudo-random usernames a single time.  Note that
  the privacy-friendly usernames also MUST NOT include substrings that
  can be used to relate the identity to a specific user.  Similarly,
  privacy-friendly username SHOULD NOT be formed by a fixed mapping
  that stays the same across multiple different authentications.

I think that violating the SHOULD NOT would intrinsically violate the
preceding MUST NOT ... so should they both be MUST NOTs?

  static RSA based cipher suites without privacy.  This implies that an
  EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
  server responds to an empty certificate message with a TLS alert
  message.

Just to check my understanding, this "response" would be an EAP-TLS
response containing a new ClientHello (that would proceed to do a
handshake including the client certificate in the unprotected initial
handshake)?  That is, it would be a response at the EAP layer but not at
the TLS layer.

Section 5.9

  Pervasive monitoring refers to widespread surveillance of users.  In
  the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS

nit: "context of"

Section 5.10

  summarizes the attacks that were known at the time of publishing and
  [RFC7525] provides recommendations for improving the security of
  deployed services that use TLS.  However, many of the attacks are

Using BCP195 as the slug is probably preferred, since any RFCs
associated with the BCP are going to be relevant and topical.

[Ballot comment]
Is the intention of the Appendix to provide additional formal updates to rfc5216?  That is what it looks like to me, but there's no reference to it from the main text.  Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent.

[Ballot comment]
Thank you for the work put into this document. Improving EAP-TLS is indeed welcome! BTW, I left the security review to the SEC Area Directors.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Should the abstract briefly talk about EAP?

-- Section 1 --
Should "ietf-tls-oldversions-deprecate" be normative ?

-- Section 2 --
Nicely done to have kept the same sub-section numbers with respect to RFC 5216. Kudos !

-- Section 2.1.1 & 2.1.3 & 2.1.4 --
I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ?

-- Section 5.9 --
What is the added benefit of this section (pervasive monitoring) compared to section 5.8 (privacy considerations)? Esp when I am afraid that pervasive monitoring is deeper in the network rather than in the access network (happy to be corrected)

== NITS ==

None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-emu-eap-tls13-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the TLS Exporter Labels on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

three new labels are to be added:

EXPORTER_EAP_TLS_Key_Material
EXPORTER_EAP_TLS_IV
EXPORTER_EAP_TLS_Method-Id

IANA Question --> For each of these three registrations, IANA requests that the authors supply the remainder of the fields needed to complete the registrations in an updated version of this document. The fields to be supplied are:

DTLS-OK:
Recommended:
Note:

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-29):

From: The IESG
To: IETF-Announce
CC: emu@ietf.org, joe@salowey.net, draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, rdd@cert.org, Joseph Salowey
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using EAP-TLS with TLS 1.3) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Using EAP-TLS with TLS 1.3'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document had a lot of review and discussion.  There is in general
good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol.
At least two public implementations of the protocol are available:
wpa_supplicant - https://w1.fi/cgit/hostap/
free radius - https://github.com/FreeRADIUS/freeradius-server

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA

PCE Working Group                                            Xian Zhang
Internet-Draft                                      Young Lee (Editor)
Intended status: Standards Track                            Fatai Zhang
                                                                Huawei
                                                        Ramon Casellas
                                                                  CTTC
                                                Oscar Gonzalez de Dios
                                                        Telefonica I+D
                                                              Zafar Ali
                                                          Cisco Systems

Expires: August 13, 2018                              February 13, 2018

  Path Computation Element (PCE) Protocol Extensions for Stateful PCE
                  Usage in GMPLS-controlled Networks

              draft-ietf-pce-pcep-stateful-pce-gmpls-07.txt

Abstract

  The Path Computation Element (PCE) facilitates Traffic Engineering
  (TE) based path calculation in large, multi-domain, multi-region, or
  multi-layer networks. The PCE communication Protocol (PCEP) has been
  extended to support stateful PCE functions where the PCE retains
  information about the paths already present in the network, but
  those extensions are technology-agnostic. This memo provides
  extensions required for PCEP so as to enable the usage of a stateful
  PCE capability in GMPLS-controlled networks.

Status of this Memo

  This Internet-Draft is submitted to IETF in full conformance with
  the provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months  and may be updated, replaced, or obsoleted by other
  documents at any  time.  It is inappropriate to use Internet-Drafts

Zhang et al              Expires August 2018                  [Page 1]
Internet-Draft        Stateful PCEP for GMPLS            February 2018

  as reference  material or to cite them other than as "work in
  progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

  This Internet-Draft will expire on August 13, 2018.

Copyright Notice

  Copyright (c) 2018 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document. Please review these documents
  carefully, as they describe your rights and restrictions with
  respect to this document. Code Components extracted from this
  document must include Simplified BSD License text as described in
  Section 4.e of the Trust Legal Provisions and are provided without
  warranty as described in the Simplified BSD License.

Conventions used in this document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

  Table of Contents.................................................2
  1. Introduction...................................................3
  2. Context of Stateful PCE and PCE for GMPLS......................3
  3. Main Requirements..............................................4
  4. PCEP Extensions................................................5
      4.1. LSP Update in GMPLS-controlled Networks...................5
      4.2. LSP Synchronization in GMPLS-controlled Networks..........5
      4.3. Modification of Existing PCEP Messages and Procedures.....7
        4.3.1. Modification for LSP Re-optimization.................7
        4.3.2. Modification for Route Exclusion.....................7
      4.4. Object Encoding...........................................9

Zhang et al              Expires August 2018                  [Page 2]
Internet-Draft        Stateful PCEP for GMPLS            February 2018

  5. IANA Considerations............................................9
      5.1. New PCEP Error Codes......................................9
      5.2. New Subobject for the Exclude Route Object................9
  6. Manageability Considerations..................................10
      6.1. Requirements on Other Protocols and Functional Components10
  7. Security Considerations.......................................10
  8. Acknowledgement...............................................10
  9. References....................................................10
      9.1. Normative References.....................................10
      9.2. Informative References...................................11
  10. Contributors' Address........................................11
  Authors' Addresses...............................................12

1. Introduction

  [RFC4655] presents the architecture of a Path Computation Element
  (PCE)-based model for computing Multiprotocol Label Switching (MPLS)
  and Generalized MPLS (GMPLS) Traffic Engineering Label Switched
  Paths (TE LSPs).  To perform such a constrained computation, a PCE
  stores the network topology (i.e., TE links and nodes) and resource
  information (i.e., TE attributes) in its TE Database (TED).  Such a
  PCE is usually referred as a stateless PCE. To request path
  computation services to a PCE, [RFC5440] defines the PCE
  communication Protocol (PCEP) for interaction between a Path
  Computation Client (PCC) and a PCE, or between two PCEs.  PCEP as
  specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP
  extensions needed for GMPLS-controlled networks are provided in
  [PCEP-GMPLS].

  Stateful PCEs are shown to be helpful in many application scenarios,
  in both MPLS and GMPLS networks, as illustrated in [RFC8051].
  Further discussion of concept of a stateful PCE can be found in
  [RFC7399].  In order for these applications to able to exploit the
  capability of stateful PCEs, extensions to PCEP are required.

  [RFC8231] provides the fundamental extensions needed for stateful
  PCE to support general functionality, but leaves out the
  specification for technology-specific objects/TLVs. This document
  focuses on the extensions that are necessary in order for the
  deployment of stateful PCEs in GMPLS-controlled networks.

2. Context of Stateful PCE and PCEP for GMPLS

  This document is built on the basis of Stateful PCE [RFC8231] and
  PCEP for GMPLS [PCEP-GMPLS].

Zhang et al              Expires August 2018                  [Page 3]
Internet-Draft        Stateful PCEP for GMPLS            February 2018

  There are two types of LSP operation for Stateful PCE.

  For Active Stateful PCE, PCUpd message is sent from PCE to PCC to
  update the LSP state for the LSP delegated to PCE. Any changes to
  the delegated LSPs generate a PCRpt message by the PCC to PCE to
  convey the changes of the LSP. Any modifications to the Objects/TLVs
  that are identified in this document to support GMPLS technology-
  specific attributes will be carried in the PCRpt and PCUpd messages.

  For Passive Stateful PCE where PCReq/PCRep messages are used to
  convey path computation instruction. As GMPLS-technology specific
  Objects/TLVs are defined in [PCEP-GMPLS], this document just points
  to the work in [PCEP-GMPLS] and add only the stateful PCE aspect
  only if applicable. Passive Stateful PCE makes use of PCRep messages
  when reporting LSP State changes sent by PCC to PCEs. Any
  modifications to the Objects/TLVs that are identified in this
  document to support GMPLS technology-specific attributes will be
  carried in the PCRpt message.

  [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this
  document makes use of these Objects/TLVs without modifications where
  applicable. Some of these Objects/TLVs may require modifications to
  incorporate stateful PCE element where applicable.

3. Main Requirements

  This section notes the main functional requirements for PCEP
  extensions to support stateful PCE for use in GMPLS-controlled
  networks, based on the description in [RFC8051].  Many
  requirements are common across a variety of network types (e.g.,
  MPLS-TE networks and GMPLS networks) and the protocol extensions to
  meet the requirements are already described in [RFC8231].  This
  document does not repeat the description of those protocol
  extensions.  This document presents protocol extensions for a set of
  requirements which are specific to the use of a stateful PCE in a
  GMPLS-controlled network.

  The basic requirements are as follows:

  o  Advertisement of the stateful PCE capability.  This generic
    requirement is covered in Section 5.7. of [RFC8231].  This
    document does not provide any further extensions.

  o  LSP delegation is already covered in Section 5.7. of [RFC8231].
    Section 2.2. of this document does not provide any further
    extensions.

Zhang et al              Expires August 2018                  [Page 4]
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document had a lot of review and discussion.  There is in general
good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol.
At least two public implementations of the protocol are available:
wpa_supplicant - https://w1.fi/cgit/hostap/
free radius - https://github.com/FreeRADIUS/freeradius-server

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document had a lot of review and discussion.  There is in general
good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard because it is specify a revision to a protocol that is on standards track that is widely implemented.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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 updates RFC 5216.

Working Group Summary:

The document had a lot of review and discussion.  There is in general
good consensus for moving the document forward.

Document Quality:

Much of the discussion on the list was based on comments from implemented
of the previous version of the protocol or the proposed version of the protocol

Personnel:

Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

TBD

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus with the WG as a whole,

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are references to obsoleted documents that are intentional to discuss changes in behavior of the protocol.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will update RFC 5216.  This is included in the header, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
NA