Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
On Aug 18, 2023, at 1:49 PM, Eliot Lear wrote: >>> 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. Arguably this belongs in 5216. I'm happy to remove it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
Just to follow up: On 18.08.23 19:47, Alan DeKok wrote: On Aug 18, 2023, at 1:33 PM, Eliot Lear 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
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
On Aug 18, 2023, at 1:33 PM, Eliot Lear 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
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 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. 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. 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. 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
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
Many changes to address comments from Michael and Heikki. * new section on inner method limitations * moved normative text out of Security Considerations section * explained client and server cert issues in the section describing the TEAP protocol * various other clarifications and corner cases > On Aug 18, 2023, at 1:13 PM, 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-rfc7170bis-12.txt
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
