On Thu, Jan 12, 2023 at 11:34 AM Alan DeKok <al...@freeradius.org> wrote:
> 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. > Ok. > > > 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. > I was more thinking that TLS 1.3 has resumption, but older TLS versions might not as it was not in the core TLS document at the time but as an extension ? > 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. > All the links in this sextion say "[RFCxxxx] Section N.M" but actually point to THIS document section N.M > > > 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]. > Ok. Paul
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
