Draft: draft-palombini-ace-key-groupcomm

Commentary: Update for v-02
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.
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.
This document defines message formats and procedures for requesting
and distributing group keying material using the ACE framework, to
protect communications between group members.
This document expands the ACE framework I-D.ietf-ace-oauth-authz to
define the format of messages used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on
multicast RFC7390 or on publishing-subscribing I-D.ietf-core-coap-
pubsub.
Profiles that use group communication can build on this document to
specify the selection of the message parameters defined in this
document to use and 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.
If the application requires backward and forward security, updated
keying material is generated and distributed to the group members
(rekeying), when membership changes.  A key management scheme
performs the actual distribution of the updated keying material to
the group.  In particular, the key management scheme rekeys the
current group members when a new node joins the group, and the
remaining group members when a node leaves the group.  This document
provides a message format for group rekeying that allows to fulfill
these requirements.  Rekeying mechanisms can be based on RFC2093,
RFC2094 and RFC2627.
Readers are expected to be familiar with the terms and concepts
described in I-D.ietf-ace-oauth-authz and RFC8152.
Client: Node that wants to join the group communication.  It can
either want write rights or read rights.
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.
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.
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 fig-flow.
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.
grant_type, with value "client_credentials".
aud, with value an identifier of the KDC.
cnf, containing the public key (or certificate) of the Client, if
it wishes to communicate that to the AS.
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), and additionally
other optional parameters the profile requires.
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.
rs_cnf if asymmetric keys are used, contains information about the
public key of the KDC.  Not present if symmetric keys are used.
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.
Readers are expected to be familiar with the terms and concepts
described in I-D.ietf-ace-oauth-authz and RFC8152, such as
Authorization Server (AS) and Resource Server (RS).
The following participants (see fig-roles) take part in the
authorization and key distribution.
Client (C): node that wants to join the group communication.  It
can request write and/or read rights.
Authorization Server (AS): same as AS in the ACE Framework; it
enforces access policies, and knows if a node is allowed to join
the group with write and/or read rights.
Key Distribution Center (KDC): 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 (sec-auth), it takes the role of the RS in the ACE
Framework.  During the second part (key-distr), which is not based
on the ACE Framework, it distributes the keying material.  In
addition, it provides the latest keying material to group members
when requested.  If required by the application, the KDC renews
and re-distributes the keying material in the group when
membership changes.
Dispatcher: entity through which the Clients communicate with the
group and which distributes messages to the group members.
Examples of dispatchers are: the Broker node in a pub-sub setting;
a relayer node for group communication that delivers group
messages as multiple unicast messages to all group members; an
implicit entity as in a multicast communication setting, where
messages are transmitted to a multicast IP address and delivered
on the transport channel.
Authorizing a new node to join the group (sec-auth), and providing
it with the group keying material to communicate with the other
group members (key-distr).
Removing of a current member from the group (sec-node-removal).
Retrieving keying material as a current group member (sec-
expiration and sec-key-retrieval).
Renewing and re-distributing the group keying material (rekeying)
upon a membership change in the group (ssec-key-distribution-
response and sec-node-removal).
fig-flow provides a high level overview of the message flow for a
node joining a group communication setting.
The exchange of Authorization Request and Authorization Response
between Client and AS MUST be secured, as specified by the ACE
profile used between Client and KDC.
The exchange of Key Distribution Request and Key Distribution
Response between Client and KDC MUST be secured, as a result of the
ACE profile used between Client and KDC.
All further communications between the Client and the KDC MUST be
secured, for instance with the same security mechanism used for the
Key Distribution exchange.
All further communications between a Client and the other group
members MUST be secured using the keying material provided in key-
distr.
This section describes in detail the format of messages exchanged by
the participants when a node requests access to a group.  The first
part of the exchange is based on ACE I-D.ietf-ace-oauth-authz.
As defined in I-D.ietf-ace-oauth-authz, the Client requests from the
AS an authorization to join the group through the KDC (see ssec-
authorization-request).  If the request is approved and authorization
is granted, the AS provides the Client with a proof-of-possession
access token and parameters to securely communicate with the KDC (see
ssec-authorization-response).  Communications between the Client and
the AS MUST be secured, and depends on the profile of ACE used.
fig-group-member-registration gives an overview of the exchange
described above.
'grant_type', with value "client_credentials".
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.
'req_aud', as defined in Section 3.1 of I-D.ietf-ace-oauth-params,
with value an identifier of the KDC.
'req_cnf', as defined in Section 3.1 of I-D.ietf-ace-oauth-params,
optionally containing the public key or the certificate of the
Client, if it wishes to communicate that to the AS.
'access_token', containing the proof-of-possession access token.
'cnf' if symmetric keys are used, not present if asymmetric keys
are used.  This parameter is defined in Section 3.2 of I-D.ietf-
ace-oauth-params and contains the symmetric proof-of-possession
key that the Client is supposed to use with the KDC.
'rs_cnf' if asymmetric keys are used, not present if symmetric
keys are used.  This parameter is as defined in Section 3.2 of I-
D.ietf-ace-oauth-params and contains information about the public
key of the KDC.
'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.
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.
The access token MUST contain all the parameters defined above
(including the same 'scope' as in this message, if present, or the
'scope' of the Authorization Request otherwise), and additionally
other optional parameters the profile requires.
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 ACE profile defines it, the Client MAY use a
different endpoint than /authz-info 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.
The Client wishes to (re-)get the current keying material, for
cases such as expiration, loss or suspected mismatch, due to e.g.
reboot or missed rekeying.  This is further discussed in sec-
expiration.
scope, with value the specific resource or topic identifier and
role(s) that the Client is authorized to access, encoded as in
authorization-request.
get_pub_keys, if the Client wishes to receive the public keys of
the other nodes in the group from the KDC.  The value is an empty
CBOR Array.  This parameter may be present if the KDC stores the
public keys of the nodes in the group and distributes them to the
Client; it is useless to have here if the set of public keys of
the members of the group is known in another way, e.g. it was
supplied by the AS.
client_cred, with value the public key or certificate of the
Client.  If the KDC is managing (collecting from/distributing to
the Client) the public keys of the group members, this field
contains the public key of the Client.
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 Client.
kty, as defined in RFC8152.
k, as defined in RFC8152.
exp (optionally), as defined below.  This parameter is
RECOMMENDED to be included in the COSE_Key.  If omitted, the
authorization server SHOULD provide the expiration time via
other means or document the default value.
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
countersign the message, taken from Table 5 and 6 of RFC8152.
If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel using ACE.  The
exchange of Key Distribution Request-Response MUST occur over that
secure channel.  The Client and the KDC MAY use that same secure
channel to protect further pairwise communications, that MUST be
secured.
During this exchange, the Client sends a request to the AS,
specifying the group it wishes to join (see ssec-key-distribution-
request).  Then, the KDC verifies the access token and that the
Client is authorized to join that group; if so, it provides the
Client with the keying material to securely communicate with the
member of the group (see ssec-key-distribution-response).
fig-key-distr-join gives an overview of the exchange described above.
The Client wishes to (re-)get the current keying material, for
cases such as expiration, loss or suspected mismatch, due to e.g.
reboot or missed group rekeying.  This is further discussed in
sec-expiration.
Additionally, the format of the payload of the Key Distribution
Response (ssec-key-distribution-response) can be reused for messages
sent by the KDC to distribute updated group keying material, in case
of a new node joining the group or of a current member leaving the
group.  The key management scheme used to send such messages could
rely on, e.g., multicast in case of a new node joining or unicast in
case of a node leaving the group.
Note that proof-of-possession to bind the access token to the Client
is performed by using the proof-of-possession key bound to the access
token for establishing secure communication between the Client and
the KDC.
'scope', with value the specific resource that the Client is
authorized to access (i.e. group or topic identifier) and role(s),
encoded as in ssec-authorization-request.
'get_pub_keys', if the Client wishes to receive the public keys of
the other nodes in the group from the KDC.  The value is an empty
CBOR Array.  This parameter may be present if the KDC stores the
public keys of the nodes in the group and distributes them to the
Client; it is useless to have here if the set of public keys of
the members of the group is known in another way, e.g. it was
provided by the AS.
'client_cred', with value the public key or certificate of the
Client.  If the KDC is managing (collecting from/distributing to
the Client) the public keys of the group members, this field
contains the public key of the Client.
'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 Client.
'kty', as defined in RFC8152.
'k', as defined in RFC8152.
'exp' (optionally), as defined below.  This parameter is
RECOMMENDED to be included in the COSE_Key.  If omitted, the
authorization server SHOULD provide the expiration time via
other means or document the default value.
'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
countersign the message, taken from Table 5 and 6 of RFC8152.
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.
group_policies, with value a list of parameters indicating how the
group handles specific management 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.
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
may be specified in the profile.
'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.
'group_policies', with value a list of parameters indicating how
the group handles specific management 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.
'mgt_key_material', with value the administrative keying material
to participate in the group rekeying performed by the KDC.  The
exact format and content depend on the specific rekeying scheme
used in the group, which may be specified in the profile.
If the application requires backward security, the KDC SHALL generate
new group keying material and securely distribute it to all the
current group members, using the message format defined in this
section.  Application profiles may define alternative message
formats.
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.
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.
If the application requires forward security, the KDC SHALL generate
new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format
defined in ssec-key-distribution-response.  Application profiles may
define alternative message formats.
Either case, once aware that a node is not authorized anymore, the
KDC has to remove the unauthorized node from the list of group
members, if the KDC keeps track of that.
A node can actively request to leave the group.  In this case, the
Client can send a request formatted as follows to the KDC, to abandon
the group.
The KDC should then remove the leaving node from the list of group
members, if the KDC keeps track of that.
Note that, after having left the group, a node may wish to join it
again.  Then, as long as the node is still authorized to join the
group, i.e. it has a still valid access token, it can re-request to
join the group directly to the KDC without needing to retrieve a new
access token from the AS.  This means that the KDC needs to keep
track of nodes with valid access tokens, before deleting all
information about the leaving node.
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.
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 receive or decrypt.
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.
The KDC receiving a Key Re-Distribution Request MUST check that it is
storing a valid access token from that client for that scope.
TODO: defines error response if it does not have it / is not valid.
fig-public-key-req-resp gives an overview of the exchange described
above.
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 if the specified identifiers allow to
retrieve public keys with no ambiguity.  The Client MUST include
the scope parameter if it is a member of multiple groups under the
same KDC.
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.
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.
The KDC should renew the keying material upon group membership
change, and should provide it to the current group members through
the rekeying scheme used in the group.