Subject: [Emu] draft-ietf-emu-eap-tls13-16.txt

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jun 2021 09:38:08 -0400

Some comments have been addressed, others not.  The majority of the issues raised in my review have been silently ignored.  Some issues are nits, some affect interoperability and security.

  Until these issues are addressed, the document is insufficient to guide a reader into creating a secure and inter-operable implementation.

Unaddressed without any comment or discussion:

> Section 1 says:
> 
>  While this document updates EAP-TLS [RFC5216], it
>  remains backwards compatible with it and existing implementations of
>  EAP-TLS. 
> 
> Other than the abstract, this is the only reference to EAP-TLS 1.3
> being backwards compatible with older versions of EAP-TLS.  This
> compatibility is simply asserted, with no further explanation given.
> 
> Q: What does "backwards compatible" mean?  How is it achieved?
> 
> Suggestion: add text explaining how it is backwards compatible.  How
> will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
> update Section 2.1 with text indicating that TLS version negotiation
> is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically
> leverage that capability.
> 
> 
> Section 2.1.1 says:
> 
>  TLS 1.3 introduced the Post-Handshake KeyUpdate
>  message which is not useful and not expected in EAP-TLS. 
> 
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.
> 
> Suggestion: If there is no use for KeyUpdate messages, then mandate
> that it SHOULD be ignored, or perhaps connections which use KeyUpdate
> MUST be closed without updating the keys.  OpenSSL as APIs to
> determine the status of key updates, so this suggestion is
> implementable.

  Addressed:

> Section 2.1.3 says this about the session ticket:
> 
>  ... If the EAP-TLS server
>  accepts it, then the security context of the new connection is tied
>  to the original connection and the key derived from the initial
>  handshake is used to bootstrap the cryptographic state instead of a
>  full handshake. 
> 
> Nit: This the the only reference to "bootstrap the cryptographic
> state" in this document.  This text seems like an unnecessary
> repetition of RFC 8446 Section 2.2.
> 
> Suggestion: Perhaps say instead
> 
>  ... If the EAP-TLS server
>  accepts it, then the resumed session has been deemed to be
>  authenticated, and securely associated with the prior authentication
>  or resumption.
> 
> 
> Section 2.1.4
> 
>   In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
>   fatal error condition.  Failure to send TLS Error alerts means that
>   the peer or server would have no way of determining what went wrong.
>   EAP-TLS 1.3 strengthen this requirement. 
> 
> NIT: strengthenS this requirement.

Unaddressed without any comment or discussion:

> Section 2.1.5 is essentially empty.
> 
> Is there guidance as to when no peer authentication should /
> should not be used?  Is it possible for an EAP peer to present a
> client certificate, but have the EAP server ignore it?  What kind of network access should an EAP peer have if it does not use peer authentication?
> 
>  Perhaps some of the text from Section 5.6 could be added here.
> 
> Perhaps suggest that in the normal case, deployments SHOULD use peer
> authentication.  Also that the "no peer authentication" case be
> strictly limited in both time, and network access.
> 
> e.g. The "no peer authentication" situation MUST NOT be used to give
> normal network access to EAP peers.  Instead, deployments SHOULD
> provide access which is limited in both time, and in capability.
> Usually this means a "quarantine" network, or "walled garden", which
> has only limited capability.
> 
> Also, the Security Considurations section has no discussion of the
> security impact of not authenticating the peer.  As Section 2.1.5 is
> new, it has major impacts on security, and thus needs to be discussed.

Unaddressed without any comment or discussion:

  I don't understand why it's necessary to include discussion of TLS negotiation in EAP, when that negotiation does not affect EAP in any way.

