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

[Michael Richardson <[e-mail]>]

Joseph Salowey <[e-mail]> 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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [