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

[Oleg Pekar <[e-mail]>]

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("[e-mail]", 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 "anonymous@my_ad.example.com" 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 <[e-mail]> wrote:

> 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
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>