Thanks for a very clear document.
There is some redundancy in it but I think that is the correct way to
ensure implementers reading only "their" section get the proper information.
I have a few comments and a some nits:
Comments:
Implementations SHOULD NOT use inner identities which contain an NAI
realm.
Why is this not a MUST NOT ?
All TLS-based EAP methods support resumption, as it is a property of
the underlying TLS protocol. All EAP servers and peers MUST support
resumption for all TLS-based EAP methods.
Should this be "TLSv1.3 based" instead of "TLS-based" ?
5. Implementation Status
This section is missing a direction to the RFC Editor to remove this section
before publication.
NITS:
These links go to the wrong RFC:
2.4.1. Client Certificates
[RFC5281] Section 7.6
and
3.1. Identities
[RFC9190] Sections 2.1.3 and 2.1.7
and
4. Resumption
[RFC9190] Section 2.1.3
and
6. Security Considerations
[RFC9190] Section 5
and
as indicated by Section 2, item 4 of [RFC3748].
For TLS 1.3, the TK should be derived from the Key_Material defined
above in Section 2.1, instead of using the TLS-PRF-128 derivation
given above.
The different use of "above" in one sentence is confusing.
This change can
cause many implementations to fail in a number of different ways, due
to a reliance on implicit behavior seen in earlier TLS versions.
Remove the word "many" ?
u...@example.com
This got rendered as a mailto: link, try to remove the link?
and tje
"and the"
Paul
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
