Alan, A few things with this text:
I'm having some issues with Section 3.3:
The peer SHOULD verify the validity of the EAP servercertificate and SHOULD also examine the EAP server name presented in the certificate in order to determine whether the EAP server can betrusted.
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 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.In addition,implementations MUST support matching the realm portion of the peer's NAI against a SubjectAltName of type dNSName within the servercertificate.
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, theserver MAY send a TLS hello_request.
Has anyone coded this for TEAP? Also, I think the diagrams in the Appendix may need some updating.
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 may have a few more comments after the weekend. Eliot On 18.08.23 19:13, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.
Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Author : Alan DeKok
Filename : draft-ietf-emu-rfc7170bis-12.txt
Pages : 108
Date : 2023-08-18
Abstract:
This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1. TEAP is a tunnel-based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) protocol to establish a mutually
authenticated tunnel. Within the tunnel, TLV objects are used to
convey authentication-related data between the EAP peer and the EAP
server. This document obsoletes RFC 7170.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-12
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
