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

From: Joseph Salowey <[email-masked]>
Date: Thu, 8 Nov 2018 10:13:06 +0700

At the IETF 103 meeting there was support in the room to adopt
draft-arkko-eap-aka-pfs-03.txt as a working group item as the basis to add
perfect forward secrecy to EAP-AKA.  This message is to confirm that
consensus.  If you do not support adoption of
draft-arkko-eap-aka-pfs-03.txt as WG item please say so by 2359UTC on 30
November 2018 (and say why).

The draft is available at
https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt.

Thanks,

Joe

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 8 Nov 2018 10:23:24 +0700

Please note there are IPR disclosure for draft-arkko-eap-aka-pfs-03.txt
<https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt> available at
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-arkko-eap-aka-pfs
.

Thanks,

Joe

---

From: "Dr. Pala" <[email-masked]>
Date: Sat, 10 Nov 2018 05:52:35 -0500

Hi all,

I am in favor of addressing the issue of PFS in 3GPP authentication - it 
is important work that moves cellular network authentication towards 
more modern approaches and more compatible with IETF technologies.

This said, I am concerned about the fact that the IPR is not marked as 
Royalty-Free, therefore I am not in favor of adopting it if the IPR 
restrictions (fees) are not removed (please let me know if I am 
mis-interpreting the IPR declaration). I think I missed this point 
(maybe the jet lag, but it might not have been clear to the room).

As a possible way forward (if IPR restrictions are not modified), we 
could work on something different that is not encumbered by patents 
restrictions. However, for this, we would need to see the specific 
claims of the application...

Cheers,
Max

On 11/7/18 10:23 PM, Joseph Salowey wrote:
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-arkko-eap-aka-pfs.
>
> Thanks,
>
> Joe
>
> On Thu, Nov 8, 2018 at 10:13 AM Joseph Salowey <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     draft-arkko-eap-aka-pfs-03.txt as a working group item as the
>     basis to add perfect forward secrecy to EAP-AKA.  This message is
>     to confirm that consensus.  If you do not support adoption of
>     draft-arkko-eap-aka-pfs-03.txt as WG item please say so by 2359UTC
>     on 30 November 2018 (and say why).
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Nov 2018 09:39:53 -0500

> On Nov 10, 2018, at 5:52 AM, Dr. Pala <[email-masked]> wrote:
> 
> Hi all,
> 
> I am in favor of addressing the issue of PFS in 3GPP authentication - it is important work that moves cellular network authentication towards more modern approaches and more compatible with IETF technologies.
> 
> This said, I am concerned about the fact that the IPR is not marked as Royalty-Free, therefore I am not in favor of adopting it if the IPR restrictions (fees) are not removed (please let me know if I am mis-interpreting the IPR declaration). I think I missed this point (maybe the jet lag, but it might not have been clear to the room). 
> 
> As a possible way forward (if IPR restrictions are not modified), we could work on something different that is not encumbered by patents restrictions. However, for this, we would need to see the specific claims of the application...

  I share these concerns.

  Alan DeKok.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Nov 2018 10:32:00 +0200

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Nov 2018 07:12:42 -0500

> 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 instanc…

  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 do…

  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.