On May 23, 2024, at 6:48 AM, Gunter Van de Velde via Datatracker <nore...@ietf.org> wrote: > #GENERIC COMMENTS > #================ > 275 authentication, or a vendor-specific authentication method. > Where > 276 the TLS connection is authenticated, the inner method could also > 277 be a PKCS exchange. > > can the PKCS (Public Key Cryptography Standards) be expanded upon first usage?
Done. > 291 As discussed in [RFC9190] Section 2.1.7 and [RFC9427] Section 3.1, > 292 the outer EAP Identity SHOULD be an anonymous NAI Network Access > 293 Identifier (NAI) as descrived in [RFC7542], Section 2.4. While > > Twice usage of NAI in the phrase construct Fixed. > s/descrived/described/ Fixed. > 301 Any inner identities (EAP or otherwise) SHOULD also follow the > 302 recommendations of [RFC9427] Section 3.1. > > The recommendations are slightly tucked away in RFC9427 sec3.1 > Maybe the phrase should be more explicit that its about the recommendations > about inner identifies from 3.1 as that section handles more as only inner > identities Done. > 335 of the TEAP server, and handles the application data (inner > methods, > 336 EAP, passwords, etc.) inside of the TLS tunnel. > > Maybe my little knowledge about TEAP/EAP, but the application data mentioned > here is all about security. Maybe it should be spelled out more explicit that > this is data used by EAP? The rest of the document discusses how the EAP server handles the inner tunnel data, so I think it's already explicit that the data is handled by EAP. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
