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

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Dec 2018 17:32:52 +0200

Alan,

Circling back to this.

I’ll first agree with your summary about the importance of the tech, that there’s some risk but the risk is likely low but non-zero, and that in an ideal situation you wouldn’t have to deal with this.

However, I would like to point out that

* The draft is an *optional* extension to something bigger, and no one is forced to implement it.

* Regardless of that, even the base RFC had a similar IPR associated with it back in ‘09, so any discussion about an extension’s properties should be set in that context. A problem in the extension cannot be bigger than a problem in what the extension builds on, no? Not to mention the context of say, 5G phones.

Neither me or you can change that context or even the situation with the base. Perhaps the world should operate on other kinds of rules, but what we have here is a tool that could have a real impact on billions of users’ security, and I think we could make it do that. But we need a standard. Can we have that?

Jari

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Dec 2018 11:14:55 -0500

> * The draft is an *optional* extension to something bigger, and no one is forced to implement it.

  I don't quite understand that argument.  It's superficially true, but not really correct.

  If a product is to be at all competitive in a landscape where the "big players" require this, then the product *must* implement it.  The alternative is to cede market share, revenue, etc.

  Standards do live in a larger environment than just the standards bodies.  They affect all kinds of things.

> * Regardless of that, even the base RFC had a similar IPR associated with it back in ‘09, so any discussion about an extension’s properties should be set in that context. A problem in the extension…

  If the IPR is new (I haven't checked), then it could potentially add to the problem, yes.

> Neither me or you can change that context or even the situation with the base. Perhaps the world should operate on other kinds of rules, but what we have here is a tool that could have a real impac…

  I agree absolutely that this is needed and useful.  I've said that before.

  The underlying issue here is that a company has gained control over part of the standard space.  And we rely only on their good will for continued use of an open standard.  That tends to make me nervous.

  Alan DeKok.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Dec 2018 18:23:21 +0200

Re: optional but everyone requiring a feature.
 
I think in this case the “can require everyone to do it” is probably far away in the future, in practice. Given that Release 15 does not require this extension, it only requires RFC 5448 EAP-AKA’ (or the bis), this means that there will be lots of phones and networks that only do the base… if you mandated an extension you’d have lots of users having a problem connecting. 

It is not completely unthinkable that at some point you’d be in a situation where there’s enough deployment to start requiring something, but that would certainly be many years away. Plus some portion of 5G deployment happens in so called Option 3 model, which means no new core, no new protocols (incl. EAP) between the network and the UE. Before you can progress away from that and the RFC 5448-only modes, much time will pass.

Jari

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Dec 2018 11:38:00 -0500

> I think in this case the “can require everyone to do it” is probably far away in the future, in practice. Given that Release 15 does not require this extension, it only requires RFC 5448 EAP-AKA’ (…

  Sure.

> It is not completely unthinkable that at some point you’d be in a situation where there’s enough deployment to start requiring something, but that would certainly be many years away. Plus some port…

  I've been doing my thing for 20 years.  I'm not going anywhere, so I'm thinking about the long term.

  Anyways, I think this is necessary.

  Alan DeKok.