Just to follow up: On 18.08.23 19:47, Alan DeKok wrote:
On Aug 18, 2023, at 1:33 PM, Eliot Lear <l...@lear.ch> 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.
Upon reflection this might answer my previous “How” question.
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.
This is more of an issue. Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