> Section 2.1.6 says:
> 
>  As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
>  HelloRetryRequest message in response to a ClientHello if the EAP-TLS
>  server finds an acceptable set of parameters but the initial
>  ClientHello does not contain all the needed information to continue
>  the handshake.
> 
> It's not clear why this section is necessary.  The text here appears
> to be discussing internals of TLS layer negotiation, which are
> invisible to EAP-TLS.  That is, this packet flow has no effect on the
> EAP-TLS state machine, other than a different number of packets are
> exchanged than with other packet flows.
> 
> Question: Is it that "EAP-TLS server" does not have sufficient
> information to continue the handshake, or is it "the TLS layer" ?
> 
> Question: if the EAP-TLS implementation can do nothing other than ask
> the TLS layer to continue the handshake, is this section even
> necessary or relevant?
> 
> 
> Section 2.1.9 says:
> 
>  Some EAP implementations and access networks may limit the number of
>  EAP packet exchanges that can be handled.
> 
> This is under-stating the issue rather severely.  We know with
> absolute certainty that most (if not all) EAP implementations and
> access networks limit the number of EAP packet exchanges.  Perhaps
> update the text to reference implementation and interoperability
> experience.

   Addressed in part:

  The updated text is clearer, but still does not address some of the questions raised below about calling this out as a new requirement from 5216, and what happens in an HA environment.

> Section 2.2 has substantial new text which was not previously discussed on the WG mailing list.
> 
>   The EAP server identity in the TLS server certificate is typically a
>   fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>   allow users to configuring a unique trust root (CA certificate) and a
>   server name to authenticate the server certificate and match the
>   subjectAlternativeName (SAN) extension in the server certificate with
>   the configured server name.
> 
> Comment: How does this text related to RFC 5216 Section 5.2 ?  There seems to be substantial overlap.
> 
> What does this text add to / change from RFC 5216 Section 5.2 ?
> 
> Requiring a supplicant to be configured with a peer name is a new requirement from RFC 5216, and isn't called out as such.
> 
> What happens in a high availability (HA) environment?  Are all of the EAP servers required to have the same FQDN?
> 
> While this text is intended to increase security, there are implementation and operational considerations which need addressing.
> 
>   In the absence of a user-configured root
>   CA certificate,
> 
> Comment: I'm not sure what that means.  It seems to assume certain things without explaining them.
> 
>   The process of configuring a root CA certificate and a server name is
>   non-trivial and therefore automated methods of provisioning are
>   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>   a Configuration Assistant Tool (CAT) to automate the configuration
>   process.  In the absence of a trusted root CA certificate (user
>   configured or system-wide), EAP peers MAY implement a trust on first
>   use (TOFU) mechanism where the peer trusts and stores the server
>   certificate during the first connection attempt.  The EAP peer
>   ensures that the server presents the same stored certificate on
>   subsequent interactions.  Use of TOFU mechanism does not allow for
>   the server certificate to change without out-of-band validation of
>   the certificate and is therefore not suitable for many deployments.
> 
> i.e. when there's an HA configuration.

  Addressed.

> Section 2.3 says:
> 
> 
>   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
>   Method-Id SHALL be derived from the exporter_secret using the TLS
>   exporter interface [RFC5705] (for TLS 1.3 this is defined in
>   Section 7.5 of [RFC8446]).
> 
>   Type-Code  = 0x0D
>   MSK        = TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
>   EMSK       = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
>   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
>   Session-Id = Type-Code || Method-Id
> 
> All this is nice, but it might be too late.  I'd check with major implementations which have frozen their code, and are shipping.
> 
> It would be good for the spec and implementations to match.
> 
> 
> Section 2.3 says:
> 
>  By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
>  without having to extract the Master Secret, ClientHello.random, and
>  ServerHello.random in a non-standard way.
> 
> NIT: the exporters were first defined in TLS 1.2, and have been widely
> available in TLS library implementations.  Using master secret,
> etc. has not been necessary for a while.  Further, the "non-standard"
> use of Master Secret, etc. was first done in the original EAP-TLS RFC
> [2716], in 1999.  The TLS WG later defined and standardized the
> exporters in order to meet the needs of EAP-TLS.
> 
> Perhaps instead say:
> 
>  By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
>  which provides a public API for the exporter.  There has been no need
>  to access internal fields in TLS since the public exporters were
>  defined in [RFC5705].
> 
> 
> Section 2.4 says:
> 
>   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.
> 
> Comment: This appears to be the only reference to the commitment message in the document.  It may be good to update Section 2.5 to use the same name for the 0x00 byte of application data.

Unaddressed without any comment or discussion:

