idnits 2.17.1 draft-palombini-ace-key-groupcomm-00.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 (March 01, 2018) is 2247 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-10 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-00 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-03 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: September 2, 2018 RISE SICS AB 6 March 01, 2018 8 Key Provisioning for Group Communication using ACE 9 draft-palombini-ace-key-groupcomm-00 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 September 2, 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 . . . . . . . . . . . . . . . . 6 60 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 7 61 5. Remove a Node from the Group . . . . . . . . . . . . . . . . 8 62 5.1. Not authorized anymore . . . . . . . . . . . . . . . . . 8 63 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 75 define the format of messages used to distribute the keying material 76 in a group communication scenario. Profiles that use group 77 communication can build on this document to specify exactly which of 78 the message parameters defined in this documents are used, and what 79 are their values. Known applications that can benefit from this 80 document would be, for example, profiles addressing group 81 communication based on multicast [RFC7390] or publishing/subscribing 82 [I-D.ietf-core-coap-pubsub] in ACE. 84 1.1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. These 89 words may also appear in this document in lowercase, absent their 90 normative meanings. 92 Readers are expected to be familiar with the terms and concepts 93 described in [I-D.ietf-ace-oauth-authz] and [RFC8152]. 95 2. Overview 97 +-----------+ +-----------+ 98 | AS | | KDC | 99 | | .-------->| | 100 +-----------+ / +-----------+ 101 ^ / 102 | / 103 v / +-----------+ 104 +-----------+ / +------------+ |+-----------+ 105 | Client |<-' | Dispatcher | ||+-----------+ 106 | |<-------->| (RS) |<------->|| group | 107 +-----------+ +------------+ +| members | 108 +-----------+ 110 Figure 1: Key Distribution Participants 112 Participants: 114 o Client: Node that wants to join the group communication. It can 115 either want write rights or read rights. 117 o AS: Same as AS in the ACE Framework; it contains policies, and 118 knows if a node is allowed to join the group with write or read 119 rights. 121 o Key Distribution Center: Maintains the keying material to protect 122 group communications, and provides it to clients authorized to 123 join the group. During the first part of the exchange, it 124 corresponds to the RS in the ACE Framework. 126 o Dispatcher: this is the entity the Client wants to securely 127 communicate with and is responsible for distribution of group 128 messages. It can be an existing node, such as the Broker in a 129 pub-sub setting (in which case the Dispatcher is also a RS), or it 130 can be implicit, as in the multicast communication setting, where 131 the message distribution is done by transmitting to a multicast IP 132 address, and entrusting message delivery to the transport channel. 134 This document specifies the message flows and formats for adding a 135 node to a group, as well as for the distribution of keying material 136 to joining nodes. Also, it briefly mentions the node's removal from 137 a group and the consequent rekeying process. 139 The high level overview of the message flow for a node joining a 140 group communication setting is shown in Figure 2. 142 C AS KDC Dispatcher 143 | | | | \ 144 | authorization | | | | 145 |-----request---->| | | | defined in 146 | | | | | the ACE 147 | authorization | | | | framework 148 |<----response----| | | | 149 | | | | | 150 |--------token post---------------->| | / 151 | | | | 152 |----key distribution request------>| | 153 | | | | 154 |<---key distribution response------| | 155 | | | | 156 |<=============protected communication===============>| 157 | | | | 159 Figure 2: Key Distribution Message Flow 161 3. Addition to the Group 163 This section describes in detail the message formats exchanged by the 164 participants when a node requests access to the group. The first 165 part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz], 166 where the KDC takes the role of RS. 168 3.1. Authorization Request 170 The Authorization Request sent from the Client to the AS (as defined 171 in [I-D.ietf-ace-oauth-authz], Section 5.6.1, MUST contain the 172 following parameters: 174 o grant_type, with value "client_credentials". 176 Additionally, the Authorization Request MAY contain the following 177 parameters, which, if included, MUST have the corresponding values: 179 o scope, with value the identifier of the specific group or topic 180 the Client wishes to access, as well as the role the Client wishes 181 to take, if necessary. This value is encoded as a CBOR array, 182 which contains: 184 * as first element, the identifier of the specific group or topic 186 * optionally, as second element, the role (or CBOR array of 187 roles) the Client wishes to take in the group 189 How exactly the group or topic identifier and the roles are encoded 190 is application specific. 192 o aud, with value an identifier of the KDC. 194 o cnf, containing the public key (or certificate) of the joining 195 node, if the Client wishes to communicate that to the AS. 197 o get_pub_keys, with value the byte 0x01 if the Client wishes to 198 receive the public keys of all the other nodes in the group from 199 the KDC. This value is included in the Access Token, intended for 200 the KDC. 202 o Other additional parameters as defined in 203 [I-D.ietf-ace-oauth-authz], if necessary. 205 The parameter 'get_pub_keys' is defined in this specification. 207 TODO: insert table to specify new parameters 209 3.2. Authorization Response 211 The Authorization Response sent from the AS to the Client (as defined 212 in [I-D.ietf-ace-oauth-authz], Section 5.6.2, MUST contain the 213 following parameters: 215 o access_token, containing all the parameters defined below 216 (including the same 'scope' as in this message, if present, or the 217 'scope' of the Authorization Request otherwise), plus the 218 parameter 'get_pub_keys' from the Authorization Request if it was 219 present, and additionally other optional parameters the profile 220 requires. 222 o cnf if symmetric keys are used, not present if asymmetric keys are 223 used, contains the symmetric pop key that the Client is supposed 224 to use with the KDC. 226 o rs_cnf if asymmetric keys are used, contains information about the 227 public key of the KDC. Not present if symmetric keys are used. 229 o exp, contains the lifetime in seconds of the access token. This 230 parameter MAY be omitted if the application defines how the 231 expiration time is communicated to the Client via other means, or 232 if it establishes a default value. 234 Additionally, the Authorization Response MAY contain the following 235 parameters, which, if included, MUST have the corresponding values: 237 o scope, which mirrors the 'scope' parameter in the Authorization 238 Request. Its value is encoded as a CBOR array, containing: 240 * as first element, the identifier of the specific group or topic 241 the Client is authorized to access. 243 * optionally, as second element, the role (or CBOR array of 244 roles) the Client is authorized to take in the group. 246 How exactly the group or topic identifier and the roles are encoded 247 is application specific. 249 o Other additional parameters as defined in 250 [I-D.ietf-ace-oauth-authz], if necessary. 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. 269 4.1. Key Distribution Request 271 The Client sends a Key Distribution request to the KDC. This 272 corresponds to a CoAP POST request to the endpoint in the KDC 273 associated to the group (which is associated in the KDC to the 274 'scope' value of the Authorization Request/Response). The payload of 275 this request is a CBOR Map which MAY contain the following fields, 276 which, if included, MUST have the corresponding values: 278 o scope, with value the specific resource or topic identifier and 279 role(s) that the Client is authorized to access, encoded as in 280 Section 3.1. 282 o get_pub_keys, may be present if the KDC stores the public keys of 283 the nodes in the group and distributes them to the Client; useless 284 to have here if the set of public keys of the members of the group 285 is known in another way, e.g. was supplied by the AS. 287 o client_cred, with value the public key or certificate of the 288 Client. If the KDC is managing (collecting from/distributing to 289 the joining node) the public keys of the group members, this field 290 contains the public key of the Client. 292 o pub_keys_repos, can be present if a certificate is present in the 293 client_cred field, with value a list of public key repositories 294 storing the certificate of the joining node. 296 4.2. Key Distribution Response 298 The KDC verifies the Access Token and, if verification succeeds, 299 sends a Key Distribution success Response to the Client. This 300 corresponds to a 2.01 Created message. The payload of this response 301 is a CBOR Map which MUST contain the following fields: 303 o key, used to send the keying material to the joining node, as a 304 COSE_Key ([RFC8152]) containing the following parameters: 306 * kty, as defined in [RFC8152]. 308 * k, as defined in [RFC8152]. 310 * alg (optionally), as defined in [RFC8152]. 312 * kid (optionally), as defined in [RFC8152]. 314 * base iv (optionally), as defined in [RFC8152]. 316 * clientID (optionally), as defined in 317 [I-D.ietf-ace-oscore-profile]. 319 * serverID (optionally), as defined in 320 [I-D.ietf-ace-oscore-profile]. 322 * kdf (optionally), as defined in [I-D.ietf-ace-oscore-profile]. 324 * slt (optionally), as defined in [I-D.ietf-ace-oscore-profile]. 326 * cs_alg (optionally), containing the algorithm value to counter 327 sign the message, taken from Table 5 and 6 of [RFC8152]. 329 Additionally, the Key Distribution Response MAY contain the following 330 parameters, which, if included, MUST have the corresponding values: 332 o pub_keys, may only be present if get_pub_keys was present in the 333 Key Distribution Request; this parameter is a COSE_KeySet (see 334 [RFC8152]), which contains the public keys of all the members of 335 the group 337 o group_policies, with value a list of parameters indicating how the 338 group handles specific managament aspects. This includes, for 339 instance, approaches to achieve synchronization of sequence 340 numbers among group members. The exact format of this parameter 341 is specific to the profile. 343 o mgt_key_material, with value the administrative keying material to 344 participate in the revocation and renewal of group keying 345 (rekeying) performed by the KDC. The exact format and content 346 depend on the specific rekeying algorithm used in the group, which 347 is specified in the profile. 349 Specific profiles need to specify how exactly the keying material is 350 used to protect the group communication. 352 TBD: define for verification failure 354 5. Remove a Node from the Group 356 This section describes at a high level how a node can be removed from 357 the group. 359 5.1. Not authorized anymore 361 If the node is not authorized, the AS can directly communicate that 362 to the KDC. Alternatively, the authorization token might expire. In 363 both cases, the KDC needs to renew and distribute the new keying 364 material to all authorized members of the group, as well as to remove 365 the leaving node from the list of members (if the KDC keeps track of 366 that). The KDC relies on the specific rekeying algorithm used in the 367 group, such as e.g. [RFC2093], [RFC2094] or [RFC2627], and the 368 related management key material. 370 5.2. Request to Leave the Group 372 A node can actively request to leave the group. In this case, the 373 Client can send a request to the KDC to exit the group. The KDC can 374 then renew and distribute the new keying material to all authorized 375 members of the group, as well as remove the leaving node from the 376 list of members (if the KDC keeps track of that). Note that as long 377 as the node is authorized to join the group (valid authorization 378 token), it can re-request to join the group directly to the KDC 379 without needing to retrieve a new authorization token. This means 380 that the KDC needs to keep track of this information, before deleting 381 all information about the leaving node. 383 6. Security Considerations 385 TODO 387 7. IANA Considerations 389 TODO 391 8. References 393 8.1. Normative References 395 [I-D.ietf-ace-oauth-authz] 396 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 397 H. Tschofenig, "Authentication and Authorization for 398 Constrained Environments (ACE)", draft-ietf-ace-oauth- 399 authz-10 (work in progress), February 2018. 401 [I-D.ietf-ace-oscore-profile] 402 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 403 profile of the Authentication and Authorization for 404 Constrained Environments Framework", draft-ietf-ace- 405 oscore-profile-00 (work in progress), December 2017. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 413 RFC 8152, DOI 10.17487/RFC8152, July 2017, 414 . 416 8.2. Informative References 418 [I-D.ietf-core-coap-pubsub] 419 Koster, M., Keranen, A., and J. Jimenez, "Publish- 420 Subscribe Broker for the Constrained Application Protocol 421 (CoAP)", draft-ietf-core-coap-pubsub-03 (work in 422 progress), February 2018. 424 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 425 Protocol (GKMP) Specification", RFC 2093, 426 DOI 10.17487/RFC2093, July 1997, 427 . 429 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 430 Protocol (GKMP) Architecture", RFC 2094, 431 DOI 10.17487/RFC2094, July 1997, 432 . 434 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 435 Multicast: Issues and Architectures", RFC 2627, 436 DOI 10.17487/RFC2627, June 1999, 437 . 439 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 440 the Constrained Application Protocol (CoAP)", RFC 7390, 441 DOI 10.17487/RFC7390, October 2014, 442 . 444 Acknowledgments 446 The following individuals were helpful in shaping this document: Ben 447 Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander. 449 The work on this document has been partly supported by the EIT- 450 Digital High Impact Initiative ACTIVE. 452 Authors' Addresses 454 Francesca Palombini 455 Ericsson AB 456 Torshamnsgatan 23 457 Kista SE-16440 Stockholm 458 Sweden 460 Email: francesca.palombini@ericsson.com 462 Marco Tiloca 463 RISE SICS AB 464 Isafjordsgatan 22 465 Kista SE-16440 Stockholm 466 Sweden 468 Email: marco.tiloca@ri.se