On Jan 11, 2023, at 8:02 PM, Paul Wouters <paul.wout...@aiven.io> wrote: > 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.
Thanks, I agree. > Comments: > > Implementations SHOULD NOT use inner identities which contain an NAI > realm. > > Why is this not a MUST NOT ? There was significant discussion about this. I would prefer a MUST NOT, but there were reasons for allowing a realm. IIRC it was things like separating routing from identity. The outer realm routes to a particular destination. However, that destination may authentication people from multiple realms. And those realms have to exist in the inner tunnel. > 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" ? I'm ambivalent. The text leaves it open for later TLS versions, which seems fine. > > 5. Implementation Status > > This section is missing a direction to the RFC Editor to remove this section > before publication. Added, thanks. > > NITS: > > These links go to the wrong RFC: > > 2.4.1. Client Certificates > > [RFC5281] Section 7.6 I think that's correct. It's not discussing EAP-TLS use of client certs. I can clarify that this reference is for TTLS. The other links seem correct, too. I'm not sure which other RFC they should point to? > 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. Perhaps: For TLS 1.3, the TK should be derived from the Key_Material defined here in Section 2.1, instead of using the TLS-PRF-128 derivation given in [PEAP-PRF]. > > 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" ? Yes. > u...@example.com > > This got rendered as a mailto: link, try to remove the link? I think that's an artifact of the conversion to XML. I'll see if I can address it. > and tje > > "and the" Fixed, thanks. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