> Section 5.1 says:
> 
>  [4] Cryptographic Negotiation: TLS 1.3 increases the number of
>  cryptographic parameters that are negotiated in the handshake.  When
>  EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
>  negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
>  groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
> 
> Question: what does this mean in practice for EAP-TLS?  i.e. this text
> describes a capability.  It does not describe what that capability
> does, or how it benefits EAP-TLS.
> 
> 
> Section 5.2 says:
> 
> No updates to section 5.2 of [RFC5216].
> 
> This isn't true.  Section 2.2 has substantial new text with new requirements, and new security impacts.
> 
> 
> Section 5.3 says:
> 
>   While certificates may have long validity periods,
> 
> Comment: Certs issued by public CAs are generally short-lived, as in a year or so.  It may be worth discussing this.
> 
> 
> Section 5.4 says:
> 
>   Some deployments may permit no peer authentication for some or all
>   connections.  When peer authentication is not used, implementations
>   MUST take care to limit network access appropriately for
>   unauthenticated peers
> 
> Q: Are these EAP server implementations?  How does an EAP server limit network access for unauthenticated peers?
> 
> Section 5.7 says:
> 
>  There are a number of security issues related to resumption that are
>  not described in [RFC5216].  The problems, guidelines, and
>  requirements in this section therefore applies to all version of TLS.
> 
> NIT: These requirements are for EAP-TLS, and not TLS.  This document does not apply new security requirements to the TLS protocol
> 
> Perhaps instead:
> 
>  There are a number of security issues related to resumption that are
>  not described in [RFC5216].  The problems, guidelines, and
>  requirements in this section therefore applies EAP-TLS when is used
>  with any version of TLS.
> 
> 
> Section 5.7 says:
> 
>   If the EAP-TLS server or EAP client do not apply any authorization
>   policies, 
> 
> NIT: EAP-TLS servers do not apply authorization policies.  Perhaps explain that the EAP-TLS server is co-located with RADIUS / Diameter etc, and those apply policies.
> 
> NIT2: It's not clear how an EAP client would apply authorization policies.  Perhaps just remove the reference to the EAP client.
> 
>

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 11 Jun 2021 18:12:48 +0000

Hi Alan,

Response in-line.

