Re: [3gpp-ietf-coord] 3GPP/IETF Coordination Meeting @ IETF 100

[Jari Arkko <[e-mail]>]

Thanks, Georg.

I won’t be at the meeting today due to other commitments, but wanted to highlight a couple of items:

* A small group of web experts has been gathered to help provide guidance/feedback to 3GPP SBA efforts. Georg and Gonzalo are running this, so they can talk to this. In the first meeting we had talked about needs for coordination around extensions (or lack thereof), and some general advice. See end of this message. 

* One of the changes in 5G is the support for native authentication to 5G networks using EAP. This probably deserves some awareness-building and discussion just to make sure everyone is on the same page. I’d suggest that we try to get the EAP experts in 3GPP and IETF together on a call in the coming weeks. There’s probably little need for new IETF work (but see below for one minor thing and one opt-in item). However, on the non-3gpp access side, there’s a bigger change in the stack coming, as SA2 and SA3 are planning to create a two-level EAP solution where a new EAP method, EAP-5G, carries the 5G NAS protocol between a UE and the network, and inside that, regular authentication (e.g., EAP-AKA’) happens. I believe the plan is for 3GPP to define the necessary new EAP method themselves.

* Related to EAP, I’m presenting in SAAG about the use of EAP in 5G and have two drafts as well — The first one draft-arkko-eap-rfc5448bis, which is a friendly amendment to update just one reference:

>   This version of the EAP-AKA' specification is an update to RFC 5448.
>   The update is to the reference on how the Network Name field is
>   constructed in the protocol.  The update helps ensure that EAP-AKA'
>   becomes compatible with 5G deployments as well.  RFC 5448 referred to
>   the 2008 version of that reference ([TS-3GPP.24.302]) and this update
>   points to the 5G version of that reference.
> 
>   Arguably, the update is small, as the 3GPP specification number for
>   the updated calculation has not changed, only the version.  But this
>   reference is crucial in correct calculation of the keys resulting
>   from running the EAP-AKA' method, so an update of the RFC with the
>   newest version pointer may be warranted.  As always, feedback is
>   welcome on that point as well as on any other topic within this
>   document.


* Also related to this, there’s a bigger new feature that might be interesting but is not something that is currently demanded by 3GPP, perfect forward secrecy support for EAP-AKA’. We’ve submitted a draft for an extension of EAP-AKA’, opt-in for those who would like to use it. But I wanted to let people know that we’re doing this.

>   Many different attacks have been reported as part of revelations
>   associated with pervasive surveillance.  Some of the reported attacks
>   involved compromising smart cards, such as attacking SIM card
>   manufacturers and operators in an effort to compromise shared secrets
>   stored on these cards.  Since the publication of those reports,
>   manufacturing and provisioning processes have gained much scrutiny
>   and have improved.  However, the danger of resourceful attackers for
>   these systems is still a concern.
> 
>   This specification is an optional extension to the EAP-AKA'
>   authentication method which was defined in RFC 5448.  The extension
>   provides Perfect Forward Secrecy for the session key generated as a
>   part of the authentication run in EAP-AKA'.  This prevents an
>   attacker who has gained access to the long-term pre-shared secret in
>   a SIM card from merely passively eavesdropping the EAP-AKA' exchanges
>   and deriving associated session keys, forcing attackers to use active
>   attacks instead.


Jari

Meeting with the web experts. Since this meeting, Martin Thompson and Salvatore Loreto have also volunteered to help.

