Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

Jari Arkko <jari.arkko@piuha.net> Wed, 28 November 2018 08:32 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D096E130E4A for <emu@ietfa.amsl.com>; Wed, 28 Nov 2018 00:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmBKgQtlz0AT for <emu@ietfa.amsl.com>; Wed, 28 Nov 2018 00:32:04 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 670C412D4ED for <emu@ietf.org>; Wed, 28 Nov 2018 00:32:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AA98466028B; Wed, 28 Nov 2018 10:32:02 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37jH85XiDV5W; Wed, 28 Nov 2018 10:32:01 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 46E13660154; Wed, 28 Nov 2018 10:32:01 +0200 (EET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <39E1238A-2E39-4FF4-89C3-2B549C1EA84F@deployingradius.com>
Date: Wed, 28 Nov 2018 10:32:00 +0200
Cc: emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <932256A8-6381-4EE9-95B2-C56B4E7F52D5@piuha.net>
References: <CAOgPGoBGZWbyHYybnMUbKG77Mei3yBOS1HyS4Uso1HKgxq1VNg@mail.gmail.com> <CAOgPGoAvGm7gfgAHsPHHdO9OU601wp=NY2fb9YjQyh0h6cy3nQ@mail.gmail.com> <45e7325b-f5d1-c4b8-edb2-3e39d03989fe@openca.org> <39E1238A-2E39-4FF4-89C3-2B549C1EA84F@deployingradius.com>
To: "Dr. Pala" <director@openca.org>, Alan DeKok <aland@deployingradius.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/3gOEF6LUbhqoYaIOKOkxsAFSun8>
Subject: Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs
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: Wed, 28 Nov 2018 08:32:07 -0000

Max, Alan,

First, thank you for your review and expressing that this is an important step in moving the mobile network authentication schemes to present-day crypto approaches :-)

With regards to the IPR question, I want to stay away from discussing anyone’s licensing conditions, as I don’t represent anyone and also because of anti-trust.

However, I think it would be useful to understand the situation:

The proposed specification is an extension of RFC 5448 or EAP-AKA'. That RFC already had a similar IPR declaration from someone else, back 10 years ago when it was being specified. Yet, the declared or other potential IPR constraints do not appear to have slowed the adoption of this RFC in the industry. The phone that I’m writing this on implements EAP-AKA’ for instance. And there are open source implementations. Also, a likely use case for this is in 5G, but in a (say) 5G phone there will be other technologies, not all unencumbered.

We could do this particular extension in a different way to avoid this particular license, but it wouldn’t necessarily resolve all issues. In addition, new technical issues might arise. For instance, I predict that the ability to perform PFS in the same number of roundtrips for the registration exchange is important for the potential adoption of this. I wouldn’t want to trade that away for instance, if using different technology meant doing that.

Finally, I think we really need this for the users.

So from my perspective there’s a clear need for this and I see no evidence that previous situations in this particular case have slowed deployment in any fashion. Also, this particular extension doesn’t change the overall situation with regards to EAP-AKA’. Does that help reduce your concerns?

Jari