Alan DeKok wrote:
>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.
What does "avoid having multiple EAP types" refer to?
Does this mean you would like to avoid "EAP-TLS (certs), and another for
EAP-TLS (everything else)", even If you can accept it
Or are you saying that you want to avoid EAP-TLS (cert), EAP-TLS (psk), EAP-TLS
(pwd), etc....
John
-----Original Message-----
From: Alan DeKok <[email protected]>
Date: Wednesday, 11 March 2020 at 12:26
To: John Mattsson <[email protected]>
Cc: Russ Housley <[email protected]>, Mohit Sethi M
<[email protected]>, EMU WG <[email protected]>
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13
On Mar 11, 2020, at 4:01 AM, John Mattsson
<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
