idnits 2.17.1 draft-palombini-ace-key-groupcomm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2018) is 2129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-12 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-01 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track M. Tiloca 5 Expires: December 29, 2018 RISE SICS 6 June 27, 2018 8 Key Provisioning for Group Communication using ACE 9 draft-palombini-ace-key-groupcomm-01 11 Abstract 13 This document defines a message format for distributing keying 14 material in group communication scenarios (such as based on multicast 15 or publisher-subscriber model) using the ACE framework. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 29, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Addition to the Group . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 4 56 3.2. Authorization Response . . . . . . . . . . . . . . . . . 5 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Key Distribution Request . . . . . . . . . . . . . . . . 7 60 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 7 61 5. Remove a Node from the Group . . . . . . . . . . . . . . . . 9 62 5.1. Not authorized anymore . . . . . . . . . . . . . . . . . 9 63 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 9 64 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 10 65 6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 10 66 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 10 67 7. Retrieval of Public Keys for Group Members . . . . . . . . . 10 68 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 11 69 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 10.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 81 define the format of messages used to distribute the keying material 82 in a group communication scenario. Profiles that use group 83 communication can build on this document to specify exactly which of 84 the message parameters defined in this documents are used, and what 85 are their values. Known applications that can benefit from this 86 document would be, for example, profiles addressing group 87 communication based on multicast [RFC7390] or publishing/subscribing 88 [I-D.ietf-core-coap-pubsub] in ACE. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. These 95 words may also appear in this document in lowercase, absent their 96 normative meanings. 98 Readers are expected to be familiar with the terms and concepts 99 described in [I-D.ietf-ace-oauth-authz] and [RFC8152]. 101 2. Overview 103 +-----------+ +-----------+ 104 | AS | | KDC | 105 | | .-------->| | 106 +-----------+ / +-----------+ 107 ^ / 108 | / 109 v / +-----------+ 110 +-----------+ / +------------+ |+-----------+ 111 | Client |<-' | Dispatcher | ||+-----------+ 112 | |<-------->| (RS) |<------->|| Group | 113 +-----------+ +------------+ +| members | 114 +-----------+ 116 Figure 1: Key Distribution Participants 118 Participants: 120 o Client: Node that wants to join the group communication. It can 121 either want write rights or read rights. 123 o AS: Same as AS in the ACE Framework; it contains policies, and 124 knows if a node is allowed to join the group with write or read 125 rights. 127 o Key Distribution Center: Maintains the keying material to protect 128 group communications, and provides it to clients authorized to 129 join the group. During the first part of the exchange, it 130 corresponds to the RS in the ACE Framework. 132 o Dispatcher: this is the entity the Client wants to securely 133 communicate with and is responsible for distribution of group 134 messages. It can be an existing node, such as the Broker in a 135 pub-sub setting (in which case the Dispatcher is also a RS), or it 136 can be implicit, as in the multicast communication setting, where 137 the message distribution is done by transmitting to a multicast IP 138 address, and entrusting message delivery to the transport channel. 140 This document specifies the message flows and formats for adding a 141 node to a group, as well as for the distribution of keying material 142 to joining nodes. Also, it briefly mentions the node's removal from 143 a group and the consequent rekeying process. 145 The high level overview of the message flow for a node joining a 146 group communication setting is shown in Figure 2. 148 C AS KDC Dispatcher 149 | | | | \ 150 | authorization | | | | 151 |-----request---->| | | | defined in 152 | | | | | the ACE 153 | authorization | | | | framework 154 |<----response----| | | | 155 | | | | | 156 |--------token post---------------->| | / 157 | | | | 158 |----key distribution request------>| | 159 | | | | 160 |<---key distribution response------| | 161 | | | | 162 |<=============protected communication===============>| 163 | | | | 165 Figure 2: Key Distribution Message Flow 167 3. Addition to the Group 169 This section describes in detail the message formats exchanged by the 170 participants when a node requests access to the group. The first 171 part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz], 172 where the KDC takes the role of RS. 174 3.1. Authorization Request 176 The Authorization Request sent from the Client to the AS (as defined 177 in [I-D.ietf-ace-oauth-authz], Section 5.6.1, MUST contain the 178 following parameters: 180 o grant_type, with value "client_credentials". 182 Additionally, the Authorization Request MAY contain the following 183 parameters, which, if included, MUST have the corresponding values: 185 o scope, with value the identifier of the specific group or topic 186 the Client wishes to access, as well as the role the Client wishes 187 to take, if necessary. This value is a CBOR array encoded as a 188 byte string, which contains: 190 * as first element, the identifier of the specific group or topic 191 * optionally, as second element, the role (or CBOR array of 192 roles) the Client wishes to take in the group 194 How exactly the group or topic identifier and the roles are 195 encoded is application specific. 197 o aud, with value an identifier of the KDC. 199 o cnf, containing the public key (or certificate) of the Client, if 200 it wishes to communicate that to the AS. 202 o Other additional parameters as defined in 203 [I-D.ietf-ace-oauth-authz], if necessary. 205 3.2. Authorization Response 207 The Authorization Response sent from the AS to the Client (as defined 208 in [I-D.ietf-ace-oauth-authz], Section 5.6.2, MUST contain the 209 following parameters: 211 o access_token, containing all the parameters defined below 212 (including the same 'scope' as in this message, if present, or the 213 'scope' of the Authorization Request otherwise), and additionally 214 other optional parameters the profile requires. 216 o cnf if symmetric keys are used, not present if asymmetric keys are 217 used, contains the symmetric pop key that the Client is supposed 218 to use with the KDC. 220 o rs_cnf if asymmetric keys are used, contains information about the 221 public key of the KDC. Not present if symmetric keys are used. 223 o exp, contains the lifetime in seconds of the access token. This 224 parameter MAY be omitted if the application defines how the 225 expiration time is communicated to the Client via other means, or 226 if it establishes a default value. 228 Additionally, the Authorization Response MAY contain the following 229 parameters, which, if included, MUST have the corresponding values: 231 o scope, which mirrors the 'scope' parameter in the Authorization 232 Request Section 3.1. Its value is a CBOR array encoded as a byte 233 string, containing: 235 * as first element, the identifier of the specific group or topic 236 the Client is authorized to access. 238 * optionally, as second element, the role (or CBOR array of 239 roles) the Client is authorized to take in the group. 241 How exactly the group or topic identifier and the roles are 242 encoded is application specific. 244 o Other additional parameters as defined in 245 [I-D.ietf-ace-oauth-authz], if necessary. 247 When receiving an Authorization Request from a Client that was 248 previously authorized, and which still owns a valid non expired 249 Access Token, the AS can simply reply with an Authorization Response 250 including a new Access Token. 252 3.3. Token Post 254 The Client sends a CoAP POST request including the Access Token to 255 the KDC, as specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 256 If the specific profile defines it, the Client MAY use a different 257 endpoint at the KDC to post the Access Token to. After successful 258 verification, the Client is authorized to receive the group keying 259 material from the KDC and join the group. 261 Note that this step could be merged with the following message from 262 the Client to the KDC, namely Key Distribution Request. 264 4. Key Distribution 266 This section defines how the keying material used for group 267 communication is distributed from the KDC to the Client, when joining 268 the group as a new member. 270 The same types of messages can also be used for the following cases, 271 when the Client is already a group member: 273 o The Client wishes to (re-)get the current keying material, for 274 cases such as expiration, loss or suspected mismatch, due to e.g. 275 reboot or missed rekeying. This is further discussed in 276 Section 6. 278 o The Client wishes to (re-)get the public keys of other group 279 members, e.g. if it is aware of new nodes joining the group after 280 itself. This is further discussed in Section 7. 282 4.1. Key Distribution Request 284 The Client sends a Key Distribution request to the KDC. This 285 corresponds to a CoAP POST request to the endpoint in the KDC 286 associated to the group (which is associated in the KDC to the 287 'scope' value of the Authorization Request/Response). The payload of 288 this request is a CBOR Map which MAY contain the following fields, 289 which, if included, MUST have the corresponding values: 291 o scope, with value the specific resource or topic identifier and 292 role(s) that the Client is authorized to access, encoded as in 293 Section 3.1. 295 o get_pub_keys, if the Client wishes to receive the public keys of 296 the other nodes in the group from the KDC. The value is an empty 297 CBOR Array. This parameter may be present if the KDC stores the 298 public keys of the nodes in the group and distributes them to the 299 Client; it is useless to have here if the set of public keys of 300 the members of the group is known in another way, e.g. it was 301 supplied by the AS. 303 o client_cred, with value the public key or certificate of the 304 Client. If the KDC is managing (collecting from/distributing to 305 the Client) the public keys of the group members, this field 306 contains the public key of the Client. 308 o pub_keys_repos, can be present if a certificate is present in the 309 client_cred field, with value a list of public key repositories 310 storing the certificate of the Client. 312 4.2. Key Distribution Response 314 The KDC verifies the Access Token and, if verification succeeds, 315 sends a Key Distribution success Response to the Client. This 316 corresponds to a 2.01 Created message. The payload of this response 317 is a CBOR Map which MUST contain the following fields: 319 o key, used to send the keying material to the Client, as a COSE_Key 320 ([RFC8152]) containing the following parameters: 322 * kty, as defined in [RFC8152]. 324 * k, as defined in [RFC8152]. 326 * exp (optionally), as defined below. This parameter is 327 RECOMMENDED to be included in the COSE_Key. If omitted, the 328 authorization server SHOULD provide the expiration time via 329 other means or document the default value. 331 * alg (optionally), as defined in [RFC8152]. 333 * kid (optionally), as defined in [RFC8152]. 335 * base iv (optionally), as defined in [RFC8152]. 337 * clientID (optionally), as defined in 338 [I-D.ietf-ace-oscore-profile]. 340 * serverID (optionally), as defined in 341 [I-D.ietf-ace-oscore-profile]. 343 * kdf (optionally), as defined in [I-D.ietf-ace-oscore-profile]. 345 * slt (optionally), as defined in [I-D.ietf-ace-oscore-profile]. 347 * cs_alg (optionally), containing the algorithm value to 348 countersign the message, taken from Table 5 and 6 of [RFC8152]. 350 The parameter 'exp' identifies the expiration time in seconds after 351 which the COSE_Key is not valid anymore for secure communication in 352 the group. A summary of 'exp' can be found in Figure 3. 354 +------+-------+----------------+------------+-----------------+ 355 | Name | Label | CBOR Type | Value | Description | 356 | | | | Registry | | 357 +------+-------+----------------+------------+-----------------+ 358 | exp | TBD | Integer or | COSE Key | Expiration time | 359 | | | floating-point | Common | in seconds | 360 | | | number | Parameters | | 361 +------+-------+----------------+------------+-----------------+ 363 Figure 3: COSE Key Common Header Parameter 'exp' 365 Additionally, the Key Distribution Response MAY contain the following 366 parameters, which, if included, MUST have the corresponding values: 368 o pub_keys, may only be present if get_pub_keys was present in the 369 Key Distribution Request; this parameter is a COSE_KeySet (see 370 [RFC8152]), which contains the public keys of all the members of 371 the group. 373 o group_policies, with value a list of parameters indicating how the 374 group handles specific management aspects. This includes, for 375 instance, approaches to achieve synchronization of sequence 376 numbers among group members. The exact format of this parameter 377 is specific to the profile. 379 o mgt_key_material, with value the administrative keying material to 380 participate in the revocation and renewal of group keying 381 (rekeying) performed by the KDC. The exact format and content 382 depend on the specific rekeying algorithm used in the group, which 383 may be specified in the profile. 385 Specific profiles need to specify how exactly the keying material is 386 used to protect the group communication. 388 TBD: define for verification failure 390 5. Remove a Node from the Group 392 This section describes at a high level how a node can be removed from 393 the group. 395 5.1. Not authorized anymore 397 If the node is not authorized anymore, the AS can directly 398 communicate that to the KDC. Alternatively, the Access Token might 399 have expired. If Token introspection is provided by the AS, the KDC 400 can use it as per Section 5.7 of [I-D.ietf-ace-oauth-authz], in order 401 to verify that the Access Token is still valid. 403 Either case, once aware that a node is not authorized anymore, the 404 KDC has to generate and distribute the new keying material to all 405 authorized members of the group, as well as to remove the 406 unauthorized node from the list of members (if the KDC keeps track of 407 that). The KDC relies on the specific rekeying algorithm used in the 408 group, such as e.g. [RFC2093], [RFC2094] or [RFC2627], and the 409 related management key material. 411 5.2. Request to Leave the Group 413 A node can actively request to leave the group. In this case, the 414 Client can send a request to the KDC to exit the group. The KDC can 415 then generate and distribute the new keying material to all 416 authorized members of the group, as well as remove the leaving node 417 from the list of members (if the KDC keeps track of that). 419 Note that, as long as the node is authorized to join the group, i.e. 420 it has a valid Access Token, it can re-request to join the group 421 directly to the KDC without needing to retrieve a new Access Token. 422 This means that the KDC needs to keep track of nodes with valid 423 Access Tokens, before deleting all information about the leaving 424 node. 426 6. Retrieval of Updated Keying Material 428 A node stops using the group keying material upon its expiration, 429 according to the 'exp' parameter specified in the retained COSE Key. 430 Then, if it wants to continue participating in the group 431 communication, the node has to request new updated keying material to 432 the KDC. 434 The Client may perform the same request to the KDC also upon 435 receiving messages from other group members without being able to 436 correctly decrypt them. This may be due to a previous update of the 437 group keying material (rekeying) triggered by the KDC, that the 438 Client was not able to participate to. 440 Note that policies can be set up so that the Client sends a request 441 to the KDC only after a given number of unsuccessfully decrypted 442 incoming messages. 444 6.1. Key Re-Distribution Request 446 To request a re-distribution of keying material, the Client sends a 447 shortened Key Distribution request to the KDC (Section 4.1), 448 formatted as follows. The payload MAY contain only the following 449 field: 451 o scope, which contains only the identifier of the specific group or 452 topic, encoded as in Section 3.1. That is, the role field is not 453 present. 455 In some cases, it is not necessary to include the scope parameter, 456 for instance if the KDC maintains a list of active group members for 457 each managed group, and the Client is member of only one group. The 458 Client MUST include the scope parameter if it is a member of multiple 459 groups under the same KDC. 461 6.2. Key Re-Distribution Response 463 The KDC replies to the Client with a Key Distribution Response 464 containing the 'key' parameter, and optionally 'group_policies' and 465 'mgt_key_material', as specified in Section 4.2. Note that this 466 response might simply re-provide the same keying material currently 467 owned by the Client, if it has not been renewed. 469 7. Retrieval of Public Keys for Group Members 471 In case the KDC maintains the public keys of group members, a node in 472 the group can contact the KDC to request public keys of either all 473 group members or a specified subset, using the messages defined 474 below. 476 Note that these messages can be combined with the Key Re-Distribution 477 messages in Section 6, to request at the same time the keying 478 material and the public keys. In this case, either a new endpoint at 479 the KDC may be used, or additional information needs to be sent in 480 the request payload, to distinguish these combined messages from the 481 Public Key messages described below, since they would be identical 482 otherwise. 484 7.1. Public Key Request 486 To request public keys, the Client sends a shortened Key Distribution 487 request to the KDC (Section 4.1), formatted as follows. The payload 488 of this request MUST contain the following field: 490 o get_pub_keys, which has for value a CBOR array including either: 492 * no elements, i.e. an empty array, in order to request the 493 public key of all current group members; or 495 * N elements, each of which is the identifier of a group member, 496 in order to request the public key of the specified nodes. 498 Additionally, this request MAY contain the following parameter, 499 which, if included, MUST have the corresponding value: 501 o scope, which contains only the identifier of the specific group or 502 topic, encoded as in Section 3.1. That is, the role field is not 503 present. 505 In some cases, it is not necessary to include the scope parameter, 506 for instance if the KDC maintains a list of active group members 507 for each managed group, and if the specified identifiers allow to 508 retrieve public keys with no ambiguity. The Client MUST include 509 the scope parameter if it is a member of multiple groups under the 510 same KDC. 512 If the KDC can not unambiguously identify the nodes specified in the 513 'get_pub_keys' parameter, it MUST reply with an error message. In 514 this case, the Client can issue a new Public Key Request specifying 515 the group in the 'scope' parameter. 517 TODO: define error 519 7.2. Public Key Response 521 The KDC replies to the Client with a Key Distribution Response 522 containing only the 'pub_keys' parameter, as specified in 523 Section 4.2. The payload of this response contains the following 524 field: 526 o pub_keys, which contains either: 528 * the public keys of all the members of the group, if the 529 'get_pub_keys' parameter of the Public Key request was an empty 530 array; or 532 * the public keys of the group members with the identifiers 533 specified in the 'get_pub_keys' parameter of the Public Key 534 request. 536 The KDC ignores possible identifiers included in the 'get_pub_keys' 537 parameter of the Public Key request if they are not associated to any 538 current group member. 540 8. Security Considerations 542 The KDC must renew the group keying material upon its expiration. 544 The KDC should renew the keying material upon group membership 545 change, and should provide it to the current group members through 546 the rekeying algorithm used in the group. 548 9. IANA Considerations 550 The following registration is required for the COSE Key Common 551 Parameter Registry specified in Section 16.5 of [RFC8152]: 553 o Name: exp 555 o Label: TBD 557 o CBOR Type: Integer or floating-point number 559 o Value Registry: COSE Key Common Parameters 561 o Description: Identifies the expiration time in seconds of the COSE 562 Key 564 o Reference: [[this specification]] 566 10. References 568 10.1. Normative References 570 [I-D.ietf-ace-oauth-authz] 571 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 572 H. Tschofenig, "Authentication and Authorization for 573 Constrained Environments (ACE) using the OAuth 2.0 574 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12 575 (work in progress), May 2018. 577 [I-D.ietf-ace-oscore-profile] 578 Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander, 579 "OSCORE profile of the Authentication and Authorization 580 for Constrained Environments Framework", draft-ietf-ace- 581 oscore-profile-01 (work in progress), March 2018. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, 586 . 588 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 589 RFC 8152, DOI 10.17487/RFC8152, July 2017, 590 . 592 10.2. Informative References 594 [I-D.ietf-core-coap-pubsub] 595 Koster, M., Keranen, A., and J. Jimenez, "Publish- 596 Subscribe Broker for the Constrained Application Protocol 597 (CoAP)", draft-ietf-core-coap-pubsub-04 (work in 598 progress), March 2018. 600 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 601 Protocol (GKMP) Specification", RFC 2093, 602 DOI 10.17487/RFC2093, July 1997, 603 . 605 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 606 Protocol (GKMP) Architecture", RFC 2094, 607 DOI 10.17487/RFC2094, July 1997, 608 . 610 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 611 Multicast: Issues and Architectures", RFC 2627, 612 DOI 10.17487/RFC2627, June 1999, 613 . 615 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 616 the Constrained Application Protocol (CoAP)", RFC 7390, 617 DOI 10.17487/RFC7390, October 2014, 618 . 620 Acknowledgments 622 The following individuals were helpful in shaping this document: Ben 623 Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz and Goeran Selander. 625 The work on this document has been partly supported by the EIT- 626 Digital High Impact Initiative ACTIVE. 628 Authors' Addresses 630 Francesca Palombini 631 Ericsson AB 632 Torshamnsgatan 23 633 Kista SE-16440 Stockholm 634 Sweden 636 Email: francesca.palombini@ericsson.com 638 Marco Tiloca 639 RISE SICS 640 Isafjordsgatan 22 641 Kista SE-16440 Stockholm 642 Sweden 644 Email: marco.tiloca@ri.se