On Feb 21, 2022, at 4:26 AM, Oleg Pekar <[email protected]> wrote:
> 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)
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 protected]", 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"
> Suggest also directly mentioning the PAC Provisioning RFC5422.
Fixed.
> 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"
Fixed.
> 10) Section: 7. IANA Considerations
> "These labels are used only for TEAP" - should say "...for TEAP and FAST".
Fixed.
> 11) Section: 8.1. Normative References
> 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.
> 13) Section: 3. Application Data
> "behavior seen in earlier TLS versions/" - typo, should end with a dot
> instead of a slash
Fixed.
> 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?
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 "anonymous@my_ad.example.com" 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 protected]", 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 protected]". 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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
