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

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Mar 2019 21:57:42 +0100

Joseph Salowey <[email-masked]> wrote:
    > 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).

I don't think that this was decided.
At least, I did not find a message about this in the archives!

I implemented server side EAP-SIM and EAP-AKA back 16 some years ago.
Based upon the many emails I got asking for help configuring EAP-SIM, and
the zero I got for EAP-AKA, I have never been sure to what extend AKA
really go out there.  Is the nano-SIM in my phone SIM or did it mutate into
AKA?  I never quite knew.

I was always very sad that AKA did not get more uptake as it authenticates
the network to the phone, and therefore would have (as I understand things)
defended against "Stingray" like equipment used without judicial review,
requiring interceptors to significantly involve telco in such things, and
limiting who they would actually "catch".  ... I've heard other claims too.

So anything that prevents AKA' from being taken on seems like a significant
thing to me!

I re-read pfs-04, and wound up reading draft-ietf-emu-rfc5448bis-04, which I
had not read before.  I found the extensive references to TS-3GPP.24 made
that document rather hard to read, but at least I can download them easily,
unlike some other SDOs.  There are also some awkward sentences where maybe
a pass through with a language editor would help.

for instance:
   Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the
   peer, the server checks that the suggested AT_KDF value was one of
   the alternatives in its offer.  The first AT_KDF value in the message
   from the server is not a valid alternative.  If the peer has replied
   with the first AT_KDF value, the server behaves as if AT_MAC of the
   response had been incorrect and fails the authentication.

I couldn't understand this at all.
You sure you want to call this EAP-AKA', and not EAP-AKA2 ?
That lone single quote seems to be asking for problems in code to me.

section 4:
   This mechanism comes in the form of the
   AT_BIDDING attribute.  This allows both endpoints to communicate
   their desire and support for EAP-AKA' when exchanging EAP-AKA
   messages.  This attribute is not included in EAP-AKA' messages as
   defined in this RFC.  It is only included in EAP-AKA messages.

Why not include it in EAP-AKA'?  You assume that there isn't a third
mechanism which should not be bid down to EAP-AKA' (some EAP-TLS or
something).

As I understand it, AT_KDF is an alternate KDF for EAP-AKA', and the
KDF is negotiated between the parties.   It seems like a reasonable thing to
do from a technical point of view, and the implementation seems rather simple
and straightforward.

====

I followed the link to the IPR page, but I have not (and won't) read the
patent.  Having read the pseudo code in section 6.3, I can't see how it's
significantly different than IKEv2.  If there is something novel here, I
don't know what it might be.

I found it interesting the IPR claim has the word "Possible", which
kind of makes one wonder:
    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee
I think that it is a template though, not something they chose.
The difference between RAND and RF is significant to open source projects.
Why is the claim duplicated, I also wonder.

If draft-arkko-eap-aka-pfs is important, I think it should be folded into
draft-ietf-emu-rfc5448bis.  It seems terribly useful to me, and if we are
going to have it, I'd rather have it by default.

Compared to when EAP-AKA was defined, the use of open source systems to
enable roaming is very very very significant.  If open source eco-systems
feel there is FUD here, then I think it is important to think hard.

Entities that want 5G to succeed, should think hard about whether litigating
this patent is more important than 5G succeeding for roaming.

Finally, I want to point to: https://lwn.net/Articles/780078/

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Alan DeKok <[email-masked]>
Date: Sat, 30 Mar 2019 09:34:17 -0400

> The difference between RAND and RF is significant to open source projects.

  Very much so.  Especially since few projects have funding, much less funding to pay for things like this.

> going to have it, I'd rather have it by default.

  I'm OK with them being two separate documents, but they should be closely tied.

> feel there is FUD here, then I think it is important to think hard.

  The patent issues are non-trivial.

  Let's be realistic about the IETF.  While we pretend that we have individual contributors, the reality is that large companies fund huge chunks of it.  Those companies effectively shield individual contributors from patent lawsuits.  i.e. no one will sue an employee of Cisco about a standard, they will instead sue Cisco directly.

  Michael and I have no such protection.  As an implementor of EAP-SIM and EAP-AKA, he may be personally liable.  As the person hosting the web site and source code, I may also be personally liable.

  That liability means we're very concerned about these issues.  In contrast, a Cisco employee might be "personally involved" in litigation by being deposed.  During work hours, while getting paid a normal salary.

  And realistically, Open Source has driven the explosion of tech companies in the past 10 years.  I think few companies could have been profitable if they had paid license fees for an OS, web server, etc.  So there should be a vested interest in protecting open source as part of the IETF standardization process.

> this patent is more important than 5G succeeding for roaming.

  That's assuming the litigation group talks to the engineering group.  Large companies can have internal groups at odds with each other.

> Finally, I want to point to: https://lwn.net/Articles/780078/

  It may take $1M to get to the point where such legal arguments matter.  That rules out such a defence for me.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 20:53:11 -0400

Alan DeKok <[email-masked]> wrote:
    >   Let's be realistic about the IETF.  While we pretend that we have
    > individual contributors, the reality is that large companies fund huge
    > chunks of it.  Those companies effectively shield individual
    > contributors from patent lawsuits.  i.e. no one will sue an employee of
    > Cisco about a standard, they will instead sue Cisco directly.

Actually, nobody seems to sue the majors except other majors.
Nobody seems to sue small entities that have no money except patent trolls.

    >   Michael and I have no such protection.  As an implementor of EAP-SIM
    > and EAP-AKA, he may be personally liable.  As the person hosting the
    > web site and source code, I may also be personally liable.

I don't think you can be sued for patent infringemenet for writing about
the patent, only for using it.    Copyright, yes, but not patents.

    >   And realistically, Open Source has driven the explosion of tech
    > companies in the past 10 years.  I think few companies could have been
    > profitable if they had paid license fees for an OS, web server, etc.
    > So there should be a vested interest in protecting open source as part
    > of the IETF standardization process.

I agree with you, and so it borders on seriously insulting to open source
authors to have these super-vague IPR claims show up from non-technical
lawyers.

Let me restate my original opinion:
   - if this is important to 5G, then anything that gets in the way of
     adoption is a problem.  If it's not important enough to fix the IPR,
     then it's actually that important.
   - adopting AKA is very important.