>> leverage that capability.
The comment here says adding text about "TLS version negotiation". There 
is a comment from you below saying: "I don't understand why it's 
necessary to include discussion of TLS negotiation in EAP, when that 
negotiation does not affect EAP in any way." Am I missing something or 
is there conflicting feedback?
>> has only limited capability.
There is text already in the draft which says : "While the EAP server 
SHOULD require peer authentication, this is not mandatory, since there 
are circumstances in which peer authentication will not be needed (e.g., 
emergency services, as described in [UNAUTH]), or where the peer will 
authenticate via some other means.". This is what was said also in RFC 
5216. We also have also have the following text in the draft: "Some 
deployments may permit no peer authentication for some or all 
connections.  When peer authentication is not used, implementations MUST 
take care to limit network access  appropriately for unauthenticated 
peers and implementations MUST use resumption with caution to ensure 
that a resumed session is not granted more privilege than was intended 
for the original session.". I think we have tried to find a careful 
balance between providing sufficient guidance vs. being repetitive. Is 
there something that should be repeated in section 2.1.5?
>    I don't understand why it's necessary to include discussion of TLS negotiation in EAP, when that negotiation does not affect EAP in any way.
See above.
>> the TLS layer to continue the handshake, is this section even
This section was added based on a review by Jim Schaad 
(https://mailarchive.ietf.org/arch/msg/emu/qO5qgQ-8GzB-jVx2vtrQCe42cCg/). 
If nothing else, I would like to keep it as a homage to him.
>    The updated text is clearer, but still does not address some of the questions raised below about calling this out as a new requirement from 5216, and what happens in an HA environment.
Please let us know a good reference to "implementation and 
interoperability experience." about the upper limit on EAP packet 
exchanges. This would also be useful for draft-ietf-emu-eaptlscert.
>> Requiring a supplicant to be configured with a peer name is a new requirement from RFC 5216, and isn't called out as such.
I agree with you that we could benefit from more clarification on 
relationship between section 2.2 and 5.2 of this draft vs. the old RFC 
5216. Do you have a suggestion how best to split the text and reflect 
the updates to RFC5216?
>> does, or how it benefits EAP-TLS.
This is what RFC5216 said "EAP-TLS inherits the secure ciphersuite 
negotiation features of TLS, including key derivation function 
negotiation when utilized with TLS v1.2 ". Do you have some suggestion 
on what we should add?
>> Q: Are these EAP server implementations?  How does an EAP server limit network access for unauthenticated peers?

Fixed in github version.

Could you also highlight if there are some unaddressed comments. It 
wasn't obvious if "Unaddressed without any comment or discussion:" 
refers only to the discussion immediately below or to several 
discussions below.

--Mohit

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jun 2021 15:28:55 -0400

> is there conflicting feedback?

  There are two unrelated issues here.

  It would be good to explain why EAP-TLS 1.3 is compatible with earlier versions of EAP-TLS.  This compatibility is done by EAP-TLS *implicitly* relying on TLS for version negotiation.

  i.e. there is no version in the EAP-TLS header.  And EAP-TLS has no provisions for version negotiation outside of TLS.

  The later comments about other TLS negotiation are for other handshake messages, and are entirely unrelated to version negotiation. 

  TLS has a large number of handshake messages which can be exchanged.  Section 2.1.6 calls out HelloRetryRequest as special, but with no explanation as to why.  There is no discussion that the HelloRetryRequest affects EAP-TLS in any way.  As such, I ask again why is the text about HelloRetryRequest included in the document.  And if the EAP-TLS specification needs to discuss HelloRetryRequest, why not also include a section for every handshake message used by TLS?

  Does Section 2.1.6 mandate any behavior for EAP-TLS implementations?  If the text in Section 2.1.6 doesn't require EAP-TLS implementations to do anything, then that section can be omitted without any issue.

> there something that should be repeated in section 2.1.5?

  The common terms used for limited access networks include "walled garden" and "quarantine network".  Using these terms would both make it clear to the reader what is expected, and reiterate that these well-known processes are being required here.

  i.e. "take care to limit network access  appropriately" gives insufficient guidance for an implementor.  "taking care" is not an actionable recommendation.  In contrast, asking people to "enable your vendors walled garden functionality" is actionable.

>>   I don't understand why it's necessary to include discussion of TLS negotiation in EAP, when that negotiation does not affect EAP in any way.

  In short: TLS version negotiation does affect EAP-TLS.  HelloRetryRequest messages do not.

> If nothing else, I would like to keep it as a homage to him.

  That's good, but the section needs to have actionable text.  i.e. what do implementors do here?

  The recommendation in the above link says "Alternatively state that HelloRetryRequest MUST NOT be used (or positively that the server MUST respond with ServerHello)"

  Those recommendations are actionable.

> exchanges. This would also be useful for draft-ietf-emu-eaptlscert.

  I posted references on this list previously:

https://mailarchive.ietf.org/arch/browse/emu/?qdr=y

> 5216. Do you have a suggestion how best to split the text and reflect 

  Updating 2.2 with a note after the text on page 18 seems best:

While this requirement to verify domain names is new, and was not mentioned in [RFC5216], it has been widely implemented in EAP peers.  As such, we believe that this section contains minimal new interoperability or implementation requirements on EAP peers.

> negotiation when utilized with TLS v1.2 ". Do you have some suggestion 

  I am wary of repeating text about negotiation, which might be inconsistent with the parent reference.  The text isn't wrong, but it may be worth just saying something to the effect of "EAP-TLS does not do cryptographic negotiation, but instead relies on TLS.  See Section 4.1.1. of [RFC8446]"

> refers only to the discussion immediately below or to several 

  It refers to all of the discussions below, until the next comment of "addressed".  So there are still unaddressed comments.  Specifically, comments on Sections 2.1.1 (post handshake KeyUpdate), Section 5.2, 5.3, and 5.4

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 13 Jun 2021 15:49:29 -0800

On Fri, Jun 11, 2021 at 11:29 AM Alan DeKok <[email-masked]>
wrote:

>   It would be good to explain why EAP-TLS 1.3 is compatible with earlier
> versions of EAP-TLS.  This compatibility is done by EAP-TLS *implicitly*
> relying on TLS for version negotiation.
>
>   i.e. there is no version in the EAP-TLS header.  And EAP-TLS has no
> provisions for version negotiation outside of TLS.
>
>
[Joe]  The existing text already refers to relying on the underlying TLS
version negotiation.

>   The later comments about other TLS negotiation are for other handshake
> messages, and are entirely unrelated to version negotiation.
>
>   TLS has a large number of handshake messages which can be exchanged.
> Section 2.1.6 calls out HelloRetryRequest as special, but with no
> explanation as to why.  There is no discussion that the HelloRetryRequest
> affects EAP-TLS in any way.  As such, I ask again why is the text about
> HelloRetryRequest included in the document.  And if the EAP-TLS
> specification needs to discuss HelloRetryRequest, why not also include a
> section for every handshake message used by TLS?
>
>
[Joe]  I don't see a problem with covering new TLS handshake messages in
the document, however they are covered somewhat inconsistently.  Perhaps we
should cover them all in a "new handshake messages section".

TLS 1.3 introduces several new handshake messages including
HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages
will be handled by the underlying TLS libraries and are not visible to
EAP-TLS, however there are a few things to note.

The HelloRetryRequest is used by the server to reject the parameters
offered in the ClientHello and suggest new parameters.  When this message
is encountered it will increase the number of round trips used by the
protocol.

The NewSessionTicket message is used to convey session
resumption information and is covered in sections 2.1.2 and 2.1.3.

The KeyUpdate message is used to update the encryption keys used on a TLS
connection.  EAP-TLS does not encrypt significant amounts of this data so
this functionality is not needed.  Implementations SHOULD NOT send this
message, however some TLS libraries may automatically generate and process
this message.   (remove current text on KeyUpdate)

>   Does Section 2.1.6 mandate any behavior for EAP-TLS implementations?  If
> the text in Section 2.1.6 doesn't require EAP-TLS implementations to do
> anything, then that section can be omitted without any issue.
>
>   The common terms used for limited access networks include "walled
> garden" and "quarantine network".  Using these terms would both make it
> clear to the reader what is expected, and reiterate that these well-known
> processes are being required here.
>
>   i.e. "take care to limit network access  appropriately" gives
> insufficient guidance for an implementor.  "taking care" is not an
> actionable recommendation.  In contrast, asking people to "enable your
> vendors walled garden functionality" is actionable.
>
>
[Joe]  OK how about adding:

"An example of limiting network access would be to invoke a vendor's walled
garden or quarantine network functionality."

> >>   I don't understand why it's necessary to include discussion of TLS
> negotiation in EAP, when that negotiation does not affect EAP in any way.
> > See above.
>
[Joe] The EAP TLS layer needs to know which TLS version was negotiated.
HelloRetryRequests affect the number of round trips in the exchange, but
are opaque with respect to EAP-TLS.

>   The recommendation in the above link says "Alternatively state that
> HelloRetryRequest MUST NOT be used (or positively that the server MUST
> respond with ServerHello)"
>
[Joe]  HelloRetryRequest is a feature of the underlying TLS library so the
RFC8446 Should determine the underlying behavior, specifying a different
behavior is problematic.

> >>   The updated text is clearer, but still does not address some of the
> questions raised below about calling this out as a new requirement from
> 5216, and what happens in an HA environment.
[Joe] I think this is the wrong link.

> >>> Requiring a supplicant to be configured with a peer name is a new
> requirement from RFC 5216, and isn't called out as such.
> While this requirement to verify domain names is new, and was not
> mentioned in [RFC5216], it has been widely implemented in EAP peers.  As
> such, we believe that this section contains minimal new interoperability or
> implementation requirements on EAP peers.
>
>
[Joe] This does not seem to add to the specification.

>   I am wary of repeating text about negotiation, which might be
> inconsistent with the parent reference.  The text isn't wrong, but it may
> be worth just saying something to the effect of "EAP-TLS does not do
> cryptographic negotiation, but instead relies on TLS.  See Section 4.1.1.
> of [RFC8446]"
>
>
[Joe] The text included in the draft is fairly minimal.  I think the
suggestion is good since these are internal details of TLS, but I don't
think it is necessary.

>   It refers to all of the discussions below, until the next comment of
> "addressed".  So there are still unaddressed comments.  Specifically,
> comments on Sections 2.1.1 (post handshake KeyUpdate), Section 5.2, 5.3,
> and 5.4
>
>
[Joe] See suggestion for new handshake messages above.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 13 Jun 2021 20:21:37 -0400

On Jun 13, 2021, at 7:49 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe]  The existing text already refers to relying on the underlying TLS version negotiation.  

  Yes.  I was trying to address the confusion between version negotiation and other handshake negotiation.

