Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

From: Joseph Salowey <[email-masked]>
Date: Wed, 5 May 2021 08:33:56 -0700

This is the working group last-call for draft-ietf-emu-eap-tls13.  Please
review the draft, focus on the recent changes and submit your comments to
the list by May 20, 2021.

Thanks,

Joe

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

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

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 6 May 2021 15:11:53 -0400

> On May 5, 2021, at 11:33 AM, Joseph Salowey <[email-masked]> wrote:
> 
> This is the working group last-call for draft-ietf-emu-eap-tls13.  Please review the draft, focus on the recent changes and submit your comments to the list by May 20, 2021.   

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.

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.

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.

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.

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.

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.

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: Jorge Vergara <[email-masked]>
Date: Fri, 7 May 2021 20:09:19 +0000

> All this is nice, but it might be too late.  I'd check with major implementations which have frozen their code, and are shipping.

The Windows implementation is using draft-13 exporters; it is not possible to change at this point unless a critical technical issue that prevents functionality or impacts security were to be discovered. I don't think this is such an issue. The preference to keep draft-13 exporters was discussed at IETF 110 and I do not recall any objection. The draft-15 exporter is problematic for Windows at this point.

I have fewer opinions on the less-technical areas of the draft. One of my flaws as an implementor of several EAP methods is that I can parse the current draft and assume enough intent to complete my implementation. I do call out questions I have - but I sometimes make assumptions without realizing due to prior experience in the area. This may be true of several others in the working group as well. Non-implementors don't have the luxury of this experience and I think it is extremely difficult to create a secure and robust EAP method implementation from scratch. The more guidance toward this goal that can be included in the document the better, in my opinion.

Jorge

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

Section 1 says:

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.

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:

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.

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.

Section 2.1.4

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

Section 2.1.6 says:

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:

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.

Section 2.3 says:

   Type-Code  = 0x0D

Section 2.3 says:

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:

Section 2.4 says:

Section 5.1 says:

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:

Section 5.3 says:

Section 5.4 says:

Section 5.7 says:

Perhaps instead:

Section 5.7 says:

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Cjovergar%40microsoft.com%7C06cb86b7eaa94616173908d910c2d79b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637559251296905827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Mklb8zBvFHMwQ7HJC0aKtiirYQz7jbVCBMSexEMFCQc%3D&amp;reserved=0

---

From: Alan DeKok <[email-masked]>
Date: Fri, 7 May 2021 16:48:45 -0400

> The Windows implementation is using draft-13 exporters; it is not possible to change at this point unless a critical technical issue that prevents functionality or impacts security were to be disco…

  The interop report involved Microsoft, FreeRADIUS, and hostap.  All have implemented the -13 exporters, and the 0x00 Commitment message.  Interoperablity has been demonstrated to the satisfaction of all participants.

  Pretty much everyone else with supplicant and/or RADIUS server implementations is out of the loop.  They're either unaware of this work, or have no opinions on it.

  From the Open Source side, it's easy to change code.  But I will not ship a product which fails to interoperate with the dominant supplicant platform.

  I see no major security issues with the -13 exporters.  It's "nicer" to use separate labels, but it's not critically important for the security of the protocol.

> I have fewer opinions on the less-technical areas of the draft. One of my flaws as an implementor of several EAP methods is that I can parse the current draft and assume enough intent to complete m…

  I agree.

  I have expressed strong opinions that the document gives insufficient guidance to implementors.  For me, "rough consensus and running code" means I should be able to say the following, and be taken seriously:

  "Hi, as someone with running code, I believe that it is critical for the specification to say X, in order to address implementation and interoperability issues".

  It's surprising when the response to such a comment is "No".

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 7 May 2021 14:18:53 -0700

On Fri, May 7, 2021 at 1:09 PM Jorge Vergara <[email-masked]> wrote:

> > All this is nice, but it might be too late.  I'd check with major
> implementations which have frozen their code, and are shipping.
>
> The Windows implementation is using draft-13 exporters; it is not possible
> to change at this point unless a critical technical issue that prevents
> functionality or impacts security were to be discovered. I don't think this
> is such an issue. The preference to keep draft-13 exporters was discussed
> at IETF 110 and I do not recall any objection. The draft-15 exporter is
> problematic for Windows at this point.
>
>
[Joe] I think the one issue that was raised during TLS review was that
using the same label for MSK and EMSK could make it more difficult to
separate out the derivations of these keys at the TLS level.  For example,
example, perhaps the TLS implementation could restrict access to the MSK
and EMSK independently depending upon hte caller.  In practice, it is
EAP-TLS that is the caller and the use cases that require the separate
derivation of these two keys of these two keys is few to none.  I'll start
a short consensus call on this issue.

> I have fewer opinions on the less-technical areas of the draft. One of my
> flaws as an implementor of several EAP methods is that I can parse the
> current draft and assume enough intent to complete my implementation. I do
> call out questions I have - but I sometimes make assumptions without
> realizing due to prior experience in the area. This may be true of several
> others in the working group as well. Non-implementors don't have the luxury
> of this experience and I think it is extremely difficult to create a secure
> and robust EAP method implementation from scratch. The more guidance toward
> this goal that can be included in the document the better, in my opinion.
>
>
[Joe] Thanks, having a more voices chime in on issues can help resolve them
more quickly and satisfactorily.

> > This is the working group last-call for draft-ietf-emu-eap-tls13.
> Please review the draft, focus on the recent changes and submit your
> comments to the list by May 20, 2021.
>
>
> Section 1 says:
>
> 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.
>
> 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.
> implements TLS version negotiation, EAP-TLS will automatically leverage
> that capability.
>
>
> Section 2.1.1 says:
>
> 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.
>
>
> 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.
>
>  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?
>
> authentication.  Also that the "no peer authentication" case be strictly
> limited in both time, and network access.
>
> normal network access to EAP peers.  Instead, deployments SHOULD provide
> access which is limited in both time, and in capability.
> 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.
>
>
> Section 2.1.6 says:
>
> 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:
>
> 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.
>
>
> 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 text is intended to increase security, there are implementation
> and operational considerations which need addressing.
>
>  All this is nice, but it might be too late.  I'd check with major
> implementations which have frozen their code, and are shipping.
>
> available in TLS library implementations.  Using master secret, etc. has
> not been necessary for a while.  Further, the "non-standard"
> [2716], in 1999.  The TLS WG later defined and standardized the exporters
> in order to meet the needs of EAP-TLS.
>
> Perhaps instead say:
>
> 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.
>
>
> Section 5.1 says:
>
> describes a capability.  It does not describe what that capability does, or
> how it benefits EAP-TLS.
>
>
> Section 5.2 says:
>
> 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:
>
> Q: Are these EAP server implementations?  How does an EAP server limit
> network access for unauthenticated peers?
>
> Section 5.7 says:
>
> NIT: These requirements are for EAP-TLS, and not TLS.  This document does
> not apply new security requirements to the TLS protocol
>
> Perhaps instead:
>
> 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: Alan DeKok <[email-masked]>
Date: Fri, 7 May 2021 18:00:33 -0400

On May 7, 2021, at 5:18 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] I think the one issue that was raised during TLS review was that using the same label for MSK and EMSK could make it more difficult to separate out the derivations of these keys at the TLS level.  For example, example, perhaps the TLS implementation could restrict access to the MSK and EMSK independently depending upon hte caller.

  I'll have to think about that a little more before I understand the underlying objection.

  From what I can see, MSK and EMSK are specific to EAP-TLS.  They are derived in the EAP-TLS application, by passing EAP-TLS parameters to TLS key exporters.

  So the TLS layer has no concept of what MSK or EMSK are.  As a result, the TLS layer should have minimal input into what those keys are, or how they are derived.

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Sat, 8 May 2021 01:18:47 +0000

