On Tue, 27 Sep 2022, at 13:25, [email protected] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the EAP Method Update WG of the IETF. > > Title : TLS-based EAP types and TLS 1.3 > Author : Alan DeKok > Filename : draft-ietf-emu-tls-eap-types-09.txt > Pages : 21 > Date : 2022-09-27
Whilst picking through the TEAP RFC7170(bis) section 3.2 I stumbled on: "TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current ciphersuite." This language looks lifted from from the EAP-FAST (RFC4851 section 3.2). This exists so that for TLS 1.2 (and earlier) you can provide identity privacy and mutual authentication during Phase 1. As TLS 1.3 already provides the identity privacy, I think retaining the SHOULD is a good idea for backwards compatible as well as creating minimal changes to existing implementations. I do think we should highlight in the various 'Client Certificates' sub-sections that now doing the immediate renegotiation is no longer necessary. Thanks _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