> [Joe]  I don't see a problem with covering new TLS handshake messages in the document, however they are covered somewhat inconsistently.  Perhaps we should cover them all in a "new handshake messages section". 

  My point was that if the EAP layer doesn't need to do anything with those new handshake messages, then there isn't a need to mention them in the specification.

> TLS 1.3 introduces several new handshake messages including HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages will be handled by the underlying TLS libraries and are not visible to EAP-TLS, however there are a few things to note.  
> 
> The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters.  When this message is encountered it will increase the number of round trips used by the protocol.  

  If that's the only change, then I would suggest there's no need for a section dedicated to HelloRetryRequest.  Perhaps just saying "there are a number of new messages in TLS 1.3 which affect round trips, but the EAP layer doesn't have to do anything other than exchange more TLS messages".

> "An example of limiting network access would be to invoke a vendor's walled garden or quarantine network functionality."

  Sounds good.

> [Joe] The EAP TLS layer needs to know which TLS version was negotiated.  HelloRetryRequests affect the number of round trips in the exchange, but are opaque with respect to EAP-TLS.

  Yes.  I was confused at Section 2.1.6. which essentially says "HelloRetryRequest is a new TLS message, here's a diagram of using it with EAP-TLS".   As an implementor, the immediate question is "What do I *do* with this message?"  and the answer is essentially "nothing".

  Pretty much every other section in the document says "this is new in TLS 1.3, and here's how to handle it".