>[Joe] I think the one issue that was raised during TLS review was that using the same label for MSK and EMSK could make it more difficult to separate out the derivations of these keys at the TLS level.  For example, example, perhaps the TLS implementation could restrict access to the MSK and EMSK independently depending upon hte caller.  In practice, it is EAP-TLS that is the caller and the use cases that require the separate derivation of these two keys of these two keys is few to none.  I'll start a short consensus call on this issue.

I reviewed all of the concerns I was able to find in the group archives, and the concerns mostly seemed to express that the combined derivation (draft-13) was a bit "clumsy" with potential to clean it up a bit, but I didn't find any strong objections. Looking forward to more input from the group as to whether the draft-13 exporter is livable.

Jorge Vergara

From: Joseph Salowey <[email-masked]>
Sent: Friday, May 7, 2021 2:19 PM
To: Jorge Vergara <[email-masked]>
Cc: Alan DeKok <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Joe] I think the one issue that was raised during TLS review was that using the same label for MSK and EMSK could make it more difficult to separate out the derivations of these keys at the TLS level.  For example, example, perhaps the TLS implementation could restrict access to the MSK and EMSK independently depending upon hte caller.  In practice, it is EAP-TLS that is the caller and the use cases that require the separate derivation of these two keys of these two keys is few to none.  I'll start a short consensus call on this issue.

[Joe] Thanks, having a more voices chime in on issues can help resolve them more quickly and satisfactorily.

Jorge

-----Original Message-----
From: Emu <[email-masked]<mailto:[email-masked]>> On Behalf Of Alan DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Cc: EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

> On May 5, 2021, at 11:33 AM, Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
>

Section 1 says:

Section 2.1.1 says:

Section 2.1.4

Section 2.1.6 says:

Section 2.1.9 says:

Section 2.3 says:

   Type-Code  = 0x0D

Section 2.3 says:

Perhaps instead say:

Section 2.4 says:

Section 5.1 says:

Section 5.2 says:

Section 5.3 says:

Section 5.4 says:

Section 5.7 says:

Perhaps instead:

Section 5.7 says:

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Cjovergar%40microsoft.com%7C06cb86b7eaa94616173908d910c2d79b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637559251296905827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Mklb8zBvFHMwQ7HJC0aKtiirYQz7jbVCBMSexEMFCQc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=04%7C01%7Cjovergar%40microsoft.com%7C0240be909517400c4f6808d9119dbec9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637560191509453427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sTtSGXFF6G5j0nPfzZqZ42LTB91siXY1PcGCT1PQ7DY%3D&reserved=0>

---

From: "Meiling Chen" <[email-masked]>
Date: Sat, 8 May 2021 16:24:38 +0800

I have noticed that there is one modification in the Figure 1 flow diagram of edition 15.
edition 14 has TLS close_notify message, but in edition 15 changed into TLS application Data 0x00.
in the section 2.1.1, it says" TLS application data 0x00 is therefore to
   be interpreted as success after the EAP-Request that contains TLS
   application data 0x00.  After the EAP-TLS server has received an
   empty EAP-Response to the EAP-Request containing the TLS application 
   data 0x00, the EAP-TLS server sends EAP-Success."
is the data 0x00 that mean not send any more handshake messages?
another question: what's the format of the EAP-success measge, plaintext ot ciphertext?

Best Regards,
Meiling
 
From: Joseph Salowey
Date: 2021-05-05 23:33
To: EMU WG
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please review the draft, focus on the recent changes and submit your comments to the list by May 20, 2021.   

Thanks,

Joe

---

From: John Mattsson <[email-masked]>
Date: Tue, 11 May 2021 12:30:41 +0000

Hi Meiling,

In version 15 the group decided to go back more or less to how things worked in version 13 where protected TLS application Data 0x00 is send instead of close_notify.  This is changed in a lot of places in the draft.

A big change from -13 is that where protected TLS application Data 0x00 is not a protected success indication as defined in RFC 3748. That the server only sends EAP-success after this follow from it being a protected success indication.

When reading through the document to write this answer I saw that there was some leftover from the commitment message still in the draft. I made a PR to address this.

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

EAP-success is not encrytpted in any way. It is defined in RFC 3748.

