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
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
