[Emu] EAP-TLS key derivation and interoperability based on draft 13

[Heikki Vatiainen <[e-mail]>]

I'd like to express my support for draft version 13 key derivation.

I just recently joined the list so I'm unable to respond directly to Joe's
message on May 9th.

My main concern from the viewpoint of RADIUS / EAP server maintainer is the
potential bifurcation of implementations and the upcoming RFC. Our server
implementation interoperates with draft version 13 clients, and because it
now seems that Microsoft will ship based a client on draft 13, this will in
effect fixate our server to support draft 13.

Some list members may remember a bit similar case happening with PEAP.
PEAPv1 drafts used 'client PEAP encryption' label with key derivation.
However, a number of clients continued to use 'client EAP encryption'. When
this happened, the only option on the server side that was available was to
have a configuration flag that forced PEAPv1 label to either or. Debugging
this was really hard because even if the authentication completed
successfully, for example in case of Wi-Fi, the client and WLAN AP
encryption keys did not match. All logs looked fine but the radio layer
encryption did not work causing eventual timeouts and debugging nightmare.
Luckily PEAPv1 usage did not become very wide spread.

Based on the above, I think it's extremely important to make sure the
implementations and the specifications match.

The label problem seen with PEAPv1 would be the same with EAP-TLS/TLSv1.3
too if we let it happen. Fortunately it seems that there are no major
reasons to proceed with draft version 13 key derivation. I'm also happy to
support TLS application data 0x00 for messaging. I noticed there was recent
discussion about this with relation to other options.

Radiator first implemented EAP-TLS in 2002 (19 years ago) and is where
RadSec (RFC 6614 - TLS Encryption for RADIUS) first originated from. We
currently interoperate with a number of clients, Android, Apple, Microsoft
and others. Being a server software vendor, we have also been fortunate to
gather experience working with different client and server implementations.
Radiator is used by individual organisations, roaming federations, such as
eduroam, for proxying, authentication and other tasks. I won't go further
but I thought it might be useful to say a little about where we are coming
from.

I'll take a further look at the current draft and past discussion next but
I thought I'd start by replying to Joe's call before the May 20th deadline.

--
Heikki Vatiainen
[e-mail]