Subject: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

From: Joseph Salowey <[email-masked]>
Date: Fri, 18 Feb 2022 09:18:30 -0800

This is a working group last call for TLS-based EAP types and TLS 1.3. The
document is available here:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

Please review the document and provide comments by March 4, 2022

Thanks,

Joe and Mohit

---

From: John Mattsson <[email-masked]>
Date: Sat, 19 Feb 2022 08:44:27 +0000

Hi,

I have reviewed the document. I think it is ready. There is interest to use these methods in 5G. TLS 1.3 is a must going forward.

Comments:

- The MAC function in section 2.2 is not defined. I assume it should be HMAC. Suggestion:

  OLD
     For TLS 1.3, the hash function used is the same as the
     ciphersuite hash function negotiated for HKDF in the key schedule, as
     per section 7.1 of RFC 8446.
  NEW
     For TLS 1.3, MAC is HMAC using the ciphersuite hash function negotiated for
     HKDF in the key schedule, as per section 7.1 of RFC 8446.

- "As the outer identity is simply an anonymous routing identifier"
  "The outer identity contains an NAI realm, which ensures that
   the inner authentication method is routed to the correct destination."

   Is this section talking about two different "outer identifier"? The identity in the
   identity response is a routing identifier. Security properties like "ensures" is
   given be the identity in the TLS server certificate (to my understanding).

Editorial comments:

- The RFC style guide RFC 7322 states that the abstract must not contain citations.

- draft-ietf-emu-eap-tls13 is now RFC 9190. Some text in abstract and intro should be updated from "is being updated" to "has been updated".

- Section 1 Introduction should say something like "This document updates those methods in order to use the new key derivation methods available in TLS 1.3." The current formulations are "we wish" and "it is necessary".

- "MSK and EMSK are then derived",
  Suggestion "The outer MSK and EMSK are then derived"

- "Unlike previous TLS versions, TLS 1.3 can continue negotiation after the initial
   TLS handshake has been completed"

  Previous TLS versions had renegotiation.

- OLD
    but less interest in EAP-FAST and TTLS.
  NEW
    but less interest in EAP-FAST and TEAP.

- "do not provide for protected success and failure indicators as part of the
   outer TLS exchange."

   Could be good to inform the reader that the TLS alerts are still sent (I assume)
   but not used by EAP.

- "concatetation"
  "cloude"
  "changover"
  "deriviation"
  "authenticaton"
  "succeeed"
  "identies" (several places)
  "ciphersuite" (TLS uses the spelling cipher suite)
  "NewSessionTicketMessage" (NEW: NewSessionTicket message)

Cheers,
John

From: Emu <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Friday, 18 February 2022 at 18:19
To: EMU WG <[email-masked]>
Subject: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

This is a working group last call for TLS-based EAP types and TLS 1.3. The document is available here: https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

Thanks,

Joe and Mohit

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Feb 2022 08:57:34 -0500

>      HKDF in the key schedule, as per section 7.1 of RFC 8446.

  It's good to define "MAC" here.  The construct "MAC is HMAC" sounds awkward to me tho.  I'll try to come up with some phrasing.
>    given be the identity in the TLS server certificate (to my understanding).

  The word "ensures" here is not a security property.  It is used more in the sense of "allows", or "makes sure that".

>   Suggestion "The outer MSK and EMSK are then derived"

  Fixed all of the above.

>   Previous TLS versions had renegotiation.

   Which is re-starting the TLS handshake in the middle of a session.  So far as I'm aware, no EAP client or server supports that functionality.  RFC 5216 (and now 9190) are entirely silent on this topic.  Which further says to me that no one uses it.

  The comment in the document is not about re-negotiation.  In TLS <1.3, when the application sees "TLS init finished", it means that no additional TLS handshake messages will be sent for the current session.  So the application can *implicitly* assume that any further TLS exchanges contain only application data.

  This assumption isn't true for TLS 1.3.  interoperability tests among implementors showed that most, if not all, implementations required updates to correct this wrong assumption.  As such, it's useful for the specification to warn implementors about common issues.

