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

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

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

I support Rob's DISCUSS position.

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.

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

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)

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.

I found this to be exceptionally well written and clear.  Thanks for the great work on this!

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.

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.

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