ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track September 21, 2020 Expires: March 25, 2021 OSCORE Profile of ACE v2 draft-palombini-ace-oscore-profile-v2-00 Abstract This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Additionally, this profile provides OSCORE identifiers negotiation between Client and Resource Server. 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 March 25, 2021. Copyright Notice Copyright (c) 2020 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 Palombini Expires March 25, 2021 [Page 1] Internet-Draft OSCORE Profile of ACE v2 September 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 5 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 5 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 6 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 10 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 10 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 11 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 13 7.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 13 7.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 13 7.4. OSCORE Security Context Parameters Registry . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction An OSCORE profile of ACE is defined in [I-D.ietf-ace-oscore-profile]. That profiles describes how to set up OSCORE between nodes, while the OSCORE Sender and Recipient Identifiers, i.e. the identifiers of the OSCORE keying material, are assigned by the Authorization Server. This has some limitations, especially if the OSCORE profile is used in conjuction with other mechamisms that also derive identifiers, in which case there needs to be a mechanism in place to avoid collisions. This document describes a new OSCORE profile that builds on [I-D.ietf-ace-oscore-profile], and adds a mechanism for negotiating identifiers between Client and Resource Server. Palombini Expires March 25, 2021 [Page 2] Internet-Draft OSCORE Profile of ACE v2 September 2020 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in [I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oscore-profile], such as Authorization Server (AS) and Resource Server (RS). Readers are expected to be familiar with the terms and concepts described in [RFC8613], especially on the use of Sender, Recipient and Context Identifiers. 1.2. Background TODO: introduce OSCORE Sender and Recipient Identifiers and how they are used in OSCORE. The OSCORE profile defined in [I-D.ietf-ace-oscore-profile] specifies that the AS assigns and sends the OSCORE Sender and Recipient Identifiers to both Client and RS, together with the rest of the input material to derive the complete OSCORE Security Context. That is done by including these identifiers in the Access Token and Access Information response to the Client. The access token containing these identifiers is also forwarded to the RS by the Client. This works with a number of requirements: the OSCORE profile states that if other authentication mechanisms are used to set up OSCORE between the same client and RS, that do not rely on an AS assigning identifiers, collisions may happen and need to be mitigated. Such mitigation mechanisms also need to be used if a different AS (which does not synchronize identifiers with the first AS) or authentication protocol is used to set up OSCORE between the same RS and other clients. A mitigation example would be to use distinct namespaces of context identifiers for different authentication mechanisms or authentication servers. Another solution would be to use longer random identifiers. A third possible solution, acceptable if collisions are not expected to be numerous, would be to rely on trial and error of security contexts when receiving a message. These solutions have the drawback of requiring either some sort of agreement between different authentication mechanisms using disjoint namespaces for the identifiers, and/or longer identifiers to be used, Palombini Expires March 25, 2021 [Page 3] Internet-Draft OSCORE Profile of ACE v2 September 2020 which leads to larger message sizes, or additional processing on the RS. This document specifies an OSCORE profile that adds a mechanism to assign identifiers on top of the current OSCORE profile, and that allows to set up identifiers without collisions, even when other authentication mechanisms or non-syncrhonized AS are used. What specified in [I-D.ietf-ace-oscore-profile] applies to this profile as well, with the modifications reported in the following sections. Although defining a separate profile, the reader is advised that the [I-D.ietf-ace-oscore-profile] needs to be read side by side with this specification, to understand it. 2. Protocol Overview This section defines the additions to Section 2 of [I-D.ietf-ace-oscore-profile]. Once the client has retrieved the access token, and generated the nonce N1, the Client also generates a Recipient Identifier ID1 for use with the keying material associated to the RS. The client posts the token, N1 and its Recipient ID to the RS using the authz-info endpoint and mechanisms specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. If the access token is valid, the RS replies to this request with a 2.01 (Created) response with Content-Format = application/ace+cbor, which contains a nonce N2 and a newly generated Recipient Identifier ID2 for use with the keying material associated to the Client in a CBOR map. Moreover, the server concatenates the input salt, N1, and N2 to obtain the Master Salt of the OSCORE Security Context (see section 3 of [RFC8613]). The RS then derives the complete Security Context associated with the received token from the Master Salt, the Recipient ID generated by the Client (set as its OSCORE Sender Id), the Recipient ID generated by itself (set as its OSCORE Recipient Id), plus the parameters received in the access token from the AS, following section 3.2 of [RFC8613]. In a similar way, after receiving the nonce N2, the client concatenates the input salt, N1 and N2 to obtain the Master Salt of the OSCORE Security Context. The client then derives the complete Security Context from the Master Salt, the Recipient ID generated by the RS (set as its OSCORE Sender Id), the Recipient ID generated by itself (set as its OSCORE Recipient Id), plus the parameters received from the AS. After the whole message exchange has taken place, the client can contact the AS to request an update of its access rights, sending a Palombini Expires March 25, 2021 [Page 4] Internet-Draft OSCORE Profile of ACE v2 September 2020 similar request to the token endpoint that also includes an identifier so that the AS can find the correct OSCORE security material it has previously shared with the Client. This specific identifier, encoded as a byte string, is set by the AS to be unique in the sets of its OSCORE Security Contexts, and is not used as input material to derive the full OSCORE Security Context. C RS AS | | | | ----- POST /token ----------------------------> | | | | | <---------------------------- Access Token ----- | | + Access Information | | ---- POST /authz-info ---> | | | (access_token, N1, Id1) | | | | | | <- 2.01 Created (N2, Id2)- | | | | | /Sec Context /Sec Context | Derivation/ Derivation/ | | | | | ---- OSCORE Request -----> | | | | | | /proof-of-possession | | Sec Context storage/ | | | | | <--- OSCORE Response ----- | | | | | /proof-of-possession | | Sec Context storage/ | | | | | | ---- OSCORE Request -----> | | | ... | | Figure 1: OSCORE Profile v2 Overview 3. Client-AS Communication The following subsections apply modifications to what specified in Section 3 of [I-D.ietf-ace-oscore-profile]. 3.1. C-to-AS: POST to token endpoint If the client wants to update its access rights without changing an existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object. The req_cnf MUST include a kid field carrying a CBOR byte string containing the Palombini Expires March 25, 2021 [Page 5] Internet-Draft OSCORE Profile of ACE v2 September 2020 OSCORE_Input_Material Identifier (assigned as discussed in Section 3.2). An example of an update of access rights request, with payload in CBOR diagnostic notation without the tag and value abbreviations is reported in Figure 2. Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "token" Content-Format: "application/ace+cbor" Payload: { "req_aud" : "tempSensor4711", "scope" : "write", "req_cnf" : { "kid" : h'01' } Figure 2: Example C-to-AS POST /token request for updating rights to an access token bound to a symmetric key. 3.2. AS-to-C: Access Token The AS can signal that the use of OSCORE is REQUIRED for a specific access token by including the "profile" parameter with the value "coap_oscore_2" in the access token response. The AS MUST send the following data: o a master secret o an identifier of the OSCORE_Input_Material The AS MUST NOT include clientId or serverId, in the OSCORE_Input_Material, neither in the 'cnf' nor in the claims sets associated with the access token. The identifier of the OSCORE_Input_Material MUST be communicated as the 'id' field in the 'osc' field in the 'cnf' parameter of the access token response (and therefore included in the claims associated with the access token). We don't assume in this document that a resource is associated to one single AS, since the AS is not tasked with enforcing uniqueness of identifiers for each client requesting a particular resource to a RS. This profile can also be used together with other authentication mechanisms such as EDHOC, see [I-D.ietf-lake-edhoc]. Palombini Expires March 25, 2021 [Page 6] Internet-Draft OSCORE Profile of ACE v2 September 2020 Figure 3 shows an example of an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. Header: Created (Code=2.01) Content-Type: "application/ace+cbor" Payload: { "access_token" : h'8343a1010aa2044c53 ... (remainder of access token (CWT) omitted for brevity)', "profile" : "coap_oscore_2", "expires_in" : "3600", "cnf" : { "osc" : { "ms" : h'f9af838368e353e78888e1426bd94e6f', "id" : h'01' } } } Figure 3: Example AS-to-C Access Token response with OSCORE profile 2. Figure 4 shows an example CWT Claims Set, including the relevant OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation without tag and value abbreviations. { "aud" : "tempSensorInLivingRoom", "iat" : "1360189224", "exp" : "1360289224", "scope" : "temperature_g firmware_p", "cnf" : { "osc" : { "ms" : h'f9af838368e353e78888e1426bd94e6f', "id" : h'01' } } } Figure 4: Example CWT Claims Set with OSCORE parameters. The same CWT Claims Set as in Figure 4, using the value abbreviations defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in CBOR is shown in Figure 5. The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the '#' sign on the second column, for easiness of readability. Palombini Expires March 25, 2021 [Page 7] Internet-Draft OSCORE Profile of ACE v2 September 2020 A5 # map(5) 63 # text(3) 617564 # "aud" 76 # text(22) 74656D7053656E736F72496E4C6976696E67526F6F6D # "tempSensorInLivingRoom" 63 # text(3) 696174 # "iat" 6A # text(10) 31333630313839323234 # "1360189224" 63 # text(3) 657870 # "exp" 6A # text(10) 31333630323839323234 # "1360289224" 65 # text(5) 73636F7065 # "scope" 78 18 # text(24) 74656D70657261747572655F67206669726D776172655F70 # "temperature_g firmware_p" 63 # text(3) 636E66 # "cnf" A1 # map(1) 63 # text(3) 6F7363 # "osc" A2 # map(2) 62 # text(2) 6D73 # "ms" 50 # bytes(16) F9AF838368E353E78888E1426BD94E6F # "\xF9\xAF\x83\x83h\xE3S\xE7 \x88\x88\xE1Bk\xD9No" 62 # text(2) 6964 # "id" 41 # bytes(1) 01 # "\x01" Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR encoded If the client has requested an update to its access rights using the same OSCORE_Input_Material, which is valid and authorized, the AS MUST omit the 'cnf' parameter in the response, and MUST carry the OSCORE_Input_Material Identifier in the 'kid' field in the 'cnf' parameter of the token. This identifier needs to be included in the token in order for the RS to identify the correct OSCORE Input Material. Palombini Expires March 25, 2021 [Page 8] Internet-Draft OSCORE Profile of ACE v2 September 2020 Figure 6 shows an example of such an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. Header: Created (Code=2.01) Content-Type: "application/ace+cbor" Payload: { "access_token" : h'8343a1010aa2044c53 ... (remainder of access token (CWT) omitted for brevity)', "profile" : "coap_oscore_2", "expires_in" : "3600" } Figure 6: Example AS-to-C Access Token response with OSCORE profile, for update of access rights. Figure 7 shows an example CWT Claims Set, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights, in CBOR diagnostic notation without tag and value abbreviations. { "aud" : "tempSensorInLivingRoom", "iat" : "1360189224", "exp" : "1360289224", "scope" : "temperature_h", "cnf" : { "kid" : h'01' } } Figure 7 3.2.1. OSCORE_Input_Material Object The following parameter is added to the OSCORE_Input_Material object defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. +------------+-------+-------------+------------+--------------+ | name | CBOR | CBOR type | registry | description | | | label | | | | +------------+-------+-------------+------------+--------------+ | identifier | 8 | byte string | | OSCORE Input | | | | | | Material | | | | | | Identifier | +------------+-------+-------------+------------+--------------+ Figure 8: OSCORE_Input_Material Additional Parameters Palombini Expires March 25, 2021 [Page 9] Internet-Draft OSCORE Profile of ACE v2 September 2020 id: This parameter identifies the OSCORE_Input_Material and is encoded as a byte string. In JSON, the "id" value is a Base64 encoded byte string. In CBOR, the "id" type is byte string, and has label 8. 4. Client-RS Communication Additionally to what specified in Section 4 of [I-D.ietf-ace-oscore-profile], the client also generates an identifier id1, unique in the sets of its own Recipient Ids, and posts it together with the token and nonce N1 to the RS. The RS also generates an identifier id2, unique in the sets of its own Recipient Ids, and uses it together with the rest of the input material to derive a security context. Both the nonces and identifiers are encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is used. 4.1. C-to-RS: POST to authz-info endpoint Additionally to what specified in Section 4.1 of [I-D.ietf-ace-oscore-profile], the following applies. The client generates its own Recipient Id for the OSCORE Security Context that it is establishing with the RS. By generating its own Recipient Id, the client makes sure that it does not collide with any of its Recipient Identifiers. The client posts it to the RS together with what is described in Section 4.1 of [I-D.ietf-ace-oscore-profile]: the client includes the Recipient Id in the POST to authz-info request, as an ace_client_recipientid parameter, registered in Section 7.2 and Section 7.3. When receiving the POST to authz-info request including the ace_client_recipientid parameter, the RS MUST set its own Sender Identifier to the value of the ace_client_recipientid. If the ace_client_recipientid parameter is not included in the request, the RS MUST stop processing the request and interrupt the Ace exchange, and MAY reply with a 4.00 (Bad Request) error message. If the access token received contains either the clientId or serverId parameters, the server SHOULD stop processing the message, and MAY reply with a 4.00 (Bad Request) error message. Figure 9 shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. Palombini Expires March 25, 2021 [Page 10] Internet-Draft OSCORE Profile of ACE v2 September 2020 Header: POST (Code=0.02) Uri-Host: "rs.example.com" Uri-Path: "authz-info" Content-Format: "application/ace+cbor" Payload: { "access_token": h'8343a1010aa2044c53 ... (remainder of access token (CWT) omitted for brevity)', "nonce1": h'018a278f7faab55a', "ace_client_recipientid" : h'11' } Figure 9 4.1.1. The ace_client_recipientid Parameter This parameter MUST be sent from the client to the RS, together with the access token and the nonce, if the ace profile used is coap_oscore_2. The parameter is encoded as a byte string for CBOR- based interactions, and as a string (Base64 encoded binary) for JSON- based interactions. This parameter is registered in Section 7.2 and Section 7.3. 4.2. RS-to-C: 2.01 (Created) Additionally to what specified in Section 4.2 of [I-D.ietf-ace-oscore-profile], the following applies. The RS generates its own Recipient Id for the OSCORE Security Context that it is establishing with the client. By generating its own Recipient Id, the RS makes sure that it does not collide with any of its Recipient Identifiers. The RS MUST ensure that id2 is different from the ace_client_recipientid. The RS sends it to the Client together with what is described in Section 4.2 of [I-D.ietf-ace-oscore-profile]: the RS includes the Recipient Id in the 2.01 (Created) response, as a ace_server_recipientid parameter, as registered in Section 7.2 and Section 7.3. When receiving the response including the ace_server_recipientid parameter, the Client MUST set its own Sender Identifier to the value of the ace_server_recipientid and discard any ClientId present in the access token. If the ace_server_recipientid parameter is not included in the response, the client MUST stop processing the response and interrupt the Ace exchange. Figure 10 shows an example of the response sent from the RS to the client, with payload in CBOR diagnostic notation without the tag and value abbreviations. Palombini Expires March 25, 2021 [Page 11] Internet-Draft OSCORE Profile of ACE v2 September 2020 Header: Created (Code=2.01) Content-Format: "application/ace+cbor" Payload: { "nonce2": h'25a8991cd700ac01', "ace_server_recipientid" : h'22' } Figure 10 4.2.1. The ace_server_recipientid Parameter This parameter MUST be sent from the RS to the client, together with the access token and nonce, if the ace profile used is coap_oscore_2. The parameter is encoded as a byte string for CBOR-based interactions, and as a string (Base64 encoded binary) for JSON-based interactions. This parameter is registered in Section Section 7.2 and Section 7.3. 4.3. OSCORE Setup Differently than what defined in Section 4.3 of [I-D.ietf-ace-oscore-profile], the client and RS do not set the Sender ID and Recipient ID from the parameters received from the AS in Section 3.2. Instead, the client MUST set the Sender ID from the ace_server_recipientid received in Section 4.2, and the Recipient ID from its own generated ace_client_recipientid. Conversely, the server MUST set the Sender ID from the ace_client_recipientid received in Section 4.1, and the Recipient ID from its own generated ace_server_recipientid. 5. Security Considerations TODO TBD: How do this profile and the v1 OSCORE profile work together? can the AS send a v1 profile + token and the c and RS try to run a v2? how does c react if it tries to run v2 and get reverted to v1? How do the 2 profiles work together? 6. Privacy Considerations TODO Palombini Expires March 25, 2021 [Page 12] Internet-Draft OSCORE Profile of ACE v2 September 2020 7. IANA Considerations This document has the following actions for IANA. 7.1. ACE Profile Registry The following registration is done for the ACE Profile Registry following the procedure specified in section 8.8 of [I-D.ietf-ace-oauth-authz]: o Name: coap_oscore_2 o Description: Profile for using OSCORE to secure communication between constrained nodes using the Authentication and Authorization for Constrained Environments framework. o CBOR Value: TBD (value between 1 and 255) o Reference: [[This specification]] 7.2. OAuth Parameters Registry The following registrations are done for the OAuth ParametersRegistry following the procedure specified in section 11.2 of [RFC6749]: o Parameter name: ace_client_recipientid o Parameter usage location: client request o Change Controller: IESG o Specification Document(s): [[This specification]] o Parameter name: ace_server_recipientid o Parameter usage location: token response o Change Controller: IESG o Specification Document(s): [[This specification]] 7.3. OAuth Parameters CBOR Mappings Registry The following registrations are done for the OAuth Parameters CBOR Mappings Registry following the procedure specified in section 8.9 of [I-D.ietf-ace-oauth-authz]: * Name: ace_client_recipientid * CBOR Key: TBD (range -256 to 255) * Value Type: byte string * Reference: \[\[This specification\]\] Palombini Expires March 25, 2021 [Page 13] Internet-Draft OSCORE Profile of ACE v2 September 2020 * Name: ace_server_recipientid * CBOR Key: TBD (range -256 to 255) * Value Type: byte string * Reference: \[\[This specification\]\] 7.4. OSCORE Security Context Parameters Registry The following registration is done for the ACE Profile Registry following the procedure specified in section 9.4 of [I-D.ietf-ace-oscore-profile]: This registry will be populated by the values in Figure 8. The specification column for all of these entries will be this document. Acknowledgments This document was started from comments and discussion with the following individuals: John Mattsson, Jim Schaad, Goeran Selander. 9. References 9.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-35 (work in progress), June 2020. [I-D.ietf-ace-oscore-profile] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-ietf-ace- oscore-profile-11 (work in progress), June 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Palombini Expires March 25, 2021 [Page 14] Internet-Draft OSCORE Profile of ACE v2 September 2020 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . 9.2. Informative References [I-D.ietf-lake-edhoc] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- edhoc-01 (work in progress), August 2020. Author's Address Francesca Palombini Ericsson AB Torshamnsgatan 23 Kista SE-16440 Stockholm Sweden Email: francesca.palombini@ericsson.com Palombini Expires March 25, 2021 [Page 15]