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

Alan DeKok <aland@deployingradius.com> Wed, 28 November 2018 12:12 UTC

Return-Path: <aland@deployingradius.com>
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 1AAEE12D4EF for <emu@ietfa.amsl.com>; Wed, 28 Nov 2018 04:12:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 hF9SN8PSdxE9 for <emu@ietfa.amsl.com>; Wed, 28 Nov 2018 04:12:45 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDC128CE4 for <emu@ietf.org>; Wed, 28 Nov 2018 04:12:45 -0800 (PST)
Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id EA31A370; Wed, 28 Nov 2018 12:12:43 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <932256A8-6381-4EE9-95B2-C56B4E7F52D5@piuha.net>
Date: Wed, 28 Nov 2018 07:12:42 -0500
Cc: "Dr. Pala" <director@openca.org>, emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <98AB9912-1110-47F8-A4B0-94CB2E6A302E@deployingradius.com>
References: <CAOgPGoBGZWbyHYybnMUbKG77Mei3yBOS1HyS4Uso1HKgxq1VNg@mail.gmail.com> <CAOgPGoAvGm7gfgAHsPHHdO9OU601wp=NY2fb9YjQyh0h6cy3nQ@mail.gmail.com> <45e7325b-f5d1-c4b8-edb2-3e39d03989fe@openca.org> <39E1238A-2E39-4FF4-89C3-2B549C1EA84F@deployingradius.com> <932256A8-6381-4EE9-95B2-C56B4E7F52D5@piuha.net>
To: Arkko Jari <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ku-62sPaygXeIERiLDD47F8yP_Y>
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 12:12:48 -0000

On Nov 28, 2018, at 3:32 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> However, I think it would be useful to understand the situation:

  i.e. No one has gotten sued for this before.  That doesn't mean they won't get sued.

  The typical practice here is that the patent holders ignore the Open Source authors.  They're scattered in many countries, and have shallow pockets.  Instead, the patent holders go after the *users* of the Open Source programs.  They're often in the same jurisdiction, and have deeper pockets.  This is happening today, and has been going on for years.
  
> 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.

  If it's an android phone, it doesn't implement EAP-AKA'.  An Open Source tool (wpa_supplicant) implements EAP-AKA', and the phone just uses the library.  So your phone *is* an Open Source implementation of EAP-AKA', and everyone involved (potentially including you) is subject to suit for patent infringement.  If your phone is an iPhone, maybe they licensed the patents.  (Apple has implemented their own supplicant).

> Also, a likely use case for this is in 5G, but in a (say) 5G phone there will be other technologies, not all unencumbered.

  I'm happy to let *other* people agree to whatever they want for using encumbered technologies.  I have concerns with "open standards" using non-open technologies.

  Some standards bodies have a habit of using encumbered technologies.  These standards bodies usually have high cost to entry, complex, obtuse specifications, and often cross-licensing.  Even if the standards bodies don't mandate cross-licensing, the individual companies can do this:

https://www.ipwatchdog.com/2018/08/03/ericsson-lg-global-cross-licensing-agreement-2g-3g-4g-mobile-seps/id=99897/

  The issue for Open Source people is that everything they do is in the open.  So there's usually no patents, not the least because there's no money for patents.  Which means cross-licensing as a defence is impossible.  And the Open Source people find it difficult (in practice) go after companies for license violations.  When the other side has lawyers on retainer, and you're trying to find funding for a new laptop, the sales of justice are massively imbalanced.

> 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.

  It is a conundrum.

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

  I agree completely.

> 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?

  It suggests that the risk may be low.  But the risk is there.

  TBH, there's no good solution for this situation.  It's needed, but at the same time anyone using it is opening themselves to lawsuits that they can't afford to defend, much less lose.

  Alan DeKok.