>     but less interest in EAP-FAST and TEAP.

  Fixed.

>    Could be good to inform the reader that the TLS alerts are still sent (I assume)

   I'm not sure why there's any need for a change here.  TLS-based EAP methods use all features of TLS, including alerts.  Those alerts don't signal any state changes in EAP, and thus aren't used by the EAP state machine.  However, they are used by implementors to inform end users about configuration / incompatibility issues.  RFC 9190 has a significant discussion of TLS alerts already, and this document just references that.

>   "NewSessionTicketMessage" (NEW: NewSessionTicket message)

  Fixed, thanks.

  Alan DeKok.

---

From: Russ Housley <[email-masked]>
Date: Sat, 19 Feb 2022 12:07:35 -0500

> On Feb 19, 2022, at 8:57 AM, Alan DeKok <[email-masked]> wrote:
> 

For TLS 1.3, the message authentication code (MAC) is compute with the HMAC algorithm ...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 20 Feb 2022 20:18:42 -0500

> For TLS 1.3, the message authentication code (MAC) is compute with the HMAC algorithm ...

  Sure, thanks.

  Alan DeKok.

---

From: Oleg Pekar <[email-masked]>
Date: Mon, 21 Feb 2022 11:26:46 +0200

Here are my two cents:

1) Section: 2.1. Key Derivation
   When talking about EAP types "Type = value of the EAP Method type"
suggest providing an example of a Type here so it will be clear what is it
about for the rest of the document (e.g. for PEAP Type is 0x19)

2) Here TLS-Exporter function is mentioned for the first time in the
document. Suggest to put a direct reference to the original document where
it is defined:
   "TLS-Exporter is defined in [RFC8446] section-7.5 as TLS-Exporter(label,
context_value, key_length) = HKDF-Expand-Label(Derive-Secret(Secret, label,
""), "exporter", Hash(context_value), key_length).
   This could help the reader to understand better what do the function
parameters mean and what does the function do. Such a reference to a PRF is
used in other documents (e.g. TEAP RFC 7170)

3) Section: 2.2 TEAP
"IMSK = TLS-Exporter("[email-masked]", EMSK, 32)" - this may be not
clear to the reader since this formula is effective when inner method
generates EMSK. It worth mentioning that in other case IMSK is selected per
TEAP RFC

4) In this sentence "For TLS 1.3, the hash function used is the same as the
ciphersuite hash function negotiated for HKDF" suggest saying "the MAC
function" instead of "the hash function"

5) Section: 2.3. FAST
"For FAST, the session_key_seed is also used as the key_block, as defined
in [RFC4851] Section 5.1" - suggest rephrasing to "For FAST, the
session_key_seed is also a part of the key_block..."

6) There are references to implement some EAP-FAST keys with TLS 1.3
similar to TEAP. I think the section about the specific protocol should be
self-contained since the reader may be interested in EAP-FAST but is not
familiar with TEAP. We should also specify the exact key derivation schemes
instead of referencing to TEAP. E.g. "T-PRF is replaced with TLS 1.3
TLS-Exporter function".

7) In addition, since TLS 1.3 allows session resumption using PSK, suggest
to explain explicitly why PAC cannot be supported anymore.

8) "EAP-FAST previously used a PAC, which is a type of pre-shared key
(PSK)" - it is more correct to say "PAC is a session ticket that contains
pre-shared key and other data"
Suggest also directly mentioning the PAC Provisioning RFC5422.

9) Section: 5. Implementation Status
"Implementors have demonstrated significant interest in getting PEAP and
TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS" -
probably the last method should be "TEAP"

10) Section: 7. IANA Considerations
"These labels are used only for TEAP" - should say "...for TEAP and FAST".

11) Section: 8.1. Normative References
RFC 5422 "Dynamic Provisioning Using Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST)" is missing

