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.


Table of Contents

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.

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:

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.

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:

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

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:

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

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:

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:

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:

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:

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.

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:

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 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:

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

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

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:

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]:

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)", Internet-Draft draft-ietf-ace-oauth-authz-12, 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", Internet-Draft draft-ietf-ace-oscore-profile-01, 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.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017.

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)", Internet-Draft draft-ietf-core-coap-pubsub-04, March 2018.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, DOI 10.17487/RFC2093, July 1997.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, DOI 10.17487/RFC2094, July 1997.
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, DOI 10.17487/RFC2627, June 1999.
[RFC7390] Rahman, A. and E. Dijk, "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014.

Acknowledgments

The following individuals were helpful in shaping this document: Ben Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz and Göran 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