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

[<[e-mail]>]

Hi,

On the use of EAP in 5G, I fully agree on the need for expertise sharing on this aspect. And the sooner will be the better.
The work on the technical specifications has already started and 3GPP is more or less like a runaway bulldozer which is quite difficult to stop when in the wrong direction.

Regards,

Lionel


> -----Message d'origine-----
> De : 3gpp-ietf-coord [mailto:[e-mail]] De la part de
> Jari Arkko
> Envoyé : lundi 13 novembre 2017 01:47
> À : Georg Mayer
> Cc : Suresh Chitturi; Ben Campbell; 3GPP_TSG_CT_IETF-
> [e-mail]; [e-mail]; Spencer Dawkins at IETF
> Objet : Re: [3gpp-ietf-coord] 3GPP/IETF Coordination Meeting @ IETF 100
> 
> 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.
> 
> _______________________________________________
> 3gpp-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/3gpp-ietf-coord

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.