Cheers,
John

From: Emu <[email-masked]> on behalf of Meiling Chen <[email-masked]>
Date: Saturday, 8 May 2021 at 10:25
To: Joseph Salowey <[email-masked]>, emu <[email-masked]>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

Best Regards,
Meiling

From: Joseph Salowey<mailto:[email-masked]>
Date: 2021-05-05 23:33
To: EMU WG<mailto:[email-masked]>
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please review the draft, focus on the recent changes and submit your comments to the list by May 20, 2021.

Thanks,

Joe

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 16 May 2021 11:30:46 -0700

> leverage that capability.
[Joe]  This text is in PR #71
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71>.

> determine the status of key updates, so this suggestion is
[Joe]  I don't see an advantage to having a special case for the KeyUpdate
message.  If the server sends a key update then the peer can just process
it with the rest of the payload it receives.  Since the peer sends no data
it does not matter if it updates the keys or not.   It might be useful to
update this section to say " TLS 1.3 introduced the Post-Handshake
KeyUpdate message which SHOULD NOT be used in EAP-TLS because only one byte
of application data is sent."

>   authenticated, and securely associated with the prior authentication
[Joe]  This text is in PR #71
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71>.

> NIT: strengthenS this requirement.
[Joe] This nit is fixed in the current git-hub draft

> 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?
>
[Joe] I agree that this should be discussed in the security
considerations.   This is discussion of this in section 5.4.

> the TLS layer to continue the handshake, is this section even
[Joe] I think showing the case where extra messages are exchanged is useful
and I don't see this causing harm.

> update the text to reference implementation and interoperability
[Joe] Is there a paper that should be referenced?

> i.e. when there's an HA configuration.
[Joe] This is discussed on a separate thread.

>   to access internal fields in TLS since the public exporters were
[Joe] PR #68  <https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/68>
reverts
to the draft 13 key derivation.

> for the 0x00 byte of application data.
[Joe] Authors please address this nit.

> does, or how it benefits EAP-TLS.
[Joe] Although this is an internal TLS detail I don't see any problem
discussing this in the security considerations.

> requirements, and new security impacts.

[Joe] This section should reference the identity and certificate discussion
in section 2.2.   Maybe section 5.2 should reference this section as well.

> network access for unauthenticated peers?
[Joe]  How about

"When peer authentication is not used, deployments
   MUST take care that the resulting access granted by AAA servers and
network authenticators is appropriate for
   unauthenticated peers."

>   requirements in this section therefore applies EAP-TLS when is used
[Joe] Authors, please address this nit.

> policies.  Perhaps just remove the reference to the EAP client.
[Joe] I don't find this text in the current draft.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 17 May 2021 08:53:11 -0400

> [Joe] Is there a paper that should be referenced?

  No papers that I recall.  But source code to hostap and FreeRADIUS is publicly available.  I've previously posted stable links to specific revisions of the source, for both projects.

> [Joe] Although this is an internal TLS detail I don't see any problem discussing this in the security considerations. 

  I don't see it's a problem, but I don't know why it's there.  Should the EAP-TLS document discuss all of the properties of TLS?  If not, then perhaps a subset?  And which subset to pick?

  As an implementor, anything which is explicitly called out in the document should be there for a reason.  i.e. to guide implementors.  So reading the above text leads me to conclude that the text is important.  But there are no actionable items coming from that text.  No recommendations, and no further discussion.

  And the first sentence is truncated from a grammatical sense:  "TLS increases..." as compared to what?

  Perhaps it's simpler to just say:

 [4] Cryptographic Negotiation: Compared to earlier versions, TLS 1.3 increases the number of
 cryptographic parameters which are negotiated in the handshake.  When
 EAP-TLS is used with TLS 1.3, EAP-TLS inherits all of the increased capabilities of TLS.  See Section 4.1.1 of [RFC8446] for more information.

>    MUST take care that the resulting access granted by AAA servers and network authenticators is appropriate for
>    unauthenticated peers."

  Yes.

  Alan DeKok.