12) Section: 2.5. PEAP
Some PEAP versions support CryptoBinding. PRF+ is used there so we should
mention that it is replaced with TLS-Exporter also.

13) Section: 3. Application Data
"behavior seen in earlier TLS versions/" - typo, should end with a dot
instead of a slash

14) Section: 3.1. Identities
"Using an anonymous NAI has two benefits. First, an anonymous identity
makes it more difficult to track users.  Second, an NAI allows the EAP
session to be routed in an AAA framework" - could you please explian what
does the second benefit mean?

15) "EAP servers MUST cause authentication to fail if an EAP peer uses an
anonymous "inner" identity for any TLS-based EAP method" - the word "inner"
identity should be always either with double quotes or without. It was
mentioned witout double quotes before and now with them.

16) If there is such a strict requirement "MUST fail" for anonymous
identity used inside the tunnel - then it worth defining exactly what is
anonymous identity

17) "The outer identity contains an NAI realm, which ensures that the inner
authentication method is routed to the correct destination." - suggest
explaining more on how NAI realm is used as outer identity. Should it be in
the form of "[email-masked]" or in any other form?

18) "In general, routing identifiers should be strongly tied to the data
which they are routing" - could you please explain this sentence?

19) Suggest explaining explicitly what the routing identifier is.

20) "The inner identity can then be fully qualified (user name plus realm)
of the organization" - suggest to rephrase "The inner identity can then be
fully qualified name of the organization", since "fully qualified name" is
a standard term

On Fri, Feb 18, 2022 at 7:18 PM Joseph Salowey <[email-masked]> wrote:

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Feb 2022 08:58:14 -0500

On Feb 21, 2022, at 4:26 AM, Oleg Pekar <[email-masked]> wrote:
>    When talking about EAP types "Type = value of the EAP Method type" suggest providing an example of a Type here so it will be clear what is it about for the rest of the document (e.g. for PEAP Type is 0x19)

  It's difficult to tif that into an already long sentence.  I'll see if there's a way to do that.

> 2) Here TLS-Exporter function is mentioned for the first time in the document. Suggest to put a direct reference to the original document where it is defined: 
>    "TLS-Exporter is defined in [RFC8446] section-7.5 as TLS-Exporter(label, context_value, key_length) = HKDF-Expand-Label(Derive-Secret(Secret, label, ""), "exporter", Hash(context_value), key_length).
>    This could help the reader to understand better what do the function parameters mean and what does the function do. Such a reference to a PRF is used in other documents (e.g. TEAP RFC 7170)

  I'd prefer to just reference RFC 9190 Section 2.3.  It would be more confusing to define TLS-Exporter again, in terms of other undefined fields.

> 3) Section: 2.2 TEAP
> "IMSK = TLS-Exporter("[email-masked]", EMSK, 32)" - this may be not clear to the reader since this formula is effective when inner method generates EMSK. It worth mentioning that in other case IMSK is selected per TEAP RFC  

  Sure.  I'll add a reference to 7170.

> 4) In this sentence "For TLS 1.3, the hash function used is the same as the ciphersuite hash function negotiated for HKDF" suggest saying "the MAC function" instead of "the hash function"

  Fixed.

> 5) Section: 2.3. FAST
> "For FAST, the session_key_seed is also used as the key_block, as defined in [RFC4851] Section 5.1" - suggest rephrasing to "For FAST, the session_key_seed is also a part of the key_block..." 

  Fixed.

> 6) There are references to implement some EAP-FAST keys with TLS 1.3 similar to TEAP. I think the section about the specific protocol should be self-contained since the reader may be interested in EAP-FAST but is not familiar with TEAP. We should also specify the exact key derivation schemes instead of referencing to TEAP. E.g. "T-PRF is replaced with TLS 1.3 TLS-Exporter function". 

  Fixed.

