[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ACE Working Group                                           F. Palombini
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                               M. Tiloca
Expires: December 29, 2018                                     RISE SICS
                                                           June 27, 2018


           Key Provisioning for Group Communication using ACE
                  draft-palombini-ace-key-groupcomm-01

Abstract

   This document defines a message format for distributing keying
   material in group communication scenarios (such as based on multicast
   or publisher-subscriber model) using the ACE framework.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 29, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Palombini & Tiloca      Expires December 29, 2018               [Page 1]


Internet-Draft             Key Prov Group Comm                 June 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Addition to the Group . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Authorization Request . . . . . . . . . . . . . . . . . .   4
     3.2.  Authorization Response  . . . . . . . . . . . . . . . . .   5
     3.3.  Token Post  . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Key Distribution  . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Key Distribution Request  . . . . . . . . . . . . . . . .   7
     4.2.  Key Distribution Response . . . . . . . . . . . . . . . .   7
   5.  Remove a Node from the Group  . . . . . . . . . . . . . . . .   9
     5.1.  Not authorized anymore  . . . . . . . . . . . . . . . . .   9
     5.2.  Request to Leave the Group  . . . . . . . . . . . . . . .   9
   6.  Retrieval of Updated Keying Material  . . . . . . . . . . . .  10
     6.1.  Key Re-Distribution Request . . . . . . . . . . . . . . .  10
     6.2.  Key Re-Distribution Response  . . . . . . . . . . . . . .  10
   7.  Retrieval of Public Keys for Group Members  . . . . . . . . .  10
     7.1.  Public Key Request  . . . . . . . . . . . . . . . . . . .  11
     7.2.  Public Key Response . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
   define the format of messages used to distribute the keying material
   in a group communication scenario.  Profiles that use group
   communication can build on this document to specify exactly which of
   the message parameters defined in this documents are used, and what
   are their values.  Known applications that can benefit from this
   document would be, for example, profiles addressing group
   communication based on multicast [RFC7390] or publishing/subscribing
   [I-D.ietf-core-coap-pubsub] in ACE.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.



Palombini & Tiloca      Expires December 29, 2018               [Page 2]


Internet-Draft             Key Prov Group Comm                 June 2018


   Readers are expected to be familiar with the terms and concepts
   described in [I-D.ietf-ace-oauth-authz] and [RFC8152].

2.  Overview

       +-----------+                  +-----------+
       |     AS    |                  |    KDC    |
       |           |        .-------->|           |
       +-----------+       /          +-----------+
             ^            /
             |           /
             v          /                           +-----------+
       +-----------+   /      +------------+        |+-----------+
       |   Client  |<-'       | Dispatcher |        ||+-----------+
       |           |<-------->|    (RS)    |<------->||   Group   |
       +-----------+          +------------+         +|  members  |
                                                      +-----------+


                  Figure 1: Key Distribution Participants

   Participants:

   o  Client: Node that wants to join the group communication.  It can
      either want write rights or read rights.

   o  AS: Same as AS in the ACE Framework; it contains policies, and
      knows if a node is allowed to join the group with write or read
      rights.

   o  Key Distribution Center: Maintains the keying material to protect
      group communications, and provides it to clients authorized to
      join the group.  During the first part of the exchange, it
      corresponds to the RS in the ACE Framework.

   o  Dispatcher: this is the entity the Client wants to securely
      communicate with and is responsible for distribution of group
      messages.  It can be an existing node, such as the Broker in a
      pub-sub setting (in which case the Dispatcher is also a RS), or it
      can be implicit, as in the multicast communication setting, where
      the message distribution is done by transmitting to a multicast IP
      address, and entrusting message delivery to the transport channel.

   This document specifies the message flows and formats for adding a
   node to a group, as well as for the distribution of keying material
   to joining nodes.  Also, it briefly mentions the node's removal from
   a group and the consequent rekeying process.




Palombini & Tiloca      Expires December 29, 2018               [Page 3]


Internet-Draft             Key Prov Group Comm                 June 2018


   The high level overview of the message flow for a node joining a
   group communication setting is shown in Figure 2.

   C                 AS               KDC           Dispatcher
   |                 |                 |                 | \
   |  authorization  |                 |                 | |
   |-----request---->|                 |                 | | defined in
   |                 |                 |                 | | the ACE
   |  authorization  |                 |                 | | framework
   |<----response----|                 |                 | |
   |                 |                 |                 | |
   |--------token post---------------->|                 | /
   |                 |                 |                 |
   |----key distribution request------>|                 |
   |                 |                 |                 |
   |<---key distribution response------|                 |
   |                 |                 |                 |
   |<=============protected communication===============>|
   |                 |                 |                 |

                  Figure 2: Key Distribution Message Flow

3.  Addition to the Group

   This section describes in detail the message formats exchanged by the
   participants when a node requests access to the group.  The first
   part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz],
   where the KDC takes the role of RS.

