On Mar 11, 2020, at 4:01 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > If I remember correctly, Bernard stated that the indroduction of PSK could > weaken the implementation and violate the security proofs of EAP-TLS. I don't > really agree with Bernard, but I am fine with resticting the type code 0x0D > to certificates only. I am not sure any proofs with TLS 1.1 would apply to > TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and > IANA registers from the old version.
For what it's worth, RFC 5216 doesn't make any statement about PSK. So on a first reading, there are currently no restrictions on using PSK with EAP-TLS, and TLS <= 1.2. There are multiple client / server implementations which support PSK for EAP-TLS. That being said, I'm OK with having one EAP type code for EAP-TLS (certs), and another for EAP-TLS (everything else) I would avoid having multiple EAP types. That would bloat implementations. It's better to just let implementors / admins configure TLS parameters for one EAP type, instead of multiple EAP types. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
