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 [email protected]
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