3.1.  Authorization Request

   The Authorization Request sent from the Client to the AS (as defined
   in [I-D.ietf-ace-oauth-authz], Section 5.6.1, MUST contain the
   following parameters:

   o  grant_type, with value "client_credentials".

   Additionally, the Authorization Request MAY contain the following
   parameters, which, if included, MUST have the corresponding values:

   o  scope, with value the identifier of the specific group or topic
      the Client wishes to access, as well as the role the Client wishes
      to take, if necessary.  This value is a CBOR array encoded as a
      byte string, which contains:

      *  as first element, the identifier of the specific group or topic





Palombini & Tiloca      Expires December 29, 2018               [Page 4]


Internet-Draft             Key Prov Group Comm                 June 2018


      *  optionally, as second element, the role (or CBOR array of
         roles) the Client wishes to take in the group

      How exactly the group or topic identifier and the roles are
      encoded is application specific.

   o  aud, with value an identifier of the KDC.

   o  cnf, containing the public key (or certificate) of the Client, if
      it wishes to communicate that to the AS.

   o  Other additional parameters as defined in
      [I-D.ietf-ace-oauth-authz], if necessary.

3.2.  Authorization Response

   The Authorization Response sent from the AS to the Client (as defined
   in [I-D.ietf-ace-oauth-authz], Section 5.6.2, MUST contain the
   following parameters:

   o  access_token, containing all the parameters defined below
      (including the same 'scope' as in this message, if present, or the
      'scope' of the Authorization Request otherwise), and additionally
      other optional parameters the profile requires.

   o  cnf if symmetric keys are used, not present if asymmetric keys are
      used, contains the symmetric pop key that the Client is supposed
      to use with the KDC.

   o  rs_cnf if asymmetric keys are used, contains information about the
      public key of the KDC.  Not present if symmetric keys are used.

   o  exp, contains the lifetime in seconds of the access token.  This
      parameter MAY be omitted if the application defines how the
      expiration time is communicated to the Client via other means, or
      if it establishes a default value.

   Additionally, the Authorization Response MAY contain the following
   parameters, which, if included, MUST have the corresponding values:

   o  scope, which mirrors the 'scope' parameter in the Authorization
      Request Section 3.1.  Its value is a CBOR array encoded as a byte
      string, containing:

      *  as first element, the identifier of the specific group or topic
         the Client is authorized to access.





Palombini & Tiloca      Expires December 29, 2018               [Page 5]


Internet-Draft             Key Prov Group Comm                 June 2018


      *  optionally, as second element, the role (or CBOR array of
         roles) the Client is authorized to take in the group.

      How exactly the group or topic identifier and the roles are
      encoded is application specific.

   o  Other additional parameters as defined in
      [I-D.ietf-ace-oauth-authz], if necessary.

   When receiving an Authorization Request from a Client that was
   previously authorized, and which still owns a valid non expired
   Access Token, the AS can simply reply with an Authorization Response
   including a new Access Token.

3.3.  Token Post

   The Client sends a CoAP POST request including the Access Token to
   the KDC, as specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz].
   If the specific profile defines it, the Client MAY use a different
   endpoint at the KDC to post the Access Token to.  After successful
   verification, the Client is authorized to receive the group keying
   material from the KDC and join the group.

   Note that this step could be merged with the following message from
   the Client to the KDC, namely Key Distribution Request.

4.  Key Distribution

   This section defines how the keying material used for group
   communication is distributed from the KDC to the Client, when joining
   the group as a new member.

   The same types of messages can also be used for the following cases,
   when the Client is already a group member:

   o  The Client wishes to (re-)get the current keying material, for
      cases such as expiration, loss or suspected mismatch, due to e.g.
      reboot or missed rekeying.  This is further discussed in
      Section 6.

   o  The Client wishes to (re-)get the public keys of other group
      members, e.g. if it is aware of new nodes joining the group after
      itself.  This is further discussed in Section 7.








Palombini & Tiloca      Expires December 29, 2018               [Page 6]


Internet-Draft             Key Prov Group Comm                 June 2018


4.1.  Key Distribution Request

   The Client sends a Key Distribution request to the KDC.  This
   corresponds to a CoAP POST request to the endpoint in the KDC
   associated to the group (which is associated in the KDC to the
   'scope' value of the Authorization Request/Response).  The payload of
   this request is a CBOR Map which MAY contain the following fields,
   which, if included, MUST have the corresponding values:

   o  scope, with value the specific resource or topic identifier and
      role(s) that the Client is authorized to access, encoded as in
      Section 3.1.

   o  get_pub_keys, if the Client wishes to receive the public keys of
      the other nodes in the group from the KDC.  The value is an empty
      CBOR Array.  This parameter may be present if the KDC stores the
      public keys of the nodes in the group and distributes them to the
      Client; it is useless to have here if the set of public keys of
      the members of the group is known in another way, e.g. it was
      supplied by the AS.

   o  client_cred, with value the public key or certificate of the
      Client.  If the KDC is managing (collecting from/distributing to
      the Client) the public keys of the group members, this field
      contains the public key of the Client.

   o  pub_keys_repos, can be present if a certificate is present in the
      client_cred field, with value a list of public key repositories
      storing the certificate of the Client.

4.2.  Key Distribution Response

   The KDC verifies the Access Token and, if verification succeeds,
   sends a Key Distribution success Response to the Client.  This
   corresponds to a 2.01 Created message.  The payload of this response
   is a CBOR Map which MUST contain the following fields:

   o  key, used to send the keying material to the Client, as a COSE_Key
      ([RFC8152]) containing the following parameters:

      *  kty, as defined in [RFC8152].

      *  k, as defined in [RFC8152].

      *  exp (optionally), as defined below.  This parameter is
         RECOMMENDED to be included in the COSE_Key.  If omitted, the
         authorization server SHOULD provide the expiration time via
         other means or document the default value.



Palombini & Tiloca      Expires December 29, 2018               [Page 7]


Internet-Draft             Key Prov Group Comm                 June 2018


      *  alg (optionally), as defined in [RFC8152].

      *  kid (optionally), as defined in [RFC8152].

      *  base iv (optionally), as defined in [RFC8152].

      *  clientID (optionally), as defined in
         [I-D.ietf-ace-oscore-profile].

      *  serverID (optionally), as defined in
         [I-D.ietf-ace-oscore-profile].

      *  kdf (optionally), as defined in [I-D.ietf-ace-oscore-profile].

      *  slt (optionally), as defined in [I-D.ietf-ace-oscore-profile].

      *  cs_alg (optionally), containing the algorithm value to
         countersign the message, taken from Table 5 and 6 of [RFC8152].

   The parameter 'exp' identifies the expiration time in seconds after
   which the COSE_Key is not valid anymore for secure communication in
   the group.  A summary of 'exp' can be found in Figure 3.

     +------+-------+----------------+------------+-----------------+
     | Name | Label | CBOR Type      | Value      | Description     |
     |      |       |                | Registry   |                 |
     +------+-------+----------------+------------+-----------------+
     | exp  | TBD   | Integer or     | COSE Key   | Expiration time |
     |      |       | floating-point | Common     | in seconds      |
     |      |       | number         | Parameters |                 |
     +------+-------+----------------+------------+-----------------+

             Figure 3: COSE Key Common Header Parameter 'exp'

   Additionally, the Key Distribution Response MAY contain the following
   parameters, which, if included, MUST have the corresponding values:

   o  pub_keys, may only be present if get_pub_keys was present in the
      Key Distribution Request; this parameter is a COSE_KeySet (see
      [RFC8152]), which contains the public keys of all the members of
      the group.

   o  group_policies, with value a list of parameters indicating how the
      group handles specific management aspects.  This includes, for
      instance, approaches to achieve synchronization of sequence
      numbers among group members.  The exact format of this parameter
      is specific to the profile.




Palombini & Tiloca      Expires December 29, 2018               [Page 8]


Internet-Draft             Key Prov Group Comm                 June 2018


   o  mgt_key_material, with value the administrative keying material to
      participate in the revocation and renewal of group keying
      (rekeying) performed by the KDC.  The exact format and content
      depend on the specific rekeying algorithm used in the group, which
      may be specified in the profile.

   Specific profiles need to specify how exactly the keying material is
   used to protect the group communication.

   TBD: define for verification failure

5.  Remove a Node from the Group

   This section describes at a high level how a node can be removed from
   the group.

5.1.  Not authorized anymore

   If the node is not authorized anymore, the AS can directly
   communicate that to the KDC.  Alternatively, the Access Token might
   have expired.  If Token introspection is provided by the AS, the KDC
   can use it as per Section 5.7 of [I-D.ietf-ace-oauth-authz], in order
   to verify that the Access Token is still valid.

   Either case, once aware that a node is not authorized anymore, the
   KDC has to generate and distribute the new keying material to all
   authorized members of the group, as well as to remove the
   unauthorized node from the list of members (if the KDC keeps track of
   that).  The KDC relies on the specific rekeying algorithm used in the
   group, such as e.g.  [RFC2093], [RFC2094] or [RFC2627], and the
   related management key material.

5.2.  Request to Leave the Group

   A node can actively request to leave the group.  In this case, the
   Client can send a request to the KDC to exit the group.  The KDC can
   then generate and distribute the new keying material to all
   authorized members of the group, as well as remove the leaving node
   from the list of members (if the KDC keeps track of that).

   Note that, as long as the node is authorized to join the group, i.e.
   it has a valid Access Token, it can re-request to join the group
   directly to the KDC without needing to retrieve a new Access Token.
   This means that the KDC needs to keep track of nodes with valid
   Access Tokens, before deleting all information about the leaving
   node.





Palombini & Tiloca      Expires December 29, 2018               [Page 9]


Internet-Draft             Key Prov Group Comm                 June 2018


6.  Retrieval of Updated Keying Material

   A node stops using the group keying material upon its expiration,
   according to the 'exp' parameter specified in the retained COSE Key.
   Then, if it wants to continue participating in the group
   communication, the node has to request new updated keying material to
   the KDC.

   The Client may perform the same request to the KDC also upon
   receiving messages from other group members without being able to
   correctly decrypt them.  This may be due to a previous update of the
   group keying material (rekeying) triggered by the KDC, that the
   Client was not able to participate to.

   Note that policies can be set up so that the Client sends a request
   to the KDC only after a given number of unsuccessfully decrypted
   incoming messages.

6.1.  Key Re-Distribution Request

   To request a re-distribution of keying material, the Client sends a
   shortened Key Distribution request to the KDC (Section 4.1),
   formatted as follows.  The payload MAY contain only the following
   field:

   o  scope, which contains only the identifier of the specific group or
      topic, encoded as in Section 3.1.  That is, the role field is not
      present.

   In some cases, it is not necessary to include the scope parameter,
   for instance if the KDC maintains a list of active group members for
   each managed group, and the Client is member of only one group.  The
   Client MUST include the scope parameter if it is a member of multiple
   groups under the same KDC.

6.2.  Key Re-Distribution Response

   The KDC replies to the Client with a Key Distribution Response
   containing the 'key' parameter, and optionally 'group_policies' and
   'mgt_key_material', as specified in Section 4.2.  Note that this
   response might simply re-provide the same keying material currently
   owned by the Client, if it has not been renewed.

7.  Retrieval of Public Keys for Group Members

   In case the KDC maintains the public keys of group members, a node in
   the group can contact the KDC to request public keys of either all




Palombini & Tiloca      Expires December 29, 2018              [Page 10]


Internet-Draft             Key Prov Group Comm                 June 2018


   group members or a specified subset, using the messages defined
   below.

   Note that these messages can be combined with the Key Re-Distribution
   messages in Section 6, to request at the same time the keying
   material and the public keys.  In this case, either a new endpoint at
   the KDC may be used, or additional information needs to be sent in
   the request payload, to distinguish these combined messages from the
   Public Key messages described below, since they would be identical
   otherwise.

7.1.  Public Key Request

   To request public keys, the Client sends a shortened Key Distribution
   request to the KDC (Section 4.1), formatted as follows.  The payload
   of this request MUST contain the following field:

   o  get_pub_keys, which has for value a CBOR array including either:

      *  no elements, i.e. an empty array, in order to request the
         public key of all current group members; or

      *  N elements, each of which is the identifier of a group member,
         in order to request the public key of the specified nodes.

   Additionally, this request MAY contain the following parameter,
   which, if included, MUST have the corresponding value:

   o  scope, which contains only the identifier of the specific group or
      topic, encoded as in Section 3.1.  That is, the role field is not
      present.

      In some cases, it is not necessary to include the scope parameter,
      for instance if the KDC maintains a list of active group members
      for each managed group, and if the specified identifiers allow to
      retrieve public keys with no ambiguity.  The Client MUST include
      the scope parameter if it is a member of multiple groups under the
      same KDC.

   If the KDC can not unambiguously identify the nodes specified in the
   'get_pub_keys' parameter, it MUST reply with an error message.  In
   this case, the Client can issue a new Public Key Request specifying
   the group in the 'scope' parameter.

   TODO: define error






Palombini & Tiloca      Expires December 29, 2018              [Page 11]


Internet-Draft             Key Prov Group Comm                 June 2018


7.2.  Public Key Response

   The KDC replies to the Client with a Key Distribution Response
   containing only the 'pub_keys' parameter, as specified in
   Section 4.2.  The payload of this response contains the following
   field:

   o  pub_keys, which contains either:

      *  the public keys of all the members of the group, if the
         'get_pub_keys' parameter of the Public Key request was an empty
         array; or

      *  the public keys of the group members with the identifiers
         specified in the 'get_pub_keys' parameter of the Public Key
         request.

   The KDC ignores possible identifiers included in the 'get_pub_keys'
   parameter of the Public Key request if they are not associated to any
   current group member.

8.  Security Considerations

   The KDC must renew the group keying material upon its expiration.

   The KDC should renew the keying material upon group membership
   change, and should provide it to the current group members through
   the rekeying algorithm used in the group.

9.  IANA Considerations

   The following registration is required for the COSE Key Common
   Parameter Registry specified in Section 16.5 of [RFC8152]:

   o  Name: exp

   o  Label: TBD

   o  CBOR Type: Integer or floating-point number

   o  Value Registry: COSE Key Common Parameters

   o  Description: Identifies the expiration time in seconds of the COSE
      Key

   o  Reference: [[this specification]]





Palombini & Tiloca      Expires December 29, 2018              [Page 12]


Internet-Draft             Key Prov Group Comm                 June 2018


10.  References

10.1.  Normative References

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12
              (work in progress), May 2018.

   [I-D.ietf-ace-oscore-profile]
              Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander,
              "OSCORE profile of the Authentication and Authorization
              for Constrained Environments Framework", draft-ietf-ace-
              oscore-profile-01 (work in progress), March 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

10.2.  Informative References

   [I-D.ietf-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", draft-ietf-core-coap-pubsub-04 (work in
              progress), March 2018.

   [RFC2093]  Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Specification", RFC 2093,
              DOI 10.17487/RFC2093, July 1997,
              <https://www.rfc-editor.org/info/rfc2093>.

   [RFC2094]  Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Architecture", RFC 2094,
              DOI 10.17487/RFC2094, July 1997,
              <https://www.rfc-editor.org/info/rfc2094>.

   [RFC2627]  Wallner, D., Harder, E., and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627,
              DOI 10.17487/RFC2627, June 1999,
              <https://www.rfc-editor.org/info/rfc2627>.



Palombini & Tiloca      Expires December 29, 2018              [Page 13]


Internet-Draft             Key Prov Group Comm                 June 2018


   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <https://www.rfc-editor.org/info/rfc7390>.

Acknowledgments

   The following individuals were helpful in shaping this document: Ben
   Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz and Goeran Selander.

   The work on this document has been partly supported by the EIT-
   Digital High Impact Initiative ACTIVE.

Authors' Addresses

   Francesca Palombini
   Ericsson AB
   Torshamnsgatan 23
   Kista  SE-16440 Stockholm
   Sweden

   Email: francesca.palombini@ericsson.com


   Marco Tiloca
   RISE SICS
   Isafjordsgatan 22
   Kista  SE-16440 Stockholm
   Sweden

   Email: marco.tiloca@ri.se




















Palombini & Tiloca      Expires December 29, 2018              [Page 14]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/