> Notes from a discussion between 3GPP-IETF liaisons, 3GPP leadership, and IETF experts on HTTP/2 usage for 3GPP’s new Service Based Architecture (SBA). Discussion happened on October 13, and the participants on the call were Georg Mayer, Lionel Morand, Gonzalo Camarillo, Barry Leiba, Mark Nottingham, and Jari Arkko. Notes by Jari Arkko and Georg Mayer.
> 
> The purpose of the call was to inform the experts on 3GPP’s efforts in designing the SBA, to get advice regarding general approaches to requirements that are likely to come up, and get an understanding of what the process is from the IETF side on any extensions, should there be need for some.
> 
> With SBA, 3GPP is replacing some of the old DIAMETER interfaces with web-based APIs, a bus-like architecture, service discovery, etc. The general architecture is agreed, and the protocol details work is starting in the 3GPP CT4 WG. They have chosen to use HTTP 2, JSON, Open API, and REST (where possible). There are two separate areas of work, one relating to the entirely internal core network functionality, and another one for exposing interfaces towards third parties.
> 
> 3GPP had looked at different protocol choices for their new 5G core network signalling, DIAMETER, HTTP 1.1, HTTP 2, and had decided on HTTP 2. The working groups are discussing further details, and given the architecture and known or inherited requirements from previous generations, need to create a system based on the web APIs. The relevant DIAMETER or AAA functions need to find corresponding implementations in the web side, e.g., for routing AAA requests to the right place or for security facilities. The work on SBA is part of the overall standards effort on 5G, and needs to be completed in about a year, in September 2018.
> 
> The questions we have for the 3GPP experts is what kinds of approaches are reasonable for these kinds of functions, and should extensions of some form be needed, what the process is for them at the IETF.
> 
> Mark: Were you thinking of routing via some form of new HTTP headers specific for the 3GPP application? When extending HTTP, adding new headers is generally easy, but adding methods or status codes is harder. And if you need to change how message exchange work or how they are routed then you’re not really doing HTTP any more and should label your protocol something else. I’m starting to think that for the core network internal part, one might want to define HTTP/2 as a base, add/substract from that but identify the protocol as not HTTP/2 but something else.
> 
> Jari: We shouldn’t jump directly to a particular design. Need to take a step back and ask what the function is that we are trying to achieve, and ask first what the best way to achieve that is. Copying DIAMETER design 1-1 to web APIs may not be the best approach, the stacks are different, other solutions may be a better match. Barry: Agree with that.
> 
> Georg & Jari: Looking back at the SIP design process, 3GPP submitted requirements, IETF then worked on solutions. Does that apply here? Perhaps, but the web platform may also be different in the sense that millions of applications build systems on top of it, and how they do it is not something that the IETF coordinates. However, it would be good to get advice from web experts on how some functions are best achieved. The 3GPP is new into this space, and it is not always clear what potential solutions are for instance already available somewhere. Bringing design problems to the experts would be very useful. In any case, one should be free to think about the potential solutions, not only requirements, but at the same time keeping the mind open that we may get information about different, better approaches to some problems. 
> 
> All: Talked about ways of getting feedback from the IETF on specific problems. First requirement is to have descriptions of specific needs. We could ask feedback on the IETF HTTPBIS working group mailing list, but perhaps it would be more productive to gather a set of individuals willing to help, and discuss with them initially. Many possible responses are possible, from “that’s fine”, “just do it in your application”, “there’s a solution X for that already”, “use new headers”, “for that we need a new general purpose extension”, or “that’s very different from HTTP, if you need that then you are not really using HTTP”. Spending a little bit of time now to get the design right would benefit the overall timeline, even if you have to invest some time now. E.g., if you find out that there already are facilities or good design rules to do something, you may be able to skip developing an unnecessary HTTP extension. The web experts at the IETF are of course also busy on many topics, but if there are key question marks on some aspects of using the web protocols, they probably have some time to help so that the right solutions are found. This help can be informal, however, rather than publishing an official spec through the IETF.
> 
> Mark: Note also that the working group is starting some work (https://mnot.github.io/I-D/bcp56bis/) on how other protocols can use HTTP/2. This can be helpful. Lionel: Is there an document that describes how to extend http? Mark: Primarily it is just the IANA registries and documents themselves, see http://httpwg.org/specs/ and the bfcp56bis work.
> 
> What’s the process for developing different classes of extensions? Mark outlined the options:
> 
> 1/ Functionality in your application — you can do it yourself. No need for extensions or talking to the IETF.
> 
> 2/ Functionality in new HTTP headers — there’s a registry, and you want to use the permanent registry. SDOs can add to this registry without IETF process beyond talking to IANA or Designated Experts. Jari: Can you advice us on when to do a header ourselves vs. taking it to the IETF. Mark: Just have clear communication channel, informing people what is happening on IETF side. No need for IETF process. For truly generic new headers perhaps there would be value of defining it in IETF, but perhaps that’s unlikely. See RFC 3864 for the process. Jari: One reason 3GPP is using web technology is the use of the broad set of tools available for it. How do new headers affect that? Mark: Usually not an issue, things like new metadata should be fine. One should not break message delimiting or other similar things, however.
> 
> 3/ Functionality in new methods and status codes — These are always expected to be general, not application specific. Approach these types of extensions with caution. IETF standards process required.
> 
> 4/ Functionality in new HTTP/2 frame types and other extensions — These are possible, but not really designed to be application visible. If you were to need these, you need to call your protocol something else than HTTP/2, or develop a generic extension to all users of HTTP/2. Not recommended.
> 
> 5/ Functionality that needs major new generic or specific features — would take a lot of time. We know that there are some applications that have requirements that HTTP/2 doesn’t meet, but could met with major work. Not recommended, try to avoid having requirements that lead to this.
> 
> Jari: Final question, how would you design a protocol that does what typical traditional AAA applications do, e.g., have multiple hops through a chain of AAA servers or AAA proxies, and be able to do processing at some level at those hops? And assume that you may be deploying TLS/HTTPS at some point. I think the HTTP headers are inside the inner TLS session even if you go through proxies.
> 
> Mark: That’s right. And proxy functionality in AAA and HTTP may use the same term but be actually different. Do you design so that it matches the current platform. First thing I’d be looking at is selection of resource and URIs, and what payloads can be carried. I would recommend looking at orchestration of resources at the application level, i.e., making a request to a URI/resource at a proxy, which then causes as a side-effect a request to another URI/resource at the next server. This way you know that you can make your application do exactly what you want.
> 
> Next steps: We will gather a group of web experts in the IETF space that are willing to look at these issues. In a week there will be another meeting of the 3GPP CT groups, and we will have more information of the kinds of design problems that 3GPP tries to find solutions for. We can also let the 3GPP know that if they have specific design problems, we are happy to take a look.
> 
> These notes can be distributed to anyone interested in this topic, e.g., the relevant 3GPP CT groups.