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

From: Joseph Salowey <[email-masked]>
Date: Tue, 2 Apr 2019 22:37:28 -0700

Thanks for reviving this thread.  I agree this is important work, but we
need to have consensus to bring the item into the working group.  I think
the IPR issue is the main sticking point.

I'll note that RFC 5448 has a similar IPR declaration and both documents
are targeted as informational.   Some possible ways forward:

1. Come up with an alternative proposal.  Since no one has already stepped
forward I don't think this is realistic.
2. Accept the document into the working group.
3. Reject the document, which will force the work to go through the
independent submission process, which will probably result in less broad
and thorough review.
4. Amendment to the license terms of the IPR - I have received no
indication that this will happen

The document will likely get published in either case 2 or 3 above.  I'd
like to work through this discussion over the next few weeks so please
voice your views on this thread.

Thanks,
Joe

On Sat, Mar 30, 2019 at 5:53 PM Michael Richardson <[email-masked]>
wrote:

>
> 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.
>
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Apr 2019 07:59:37 -0400

On Apr 3, 2019, at 1:37 AM, Joseph Salowey <[email-masked]> wrote:
> 
> Thanks for reviving this thread.  I agree this is important work, but we need to have consensus to bring the item into the working group.  I think the IPR issue is the main sticking point. 
> 
> I'll note that RFC 5448 has a similar IPR declaration and both documents are targeted as informational.   Some possible ways forward:
> 
> 1. Come up with an alternative proposal.  Since no one has already stepped forward I don't think this is realistic. 
> 3. Reject the document, which will force the work to go through the independent submission process, which will probably result in less broad and thorough review.  
> 4. Amendment to the license terms of the IPR - I have received no indication that this will happen
> 
> The document will likely get published in either case 2 or 3 above.  I'd like to work through this discussion over the next few weeks so please voice your views on this thread.  

  Despite my misgivings, I think (2) is necessary here.

  It would be helpful for the IETF as a whole to acknowledge the importance of Open Source in the IETF process.  And, that "RAND" licensing isn't necessarily RAND when fees are involved.

  e.g. "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee" 

  OK, *what* is that fee?  A million dollars for a 5G operator / vendor?  How much should an Open Source implementation pay?

  Alan DeKok.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 3 Apr 2019 18:46:53 +0300

Michael,

Thanks for your comments.

A couple of responses: with regards to deployment, there’s some amount of EAP SIM/AKA deployment, but until now it hasn’t been for the primary mobile network access. It was only used for Wireless LANs when you have a SIM card. Nevertheless, both protocols are very widely implemented and very likely available on your phone. Future usage is a guess, of course. 5G has two mandatory-to-implement authentication approaches for mobile networks: the traditional, native AKA and EAP (which defaults to EAP-AKA’). That is a much bigger potential for usage. An optimistic future is where the use of EAP in this context grows, and we use it to evolve the authentication so that improvements can be more easily and frequently added. A less optimistic future is one where we don’t really change the protocols to defend against new attacks, e.g., pervasive monitoring. I don’t know which future will actually happen but I’m willing to work towards the better one :-)

With regards to IMSI catchers, John already responded.

And about the difficult-to-read sentences… I can work on that. Thanks for the feedback.

With regards to the AT_KDF text that you quoted, that’s not new, it was part of RFC 5448, but can surely be improved. But the basic idea is that if the server proposes KDFs A, B, and C, then if A is acceptable to the peer, it will just do it. If A wants something else then it needs to propose it by responding to the server by sending the AT_KDF attribute back. If it sends A then obviously something is wrong, that should not happen and the server will refuse to do that. The peer needs to send either B or C, and then the server will use the chosen one in the next round of messages.

With regards to new versions and putting things in one or multiple documents, my opinion is that 5448 clarifications deserve to be done separately from significant new functionality such as the PFS. If we do complete the PFS work and the IETF feels like stating it is required to implement, we can state that at that time. But, I think now is too early.

With regards to AT_BIDDING, it is on purpose there only to prevent bidding down from EAP-AKA’ to EAP-AKA. And again unchanged from RFC 5448 (the diffs are here btw: http://www.arkko.com/ietf/eap/draft-ietf-emu-rfc5448bis-from-rfc5448.diff.html <http://www.arkko.com/ietf/eap/draft-ietf-emu-rfc5448bis-from-rfc5448.diff.html>). It is true that one could (probably) design a more general facility to protect against bidding down attacks in EAP more generally. Again, that feels like a separate and fairly significant piece of work. The specific EAP-AKA/EAP-AKA’ case solves an important subclass of the general problem, though, and has been around for a long time.

Jari