Key Provisioning for Group Communication using ACE
draft-palombini-ace-key-groupcomm-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Francesca Palombini , Marco Tiloca | ||
| Last updated | 2018-03-01 | ||
| Replaced by | draft-ietf-ace-key-groupcomm | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-palombini-ace-key-groupcomm-00
ACE Working Group F. Palombini
Internet-Draft Ericsson AB
Intended status: Standards Track M. Tiloca
Expires: September 2, 2018 RISE SICS AB
March 01, 2018
Key Provisioning for Group Communication using ACE
draft-palombini-ace-key-groupcomm-00
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 September 2, 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 September 2, 2018 [Page 1]
Internet-Draft Key Prov Group Comm March 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 . . . . . . . . . . . . . . . . 6
4.2. Key Distribution Response . . . . . . . . . . . . . . . . 7
5. Remove a Node from the Group . . . . . . . . . . . . . . . . 8
5.1. Not authorized anymore . . . . . . . . . . . . . . . . . 8
5.2. Request to Leave the Group . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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].
Palombini & Tiloca Expires September 2, 2018 [Page 2]
Internet-Draft Key Prov Group Comm March 2018
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.
The high level overview of the message flow for a node joining a
group communication setting is shown in Figure 2.
Palombini & Tiloca Expires September 2, 2018 [Page 3]
Internet-Draft Key Prov Group Comm March 2018
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 encoded as a CBOR array,
which contains:
* as first element, the identifier of the specific group or topic
* optionally, as second element, the role (or CBOR array of
roles) the Client wishes to take in the group
Palombini & Tiloca Expires September 2, 2018 [Page 4]
Internet-Draft Key Prov Group Comm March 2018
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 joining
node, if the Client wishes to communicate that to the AS.
o get_pub_keys, with value the byte 0x01 if the Client wishes to
receive the public keys of all the other nodes in the group from
the KDC. This value is included in the Access Token, intended for
the KDC.
o Other additional parameters as defined in
[I-D.ietf-ace-oauth-authz], if necessary.
The parameter 'get_pub_keys' is defined in this specification.
TODO: insert table to specify new parameters
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), plus the
parameter 'get_pub_keys' from the Authorization Request if it was
present, 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:
Palombini & Tiloca Expires September 2, 2018 [Page 5]
Internet-Draft Key Prov Group Comm March 2018
o scope, which mirrors the 'scope' parameter in the Authorization
Request. Its value is encoded as a CBOR array, containing:
* as first element, the identifier of the specific group or topic
the Client is authorized to access.
* 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.
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.
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, may be present if the KDC stores the public keys of
the nodes in the group and distributes them to the Client; useless
Palombini & Tiloca Expires September 2, 2018 [Page 6]
Internet-Draft Key Prov Group Comm March 2018
to have here if the set of public keys of the members of the group
is known in another way, e.g. 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 joining node) 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 joining node.
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 joining node, as a
COSE_Key ([RFC8152]) containing the following parameters:
* kty, as defined in [RFC8152].
* k, as defined in [RFC8152].
* 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 counter
sign the message, taken from Table 5 and 6 of [RFC8152].
Additionally, the Key Distribution Response MAY contain the following
parameters, which, if included, MUST have the corresponding values:
Palombini & Tiloca Expires September 2, 2018 [Page 7]
Internet-Draft Key Prov Group Comm March 2018
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 managament 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.
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
is 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, the AS can directly communicate that
to the KDC. Alternatively, the authorization token might expire. In
both cases, the KDC needs to renew and distribute the new keying
material to all authorized members of the group, as well as to remove
the leaving 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 renew 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 (valid authorization
token), it can re-request to join the group directly to the KDC
without needing to retrieve a new authorization token. This means
Palombini & Tiloca Expires September 2, 2018 [Page 8]
Internet-Draft Key Prov Group Comm March 2018
that the KDC needs to keep track of this information, before deleting
all information about the leaving node.
6. Security Considerations
TODO
7. IANA Considerations
TODO
8. References
8.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)", draft-ietf-ace-oauth-
authz-10 (work in progress), February 2018.
[I-D.ietf-ace-oscore-profile]
Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE
profile of the Authentication and Authorization for
Constrained Environments Framework", draft-ietf-ace-
oscore-profile-00 (work in progress), December 2017.
[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>.
8.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-03 (work in
progress), February 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>.
Palombini & Tiloca Expires September 2, 2018 [Page 9]
Internet-Draft Key Prov Group Comm March 2018
[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>.
[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, 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 AB
Isafjordsgatan 22
Kista SE-16440 Stockholm
Sweden
Email: marco.tiloca@ri.se
Palombini & Tiloca Expires September 2, 2018 [Page 10]