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

Heikki Vatiainen <hvn@radiatorsoftware.com> Mon, 17 May 2021 18:55 UTC

Return-Path: <hvn@radiatorsoftware.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E935E3A0B41 for <emu@ietfa.amsl.com>; Mon, 17 May 2021 11:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sjrfyHXEeFBN for <emu@ietfa.amsl.com>; Mon, 17 May 2021 11:55:53 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A132F3A0B40 for <emu@ietf.org>; Mon, 17 May 2021 11:55:48 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id p7so3791477wru.10 for <emu@ietf.org>; Mon, 17 May 2021 11:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JbLMC2+on8LCRQoD8ak3IXsDzpe7ZGiamk3YQDUVzvk=; b=zz+5A9Y+htEojhhYO5EnPOMCS8PezCXD8s4JdC7R+TpR2FMc82pirHNH5yQkv07DDw c0UY14/nAQoTlzTx3A1PVpokcznm58dkBPNnWKSBffkKlQBJiO1/30i1TcdaYi2OeQ/X tTzw4J6WcWpatc5vTAcUm8Ttq+PW9tuM8+qznrXL+h8KqOtUdkQJZYFZxbU//bsYXfLW cOm/MUzwjc3KkSKblGSTShUX3P0c3E+/3KPyaeUB6+hPu4NjU6PH1Bb7to+sK7b8M8dl 3Tnol7GsziQ24a4Op7cP/2JrzBvu+h4YQNzcfbKs9W5euLmJcNojeYJ0bXrFXDGwRZxo RwJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JbLMC2+on8LCRQoD8ak3IXsDzpe7ZGiamk3YQDUVzvk=; b=H9ijP0niQARZ6UAyScJzy4aoFpXW+L4EEuOR4NJnlG36m3M4IlI5/xrcME8NoECTr0 TFph6CyRA6OB8VCg5Atp5Kb5KMZ0bGb6FKuIYW1xNnzHghFyt/g79ExRftGCYSN1CKmj FFJ0lEAe0JkYkXi4vXo3+pmWgDRAIwJxgbh2/eQAZ8LERw17V+YZfDnIv5EZSrktXDqZ dweLExxjOu4j7gA64UNJNQwMe4pIdpnjYHF4JxWBrezX46IRwsyku7nG78drNBOCEAUO hKCKZ/kkDXRdtowCLOXNmMdINhQNer6Ag0EXISauHY0ADyRj8fKGXIhQuArJUoY0rk2h /+FQ==
X-Gm-Message-State: AOAM531ro0xH2CSMJWilvAL/xjWCvKhOUGJzFW8PdFODNgTfP2/UGrvt AO4+r8Gy0cIfg0au7VYCs+9yKrJDvW4bBD6LfNk2jL9Ihlf0WA==
X-Google-Smtp-Source: ABdhPJxtH83OjIk8HN4hd0dDl6O4KsL4kerCoSvYkfZh1w5GbyTZrB92u7FY3ky1+64da6JvmHeOf9HouJka0cN+yCo=
X-Received: by 2002:a05:6000:1866:: with SMTP id d6mr1343190wri.141.1621277741813; Mon, 17 May 2021 11:55:41 -0700 (PDT)
MIME-Version: 1.0
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Mon, 17 May 2021 21:55:26 +0300
Message-ID: <CAA7Lko87G7Bh2XZcqmn0d=cRjHnBGNxXRTU5xk5TemmPqox4Pg@mail.gmail.com>
To: emu@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e2260905c28b23e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/L5FrR0dZdsczjKiN--7raSWK3ng>
Subject: [Emu] EAP-TLS key derivation and interoperability based on draft 13
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 18:58:51 -0000

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

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