draft-ietf-ace-key-groupcomm-00.txt   draft-ietf-ace-key-groupcomm-01.txt 
ACE Working Group F. Palombini ACE Working Group F. Palombini
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track M. Tiloca Intended status: Standards Track M. Tiloca
Expires: June 23, 2019 RISE AB Expires: September 9, 2019 RISE AB
December 20, 2018 March 08, 2019
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-00 draft-ietf-ace-key-groupcomm-01
Abstract Abstract
This document defines message formats and procedures for requesting This document defines message formats and procedures for requesting
and distributing group keying material using the ACE framework, to and distributing group keying material using the ACE framework, to
protect communications between group members. protect communications between group members.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6
3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8
4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 8 4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Key Distribution Request . . . . . . . . . . . . . . . . 9 4.1. Key Distribution Request . . . . . . . . . . . . . . . . 9
4.2. Key Distribution Response . . . . . . . . . . . . . . . . 10 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 10
5. Removal of a Node from the Group . . . . . . . . . . . . . . 12 5. Removal of a Node from the Group . . . . . . . . . . . . . . 12
5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 12 5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 12
5.2. Request to Leave the Group . . . . . . . . . . . . . . . 12 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 12
6. Retrieval of Updated Keying Material . . . . . . . . . . . . 13 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 13
6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 13 6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 14
6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 13 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 14
7. Retrieval of Public Keys for Group Members . . . . . . . . . 13 7. Retrieval of Public Keys for Group Members . . . . . . . . . 15
7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 14 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 15
7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 14 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 16 9.3. Expert Review Instructions . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 20
A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
define the format of messages used to request, distribute and renew define the format of messages used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on the keying material in a group communication scenario, e.g. based on
multicast [RFC7390] or on publishing-subscribing multicast [RFC7390] or on publishing-subscribing
[I-D.ietf-core-coap-pubsub]. [I-D.ietf-core-coap-pubsub].
Profiles that use group communication can build on this document to Profiles that use group communication can build on this document to
skipping to change at page 6, line 31 skipping to change at page 6, line 31
The Authorization Request sent from the Client to the AS is as The Authorization Request sent from the Client to the AS is as
defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST
contain the following parameters: contain the following parameters:
o 'grant_type', with value "client_credentials". o 'grant_type', with value "client_credentials".
Additionally, the Authorization Request MAY contain the following Additionally, the Authorization Request MAY contain the following
parameters, which, if included, MUST have the corresponding values: parameters, which, if included, MUST have the corresponding values:
o 'scope', with value the identifier of the specific group or topic o 'scope', containing the identifier of the specific group (or topic
the Client wishes to access, and optionally the role(s) the Client in the case of pub-sub) that the Client wishes to access, and
wishes to take. This value is a CBOR array encoded as a byte optionally the role(s) that the Client wishes to take. This value
string, which contains: is a CBOR array encoded as a byte string, which contains:
* As first element, the identifier of the specific group or * As first element, the identifier of the specific group or
topic. topic.
* Optionally, as second element, the role (or CBOR array of * Optionally, as second element, the role (or CBOR array of
roles) the Client wishes to take in the group. roles) the Client wishes to take in the group.
The encoding of the group or topic identifier and of the role The encoding of the group or topic identifier and of the role
identifiers is application specific. identifiers is application specific.
o 'req_aud', as defined in Section 3.1 of o 'audience', with an identifier of a KDC.
[I-D.ietf-ace-oauth-params], with value an identifier of the KDC.
o 'req_cnf', as defined in Section 3.1 of o 'req_cnf', as defined in Section 3.1 of
[I-D.ietf-ace-oauth-params], optionally containing the public key [I-D.ietf-ace-oauth-params], optionally containing the public key
or the certificate of the Client, if it wishes to communicate that or a reference to the public key of the Client, if it wishes to
to the AS. communicate that to the AS.
o Other additional parameters as defined in o Other additional parameters as defined in
[I-D.ietf-ace-oauth-authz], if necessary. [I-D.ietf-ace-oauth-authz], if necessary.
3.2. Authorization Response 3.2. Authorization Response
The Authorization Response sent from the AS to the Client is as The Authorization Response sent from the AS to the Client is as
defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST
contain the following parameters: contain the following parameters:
skipping to change at page 9, line 41 skipping to change at page 9, line 41
multicast in case of a new node joining or unicast in case of a node multicast in case of a new node joining or unicast in case of a node
leaving the group. leaving the group.
Note that proof-of-possession to bind the access token to the Client 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 is performed by using the proof-of-possession key bound to the access
token for establishing secure communication between the Client and token for establishing secure communication between the Client and
the KDC. the KDC.
4.1. Key Distribution Request 4.1. Key Distribution Request
The Client sends a Key Distribution request to the KDC. This The Client sends a Key Distribution Request to the KDC. This
corresponds to a CoAP POST request to the endpoint in the KDC corresponds to a CoAP POST request to the endpoint in the KDC
associated to the group to join. The endpoint in the KDC is associated to the group to join. The endpoint in the KDC is
associated to the 'scope' value of the Authorization Request/ associated to the 'scope' value of the Authorization Request/
Response. The payload of this request is a CBOR Map which MAY Response. The payload of this request is a CBOR Map which MAY
contain the following fields, which, if included, MUST have the contain the following fields, which, if included, MUST have the
corresponding values: corresponding values:
o 'scope', with value the specific resource that the Client is o 'scope', with value the specific resource that the Client is
authorized to access (i.e. group or topic identifier) and role(s), authorized to access (i.e. group or topic identifier) and role(s),
encoded as in Section 3.1. encoded as in Section 3.1.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
Client. If the KDC is managing (collecting from/distributing to Client. If the KDC is managing (collecting from/distributing to
the Client) the public keys of the group members, this field the Client) the public keys of the group members, this field
contains the public key of the Client. contains the public key of the Client.
o 'pub_keys_repos', can be present if a certificate is present in o 'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value a list of public key the 'client_cred' field, with value a list of public key
repositories storing the certificate of the Client. repositories storing the certificate of the Client.
4.2. Key Distribution Response 4.2. Key Distribution Response
The KDC verifies the access token and, if verification succeeds, The KDC verifies the 'scope' received in the Key Distribution
sends a Key Distribution success Response to the Client. This Request, if present, against the 'scope' stored in the access token
corresponds to a 2.01 Created message. The payload of this response associated to this client. If verification fails, the KDC MUST
is a CBOR Map which MUST contain the following fields: respond with a 4.01 (Unauthorized) error message. If the Key
Distribution Request is not formatted correctly (e.g. no 'scope'
o 'key', used to send the keying material to the Client, as a field present while expected, or unknown fields present), the KDC
COSE_Key ([RFC8152]) containing the following parameters: MUST respond with 4.00 (Bad Request) error message.
* '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 If verification succeeds, the KDC sends a Key Distribution success
[I-D.ietf-ace-oscore-profile]. Response to the Client. The Key Distribution success Response
corresponds to a 2.01 Created message. The payload of this response
is a CBOR map, which MUST contain:
* 'slt' (optionally), as defined in o 'kty', identifying the key type of the 'key' parameter. The set
[I-D.ietf-ace-oscore-profile]. of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry. Implementations MUST verify that the key
type matches the profile being used, if present, as registered in
the "ACE Groupcomm Key" registry.
* 'cs_alg' (optionally), containing the algorithm value to o 'key', containing the keying material for the group communication,
countersign the message, taken from Table 5 and 6 of [RFC8152]. or information required to derive it.
The parameter 'exp' identifies the expiration time in seconds after The exact format of the 'key' value MUST be defined in applications
which the COSE_Key is not valid anymore for secure communication in of this specification. Additionally, documents specifying the key
the group. A summary of 'exp' can be found in Figure 5. format MUST register it in the "ACE Groupcomm Key" registry,
including its name, type and profile to be used with, as defined in
the "ACE Groupcomm Key" registry, defined in Section 9.1.
+------+-------+----------------+------------+-----------------+ +----------+----------------+---------+-------------------------+
| Name | Label | CBOR Type | Value | Description | | Name | Key Type Value | Profile | Description |
| | | | Registry | | +----------+----------------+---------+-------------------------+
+------+-------+----------------+------------+-----------------+ | Reserved | 0 | | This value is reserved |
| exp | TBD | Integer or | COSE Key | Expiration time | +----------+----------------+---------+-------------------------+
| | | floating-point | Common | in seconds |
| | | number | Parameters | |
+------+-------+----------------+------------+-----------------+
Figure 5: COSE Key Common Header Parameter 'exp' Figure 5: Key Type Values
Optionally, the Key Distribution Response MAY contain the following Optionally, the Key Distribution Response MAY contain the following
parameters, which, if included, MUST have the corresponding values: parameters, which, if included, MUST have the corresponding values:
o 'profile', with value an identifier that MUST be used to uniquely
identify itself. The identifier MUST be registered in the "ACE
Groupcomm Profile" Registry.
o 'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or
floating-point number.
o 'pub_keys', may only be present if 'get_pub_keys' was present in 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 the Key Distribution Request. This parameter is a CBOR Byte
[RFC8152]), which contains the public keys of all the members of String, which encodes the public keys of all the group members
the group. paired with the respective member identifiers. In case public
keys in the group are represented as COSE Keys, the CBOR Byte
String encodes a COSE_KeySet (see [RFC8152]), which contains the
public keys of all the members of the group. In particular, each
COSE Key in the COSE_KeySet includes the identifier of the
corresponding group member as value of its 'kid' key parameter.
Alternative specific encodings of this parameter MUST be defined
in applications of this specification.
o 'group_policies', with value a list of parameters indicating how o 'group_policies', with value a list of parameters indicating how
the group handles specific management aspects. This includes, for the group handles specific management aspects. This includes, for
instance, approaches to achieve synchronization of sequence instance, approaches to achieve synchronization of sequence
numbers among group members. The exact format of this parameter numbers among group members. The exact format of this parameter
is specific to the profile. is specific to the profile.
o 'mgt_key_material', with value the administrative keying material o 'mgt_key_material', with value the administrative keying material
to participate in the group rekeying performed by the KDC. The to participate in the group rekeying performed by the KDC. The
exact format and content depend on the specific rekeying scheme exact format and content depend on the specific rekeying scheme
skipping to change at page 12, line 8 skipping to change at page 12, line 7
Specific profiles need to specify how exactly the keying material is Specific profiles need to specify how exactly the keying material is
used to protect the group communication. used to protect the group communication.
If the application requires backward security, the KDC SHALL generate If the application requires backward security, the KDC SHALL generate
new group keying material and securely distribute it to all the new group keying material and securely distribute it to all the
current group members, using the message format defined in this current group members, using the message format defined in this
section. Application profiles may define alternative message section. Application profiles may define alternative message
formats. formats.
TBD: define for verification failure
5. Removal of a Node from the Group 5. Removal of a Node from the Group
This section describes at a high level how a node can be removed from This section describes at a high level how a node can be removed from
the group. the group.
If the application requires forward security, the KDC SHALL generate If the application requires forward security, the KDC SHALL generate
new group keying material and securely distribute it to all the new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format current group members but the leaving node, using the message format
defined in Section 4.2. Application profiles may define alternative defined in Section 4.2. Application profiles may define alternative
message formats. message formats.
skipping to change at page 12, line 37 skipping to change at page 12, line 34
to verify that the access token is still valid. to verify that the access token is still valid.
Either case, once aware that a node is not authorized anymore, the Either case, once aware that a node is not authorized anymore, the
KDC has to remove the unauthorized node from the list of group KDC has to remove the unauthorized node from the list of group
members, if the KDC keeps track of that. members, if the KDC keeps track of that.
5.2. Request to Leave the Group 5.2. Request to Leave the Group
A node can actively request to leave the group. In this case, the 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 Client can send a request formatted as follows to the KDC, to abandon
the group. the group. The client MUST use the protected channel established
with ACE, mentioned in Section 4.
TBD: Format of the message to leave the group To request to leave a group, the client MUST send a CoAP POST request
to the endpoint in the KDC associated to the group to leave (same
endpoint used in Section 4.1 for Key Distribution requests). The
payload of this Leave Request is a CBOR Map which MUST contain:
The KDC should then remove the leaving node from the list of group o 'leave', with value an empty CBOR array.
members, if the KDC keeps track of that.
o 'scope', with value the specific resource that the Client is
authorized to access (i.e. group or topic identifier) and wants to
leave, encoded as in Section 3.1. The 'role' field is omitted.
Additionally, the Leave request MAY contain the following parameters,
which, if included, MUST have the corresponding values:
o 'client_cred', with value the identifier of the public key or
certificate of the Client. This field is used if the KDC is
managing (collecting from/distributing to the Client) the public
keys of the group members.
Note that the 'role' field is omitted since such a request should
only be used to leave a group altogether. If the leaving node wants
to be part of a group with fewer roles, it does not need to
communicate that to the KDC, and can simply stop acting according to
such roles.
If the Leave Request is not formatted correctly (e.g. no 'scope'
field present, or unknown fields present), the KDC MUST respond with
a 4.00 (Bad Request) error message. Otherwise, the KDC MUST 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 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 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 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 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 access token from the AS. This means that the KDC needs to keep
track of nodes with valid access tokens, before deleting all track of nodes with valid access tokens, before deleting all
information about the leaving node. information about the leaving node.
6. Retrieval of Updated Keying Material 6. Retrieval of Updated Keying Material
skipping to change at page 13, line 23 skipping to change at page 13, line 48
The Client may perform the same request to the KDC also upon The Client may perform the same request to the KDC also upon
receiving messages from other group members without being able to receiving messages from other group members without being able to
correctly decrypt them. This may be due to a previous update of the correctly decrypt them. This may be due to a previous update of the
group keying material (rekeying) triggered by the KDC, that the group keying material (rekeying) triggered by the KDC, that the
Client was not able to receive or decrypt. Client was not able to receive or decrypt.
Note that policies can be set up so that the Client sends a request 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 to the KDC only after a given number of unsuccessfully decrypted
incoming messages. incoming messages.
Alternatively, the re-distribution of keying material can be
initiated by the KDC, which e.g.:
o Can maintain an Observable resource to send notifications to
Clients when the keying material is updated. Such a notification
would have the same payload as the Key Re-Distribution Response
defined in Section 6.2.
o Can send the payload of the Key Re-Distribution Response in a
multicast request to the members of the group.
o Can send unicast requests to each Client over a secure channel,
with the Key Re-Distribution Response as payload.
o Can act as a publisher in a pub-sub scenario, and update the
keying material by publishing on a specific topic on a broker,
which all the members of the group are subscribed to.
Note that these methods of KDC-initiated key re-distribution have
different security properties and require different security
associations.
6.1. Key Re-Distribution Request 6.1. Key Re-Distribution Request
To request a re-distribution of keying material, the Client sends a To request a re-distribution of keying material, the Client sends a
shortened Key Distribution Request to the KDC (Section 4.1), shortened Key Distribution Request to the KDC (Section 4.1),
formatted as follows. The payload MUST contain only the following formatted as follows. The payload MUST contain only the following
field: field:
o 'scope', which contains only the identifier of the specific group o 'scope', which contains only the identifier of the specific group
or topic, encoded as in Section 3.1. That is, the role field is or topic, encoded as in Section 3.1. That is, the role field is
not present. not present.
6.2. Key Re-Distribution Response 6.2. Key Re-Distribution Response
The KDC receiving a Key Re-Distribution Request MUST check that it is The KDC receiving a Key Re-Distribution Request MUST check that it is
storing a valid access token from that client for that scope. storing a valid access token from that client for that scope.
TODO: defines error response if it does not have it / is not valid. If that is not the case, i.e. it does not store the token or the
token is not valid for that client for the scope requested, the KDC
MUST respond with a 4.01 (Unauthorized) error message. Analogously
to Section 4.2, if the Key Re-Distribution Request is not formatted
correctly (e.g. no 'scope' field present, or unknown fields present),
the KDC MUST respond with a 4.00 (Bad Request) error message.
The KDC replies to the Client with a Key Distribution Response Otherwise, the KDC replies to the Client with a Key Distribution
containing the 'key' parameter, and optionally 'group_policies' and Response, which MUST include the 'kty' and 'key' parameters specified
'mgt_key_material', as specified in Section 4.2. Note that this in Section 4.2. The Key Distribution Response MAY also include the
response might simply re-provide the same keying material currently 'profile', 'exp', 'group_policies' and 'mgt_key_material' parameters
owned by the Client, if it has not been renewed. 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 7. Retrieval of Public Keys for Group Members
In case the KDC maintains the public keys of group members, a node in 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 the group can contact the KDC to request public keys of either all
group members or a specified subset, using the messages defined group members or a specified subset, using the messages defined
below. below.
Figure 6 gives an overview of the exchange described above. Figure 6 gives an overview of the exchange described above.
skipping to change at page 15, line 25 skipping to change at page 16, line 34
current group member. current group member.
8. Security Considerations 8. Security Considerations
The KDC must renew the group keying material upon its expiration. The KDC must renew the group keying material upon its expiration.
The KDC should renew the keying material upon group membership The KDC should renew the keying material upon group membership
change, and should provide it to the current group members through change, and should provide it to the current group members through
the rekeying scheme used in the group. the rekeying scheme used in the group.
When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of [I-D.ietf-core-object-security].
9. IANA Considerations 9. IANA Considerations
The following registration is required for the COSE Key Common This document has the following actions for IANA.
Parameter Registry specified in Section 16.5 of [RFC8152]:
o Name: exp 9.1. ACE Groupcomm Key Registry
o Label: TBD This specification establishes the IANA "ACE Groupcomm Key" Registry.
The Registry has been created to use the "Expert Review Required"
registration procedure [RFC8126]. Expert review guidelines are
provided in Section 9.3.
o CBOR Type: Integer or floating-point number The columns of this Registry are:
o Value Registry: COSE Key Common Parameters o Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the
encoding.
o Description: Identifies the expiration time in seconds of the COSE o Key Type Value: This is the value used to identify the keying
Key material. These values MUST be unique. The value can be a
positive integer, a negative integer, or a string.
o Reference: [[this specification]] o Profile: This field may contain a descriptive string of a profile
to be used with this item. This should be a value that is in the
Name column of the "ACE Groupcomm Profile" Registry.
o Description: This field contains a brief description of the keying
material.
o References: This contains a pointer to the public specification
for the format of the keying material, if one exists.
This Registry has been initially populated by the values in Figure 5.
The specification column for all of these entries will be this
document.
9.2. ACE Groupcomm Profile Registry
This specification establishes the IANA "ACE Groupcomm Profile"
Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 9.3. It should be noted that, in addition to
the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as
well.
The columns of this Registry are:
o Name: The name of the profile, to be used as value of the profile
attribute.
o Description: Text giving an overview of the profile and the
context it is developed for.
o CBOR Value: CBOR abbreviation for this profile name. Different
ranges of values use different registration policies [RFC8126].
Integer values from -256 to 255 are designated as Standards
Action. Integer values from -65536 to -257 and from 256 to 65535
are designated as Specification Required. Integer values greater
than 65535 are designated as Expert Review. Integer values less
than -65536 are marked as Private Use.
o Reference: This contains a pointer to the public specification of
the profile abbreviation, if one exists.
9.3. Expert Review Instructions
The IANA Registries established in this document are defined as
expert review. This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be
assigned for testing.
o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that
size.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22
(work in progress), November 2018. (work in progress), March 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-01 (work in progress), November 2018. params-04 (work in progress), February 2019.
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-05 (work in progress), November 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-05 (work in (CoAP)", draft-ietf-core-coap-pubsub-06 (work in
progress), July 2018. progress), January 2019.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, Protocol (GKMP) Specification", RFC 2093,
DOI 10.17487/RFC2093, July 1997, DOI 10.17487/RFC2093, July 1997,
<https://www.rfc-editor.org/info/rfc2093>. <https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997, DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>. <https://www.rfc-editor.org/info/rfc2094>.
skipping to change at page 17, line 5 skipping to change at page 20, line 20
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999, DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>. <https://www.rfc-editor.org/info/rfc2627>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
Appendix A. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION.
A.1. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1).
o Defined error handling on the KDC (Sections 4.2 and 6.2).
o Updated format of the Key Distribution Response as a whole
(Section 4.2).
o Generalized format of 'pub_keys' in the Key Distribution Response
(Section 4.2).
o Defined format for the message to request leaving the group
(Section 5.2).
o Mentioned methods for group rekeying initiated by the KDC
(Section 6).
o Added security consideration on replay protection (Section 8).
o New IANA registries "ACE Groupcomm Key Registry" and "ACE
Groupcomm Profile Registry" (Section 9).
Acknowledgments Acknowledgments
The following individuals were helpful in shaping this document: Ben The following individuals were helpful in shaping this document: Ben
Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and
Peter van der Stok. Peter van der Stok.
The work on this document has been partly supported by the EIT- The work on this document has been partly supported by VINNOVA and
Digital High Impact Initiative ACTIVE. the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
Kista SE-16440 Stockholm Kista SE-16440 Stockholm
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
 End of changes. 39 change blocks. 
109 lines changed or deleted 286 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/