On Aug 18, 2023, at 1:33 PM, Eliot Lear <[email protected]> wrote: >> The peer SHOULD verify the validity of the EAP server >> certificate and SHOULD also examine the EAP server name >> presented in >> the certificate in order to determine whether the EAP server >> can be >> trusted. > > How? Let me put this another way: if we don't specify the how, we should > omit the text and leave it as a matter of policy for the peer.
I'll punt, and say the same way as RFC 9190? The subsequent text also references 5280, which contains additional validation rules. So I don't see this text as any different from what's done in 5216, 9190, TTLS, PEAP, etc. >> In addition, >> implementations MUST support matching the realm portion of >> the peer's >> NAI against a SubjectAltName of type dNSName within the >> server >> certificate. > > I interpret that text to mean that the peer MUST verify that the rhs of the > NAI that it sent matches the dnsName of the server cert SAN. The value of > this being to validate that the radius packet has been routed to the right > server? I think this is okay. Yes. > With regard to: > > >> Note that since TLS client certificates are sent in the >> clear with >> TLS 1.2 and earlier, if identity protection is required, >> then it is >> possible for the TLS authentication to be renegotiated after >> the >> first server authentication. To accomplish this, the server >> will >> typically not request a certificate in the server_hello; >> then, after >> the server_finished message is sent and before TEAP Phase 2, >> the >> server MAY send a TLS hello_request. > > > Has anyone coded this for TEAP? Also, I think the diagrams in the Appendix > may need some updating. I don't think anyone has implemented this. > On the following addition: > >> Where the inner method does not provide an MSK or EMSK, the >> Crypto- >> Binding TLV offers little protection, as it cannot tie the >> inner EMSK >> to the TLS session via the TLS-PRF. As a result, the TEAP >> session >> will be vulnerable to on-path active attacks. >> Implementations and >> deployments SHOULD adopt various mitigation strategies >> described in >> [RFC7029] Section 3.2. > > Does this have an impact either with cert ops or the Phase 1 auth and close > as discussed previously? I don't think so. > I may have a few more comments after the weekend. It seems like TEAP will drag on forever :( Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