> 7) In addition, since TLS 1.3 allows session resumption using PSK, suggest to explain explicitly why PAC cannot be supported anymore. 

  OK, I'll add some text.

> 8) "EAP-FAST previously used a PAC, which is a type of pre-shared key (PSK)" - it is more correct to say "PAC is a session ticket that contains pre-shared key and other data"

  Fixed.

> "Implementors have demonstrated significant interest in getting PEAP and TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS" - probably the last method should be "TEAP"

  Fixed.

  Fixed.

> RFC 5422 "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)" is missing

  I think it should be an Informative reference, as we're not really depending on it, and 5422 is "Informational".  But I suppose it doesn't matter a lot either way.

> 12) Section: 2.5. PEAP
> Some PEAP versions support CryptoBinding. PRF+ is used there so we should mention that it is replaced with TLS-Exporter also.

  The first paragraph of that section makes it clear we're not using the TLS-Exporter here.

> "behavior seen in earlier TLS versions/" - typo, should end with a dot instead of a slash

  Fixed.

> "Using an anonymous NAI has two benefits. First, an anonymous identity makes it more difficult to track users.  Second, an NAI allows the EAP session to be routed in an AAA framework" - could you please explian what does the second benefit mean?

  I'll add a reference to RFC 7542 Section 3.  That text describes routing in an AAA system, using NAIs.

> 15) "EAP servers MUST cause authentication to fail if an EAP peer uses an anonymous "inner" identity for any TLS-based EAP method" - the word "inner" identity should be always either with double quotes or without. It was mentioned witout double quotes before and now with them.

  Fixed.

> 16) If there is such a strict requirement "MUST fail" for anonymous identity used inside the tunnel - then it worth defining exactly what is anonymous identity

   I'll add a reference to RFC 7542 Section 2.4.

> 17) "The outer identity contains an NAI realm, which ensures that the inner authentication method is routed to the correct destination." - suggest explaining more on how NAI realm is used as outer identity. Should it be in the form of "[email-masked]" or in any other form?

  RFC 7542 explains this in detail.  I'll add a reference.

> 18) "In general, routing identifiers should be strongly tied to the data which they are routing" - could you please explain this sentence? 

  If you want some authentication data routed to a destination (via AAA), that's done via an NAI, e.g. "@example.com".  If the authentication data is for a user in realm "example.org", it doesn't make sense to have an NAI of "@example.com".

In general, routing identifiers should agree with the authentication
data which they are routing.  For example, if a user has an inner
identity of "[email-masked]", then it generally makes no sense to
have an outer identity of "@example.org".  The authentication request
could then be routed to the "example.org" domain, which would have no
idea what to do with the credentials for "[email-masked]".  At best,
the authentication request would be discarded.  At worst, the
"example.org" domain could harvest user credentials for use in later
attacks on "example.com".

> 19) Suggest explaining explicitly what the routing identifier is. 

  I'll add a reference to 7542.

> 20) "The inner identity can then be fully qualified (user name plus realm) of the organization" - suggest to rephrase "The inner identity can then be fully qualified name of the organization", since "fully qualified name" is a standard term 

  The term from RFC 7542 is "realm", so it's best to continue using that terminology here.

  Alan DeKok.

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Mon, 21 Feb 2022 15:30:50 +0100

Hi to all,

I have found some small typos.

Section 2.4:

 > There no "context_value" ([RFC8446] Section 7.5) passed to the TLS-
 > Exporter function.

I suppose an "is" is missing.

Section 3:

At the end of the 6th paragraph

 > completely bypass the "inner tunnel" authentication

a dot is missing at the end of the sentence.

Section 3.1:

 > with new identies pointing to the new "cloude"

change to "cloud"

Greetings

Janfred

-- 
E-Mail: [email-masked] | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Feb 2022 14:58:42 -0500

> I have found some small typos.

  Thanks.  I've fixed them all.

  I'll issue a new version at the end of the WGLC.

  Alan DeKok.