> [Joe]  HelloRetryRequest is a feature of the underlying TLS library so the RFC8446 Should determine the underlying behavior, specifying a different behavior is problematic. 

  Sure.

> [Joe] I think this is the wrong link.  

  Yes.  The new mail archive interface is substantially worse than the older "mailman" interface.  It's difficult to follow threads, quickly search by dates, etc.

  In any case, this is the previous message:  https://mailarchive.ietf.org/arch/msg/emu/y3d6KGFeImAeSLEqF6XqVMev2Zc/

> [Joe] This does not seem to add to the specification. 

  I agree that text doesn't add any new requirements to the specification.  However, it's useful to make a note for implementors that while Section 2.2. is officially a new requirement in theory, there is little to do in practice, because implementations already meet these requirements.  There has been similar text in many other specifications.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 17 Jun 2021 16:04:19 +0000

Hi,

Thanks Joe for making such very clear and concrete issues on GitHub!

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues

I have made a single PR addressing all the currently listed issues in the way suggested by Joe.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files

- Does PR #83 address the currently listed issues?

- Are there any other remaining issues that are not listed on GitHub?

Cheers,
John

From: Emu <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Date: Monday, 14 June 2021 at 02:22
To: Joseph Salowey <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

  Sounds good.

  Sure.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Jun 2021 13:55:46 -0400

> - Does PR #83 address the currently listed issues?

  I'll have to go through it and see.  It's normally traditional to respond to reviews.  And, to reply with proposed text for the document update.  That process allows reviewers to quickly see if their issues have been addressed.

  The current use of GitHub makes this process rather more opaque.  There are changes to the document pushed as commits, but it requires rooting through multiple commits and references in order to see which commit addresses which issue.  The many commits of "updated document" make it more difficult to see what is changed, and why.

> - Are there any other remaining issues that are not listed on GitHub?

  My review of a few days ago had extensive comments.  It may be worth going through that and addressing each issue.  Some of the items have been addressed, which is positive.  However, it looks like all of my comments for Section 5 remain unaddressed.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 18 Jun 2021 12:30:36 -0800

On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok <[email-masked]>
wrote:

>   I'll have to go through it and see.  It's normally traditional to
> respond to reviews.  And, to reply with proposed text for the document
> update.  That process allows reviewers to quickly see if their issues have
> been addressed.
>
>   The current use of GitHub makes this process rather more opaque.  There
> are changes to the document pushed as commits, but it requires rooting
> through multiple commits and references in order to see which commit
> addresses which issue.  The many commits of "updated document" make it more
> difficult to see what is changed, and why.
>
>
[Joe]  The github PRs make it easier to view the changes in the context of
the document.  I realize there may be a little bit of extra work to
associate the changes to the issues, but this should be too difficult to
do.

>   My review of a few days ago had extensive comments.  It may be worth
> going through that and addressing each issue.  Some of the items have been
> addressed, which is positive.  However, it looks like all of my comments
> for Section 5 remain unaddressed.
>
>
[Joe] I opened issue 84 (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84) to track
this.

I think most of the section 5 issues have been addressed or can be
addressed with simple changes.  It's not clear what you wanted to address
in section 5.3.

---

From: John Mattsson <[email-masked]>
Date: Fri, 18 Jun 2021 21:23:42 +0000

Hi Alan,

Thanks for your thorough review of version -16. Based on the suggested changes Joe made in GitHub issue #83, I have made commits to PR #83.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83

Below is a summary of the suggested changes to section 5 to address your comments:

>From Alan's review of section 5

    Section 5.1 says:

Joe: How about:
"[4] Cryptographic Negotiation: The TLS layer handles the negotiation of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm, see Section 4.1.1 of [RFC8446]."

John: I made a commit based on Joe’s suggestion to shorten this down. Having this text is a requirement from RFC 3748 if I am correct.

    Section 5.2 says:

Joe: Add note that "Section 2.2 has additional discussion on identities."

John: I added "Note that Section 2.2 has additional discussion on identities."

    Section 5.3 says:

Joe: It's not clear what to add here.

John: Alan has a good point here. I suggest just deleting "While certificates may have long validity periods,". There is already text describing that certificates can have very short lifetimes.

    Section 5.4 says:

Joe: This should be address by PR #83 modifications for section 5.6.

John: Yes

    Section 5.7 says:

    Perhaps instead:

Joe: This comment should already be addressed by PR #83 or draft 16 text.

John: Yes

    Section 5.7 says:

Joe: Authorization should be discussed in the authorization section. Perhaps reword paragraph to:

   "The EAP-TLS server or EAP client MUST cache data during the
   initial full handshake sufficient to allow authorization decisions to be made during resumption. If cached data cannot be retrieved in a secure way, resumption MUST NOT be done."

John: I made a commit based on Joes suggestion above.

Cheers,
John

From: Joseph Salowey <[email-masked]>
Date: Friday, 18 June 2021 at 22:30
To: Alan DeKok <[email-masked]>
Cc: John Mattsson <[email-masked]>, Bernard Aboba <[email-masked]>, Mohit Sethi M <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:
On Jun 17, 2021, at 12:04 PM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files<https://protect2.fireeye.com/v1/url?k=8c954de0-d30e77f9-8c950d7b-8682aaa22bc0-57cef0b953c698ab&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fpull%2F83%2Ffiles>
>

[Joe]  The github PRs make it easier to view the changes in the context of the document.  I realize there may be a little bit of extra work to associate the changes to the issues, but this should be too difficult to do.

[Joe] I opened issue 84 (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84<https://protect2.fireeye.com/v1/url?k=27d05bf2-784b61eb-27d01b69-8682aaa22bc0-e47af421c50a8144&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fissues%2F84>) to track this.

I think most of the section 5 issues have been addressed or can be addressed with simple changes.  It's not clear what you wanted to address in section 5.3.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 18 Jun 2021 17:46:04 -0400

> [Joe]  The github PRs make it easier to view the changes in the context of the document.  I realize there may be a little bit of extra work to associate the changes to the issues, but this should b…

  It's also not difficult to address reviews which have been outstanding for 3+ months.

  If the authors don't address WG reviews, then it's difficult to see how the document can move forward.

> [Joe] I opened issue 84 (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84) to track this.  

  Thanks.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 18 Jun 2021 17:48:20 -0400

> John: I made a commit based on Joe’s suggestion to shorten this down. Having this text is a requirement from RFC 3748 if I am correct.

  That's good, thanks.

> John: I added "Note that Section 2.2 has additional discussion on identities."

  Excellent.

> John: Alan has a good point here. I suggest just deleting "While certificates may have long validity periods,". There is already text describing that certificates can have very short lifetimes.

  Sure, that works.

  The rest of the changes look good, thanks.

  Alan DeKok.