draft-ietf-ace-key-groupcomm-oscore-03.txt   draft-ietf-ace-key-groupcomm-oscore-04.txt 
ACE Working Group M. Tiloca ACE Working Group M. Tiloca
Internet-Draft RISE AB Internet-Draft RISE AB
Intended status: Standards Track J. Park Intended status: Standards Track J. Park
Expires: May 7, 2020 Universitaet Duisburg-Essen Expires: July 18, 2020 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
November 04, 2019 January 15, 2020
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-03 draft-ietf-ace-key-groupcomm-oscore-04
Abstract Abstract
This document describes a method to request and provision keying This specification defines an application profile of the ACE
material in group communication scenarios where the group framework for Authentication and Authorization, to request and
communication is based on CoAP and secured with Object Security for provision keying material in group communication scenarios that are
Constrained RESTful Environments (OSCORE). The proposed method based on CoAP and secured with Group Object Security for Constrained
delegates the authentication and authorization of new client nodes RESTful Environments (OSCORE). This application profile delegates
that join an OSCORE group through a Group Manager server. This the authentication and authorization of Clients that join an OSCORE
approach builds on the ACE framework for Authentication and group through a Resource Server acting as Group Manager for that
Authorization, and leverages protocol-specific transport profiles of group. This application profile leverages protocol-specific
ACE to achieve communication security, proof-of-possession and server transport profiles of ACE to achieve communication security, server
authentication. authentication and proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 access token.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 7, 2020. This Internet-Draft will expire on July 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 2.1. Overview of the Joining Process . . . . . . . . . . . . . 5
2.2. Overview of the Group Rekeying Process . . . . . . . . . 8 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6
3. Joining Node to Authorization Server . . . . . . . . . . . . 8 3. Joining Node to Authorization Server . . . . . . . . . . . . 6
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6
3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7
4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 4. Joining a Group . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Joining Request . . . . . . . . . . . . . . . . . . . . . 12 4.2. Sending the Joining Request . . . . . . . . . . . . . . . 8
4.3. Joining Response . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 9
5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 17 4.3. Processing the Joining Request . . . . . . . . . . . . . 10
6. Retrieval of Updated Keying Material . . . . . . . . . . . . 19 4.4. Joining Response . . . . . . . . . . . . . . . . . . . . 11
7. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 14
8. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 15
9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20 6.1. Retrieval of Group Keying Material . . . . . . . . . . . 16
10. Retrieval of Keying Material Version . . . . . . . . . . . . 21 6.2. Retrieval of Group Keying Material and Sender ID . . . . 16
11. Request to Leave the Group . . . . . . . . . . . . . . . . . 21 7. Retrieval of New Keying Material . . . . . . . . . . . . . . 16
12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21 8. Retrieval of Public Keys of Group Members . . . . . . . . . . 17
13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22 9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Retrieval of Keying Material Version . . . . . . . . . . . . 18
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Request to Leave the Group . . . . . . . . . . . . . . . . . 18
15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 24 12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 18
15.2. OSCORE Security Context Parameters Registry . . . . . . 24 13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 19
15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15.4. Sequence Number Synchronization Method Registry . . . . 26 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 27 15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 15.2. OSCORE Security Context Parameters Registry . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . 27 15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . 28 15.4. Sequence Number Synchronization Method Registry . . . . 23
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 29 15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 24
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . 24
B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . 26
B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 32 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 27
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 B.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 29
B.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 30
B.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
[RFC8613] is a method for application-layer protection of the [RFC8613] is a method for application-layer protection of the
Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object
Signing and Encryption (COSE) [RFC8152] and enabling end-to-end Signing and Encryption (COSE) [RFC8152] and enabling end-to-end
security of CoAP payload and options. security of CoAP payload and options.
As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is
used to protect CoAP group communication over IP multicast used to protect CoAP group communication over IP multicast
[RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group [I-D.dijk-core-groupcomm-bis]. This relies on a Group Manager, which
Manager, which is responsible for managing an OSCORE group, where is responsible for managing an OSCORE group, where members exchange
members exchange CoAP messages secured with Group OSCORE. The Group CoAP messages secured with Group OSCORE. The Group Manager can be
Manager can be responsible for multiple groups, coordinates the responsible for multiple groups, coordinates the joining process of
joining process of new group members, and is entrusted with the new group members, and is entrusted with the distribution and renewal
distribution and renewal of group keying material. of group keying material.
This specification builds on the ACE framework for Authentication and
Authorization [I-D.ietf-ace-oauth-authz] and defines a method to:
o Authorize a node to join an OSCORE group, and provide it with the
group keying material to communicate with other group members.
o Provide updated keying material to group members upon request.
o Renew the group keying material and distribute it to the OSCORE
group (rekeying) upon changes in the group membership.
A client node joins an OSCORE group through a resource server acting
as Group Manager for that group. The joining process relies on an
Access Token, which is bound to a proof-of-possession key and
authorizes the client to access a specific group-membership resource
at the Group Manager.
Message exchanges among the participants as well as message formats
and processing follow what specified in [I-D.ietf-ace-key-groupcomm]
for provisioning and renewing keying material in group communication
scenarios.
In order to achieve communication security, proof-of-possession and This specification is an application profile of
server authentication, the client and the Group Manager leverage [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE
protocol-specific transport profiles of ACE. These include also framework for Authentication and Authorization
possible forthcoming transport profiles that comply with the [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants
requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. as well as message formats and processing follow what specified in
[I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying
material in group communication scenarios, where Group OSCORE is used
to protect CoAP group communication over IP multicast.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with:
described in the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz]. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. In
particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS).
Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol described in
[RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless
otherwise indicated, the term "endpoint" is used here following its
OAuth definition, aimed at denoting resources such as /token and
/introspect at the AS and /authz-info at the RS. This document does
not use the CoAP definition of "endpoint", which is "An entity
participating in the CoAP protocol".
Readers are expected to be familiar with the terms and concepts for o The terms and concepts described in the ACE framework for
protection and processing of CoAP messages through OSCORE [RFC8613] authentication and authorization [I-D.ietf-ace-oauth-authz]. The
and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] in group terminology for entities in the considered architecture is defined
communication scenarios. These include the concept of Group Manager, in OAuth 2.0 [RFC6749]. In particular, this includes Client (C),
as the entity responsible for a set of groups where communications Resource Server (RS), and Authorization Server (AS).
are secured with Group OSCORE. In this specification, the Group
Manager acts as Resource Server.
This document refers also to the following terminology. o The terms and concepts related to the CoAP protocol described in
[RFC7252][I-D.dijk-core-groupcomm-bis]. Unless otherwise
indicated, the term "endpoint" is used here following its OAuth
definition, aimed at denoting resources such as /token and
/introspect at the AS and /authz-info at the RS. This document
does not use the CoAP definition of "endpoint", which is "An
entity participating in the CoAP protocol".
o Joining node: a network node intending to join an OSCORE group, o The terms and concept related to the message formats and
where communication is based on CoAP processing specified in [I-D.ietf-ace-key-groupcomm], for
[RFC7390][I-D.dijk-core-groupcomm-bis] and secured with Group provisioning and renewing keying material in group communication
OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. scenarios.
o Joining process: the process through which a joining node becomes o The terms and concepts for protection and processing of CoAP
a member of an OSCORE group. The joining process is enforced and messages through OSCORE [RFC8613] and through Group OSCORE
assisted by the Group Manager responsible for that group. [I-D.ietf-core-oscore-groupcomm] in group communication scenarios.
These include the concept of Group Manager, as the entity
responsible for a set of groups where communications are secured
with Group OSCORE. In this specification, the Group Manager acts
as Resource Server.
o Group name: stable and invariant identifier of an OSCORE group. Additionally, this document makes use of the following terminology.
The group name MUST be unique under the same Group Manager, and
MUST include only characters that are valid for a url-path
segment, namely unreserved and pct-encoded characters [RFC3986].
o Group-membership resource: a resource hosted by the Group Manager, o Group name is used as a synonym for group identifier in
associated to an OSCORE group under that Group Manager. A group- [I-D.ietf-ace-key-groupcomm].
membership resource is identifiable with the name of the
respective OSCORE group. A joining node accesses a group-
membership resource to start the joining process and become a
member of that group. The url-path of a group-membership resource
is fixed, and ends with the segments /group-oscore/NAME , where
"NAME" is the name of the associated OSCORE group. This replaces
the url-path /ace-group/gid at the KDC used in
[I-D.ietf-ace-key-groupcomm], with "gid" indicating the group
identifier. The url-path /group-oscore/NAME is a default name:
implementations are not required to use this name, and can define
their own instead.
o Group-membership endpoint: an endpoint at the Group Manager o GROUPNAME and NODENAME are used to indicate the variant parts of
associated to a group-membership resource. the resource endpoint, i.e. "gid" and "node" URI path in
[I-D.ietf-ace-key-groupcomm].
o Requester: member of an OSCORE group that sends request messages o Requester: member of an OSCORE group that sends request messages
to other members of the group. to other members of the group.
o Responder: member of an OSCORE group that receives request o Responder: member of an OSCORE group that receives request
messages from other members of the group. A responder may reply messages from other members of the group. A responder may reply
back, by sending a response message to the requester which has back, by sending a response message to the requester which has
sent the request message. sent the request message.
o Monitor: member of an OSCORE group that is configured as responder o Monitor: member of an OSCORE group that is configured as responder
and never replies back to requesters after receiving request and never replies back to requesters after receiving request
messages. This corresponds to the term "silent server" used in messages. This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
o Group rekeying process: the process through which the Group
Manager renews the security parameters and group keying material,
and (re-)distributes them to the OSCORE group members.
2. Protocol Overview 2. Protocol Overview
Group communication for CoAP over IP multicast has been enabled in Group communication for CoAP over IP multicast has been enabled in
[RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Group [I-D.dijk-core-groupcomm-bis] and can be secured with Group Object
Object Security for Constrained RESTful Environments (OSCORE) Security for Constrained RESTful Environments (OSCORE) [RFC8613] as
[RFC8613] as described in [I-D.ietf-core-oscore-groupcomm]. A described in [I-D.ietf-core-oscore-groupcomm]. A network node joins
network node joins an OSCORE group by interacting with the an OSCORE group by interacting with the responsible Group Manager.
responsible Group Manager. Once registered in the group, the new Once registered in the group, the new node can securely exchange
node can securely exchange messages with other group members. messages with other group members.
This specification describes how to use the ACE framework for
authentication and authorization [I-D.ietf-ace-oauth-authz] to:
o Enable a node to join an OSCORE group through the Group Manager
and receive the security parameters and keying material to
communicate with the other members of the group.
o Enable members of OSCORE groups to retrieve updated group keying
material and public key of other group members, from the Group
Manager.
o Enable the Group Manager to renew the security parameters and This specification describes how to use [I-D.ietf-ace-key-groupcomm]
group keying material, and to (re-)distribute them to the members and [I-D.ietf-ace-oauth-authz] to perform a number of authentication,
of the OSCORE group (rekeying). authorization and key distribution actions, as defined in Section 2.
of [I-D.ietf-ace-key-groupcomm], for an OSCORE group.
With reference to the ACE framework and the terminology defined in With reference to [I-D.ietf-ace-key-groupcomm]:
OAuth 2.0 [RFC6749]:
o The Group Manager acts as Resource Server (RS), and hosts one o The node wishing to joining the OSCORE group, i.e. the joining
group-membership resource for each OSCORE group it manages. Each node, is the Client.
group-membership resource is exported by a distinct group-
membership endpoint. During the joining process, the Group
Manager provides joining nodes with the parameters and keying
material for taking part to secure communications in the OSCORE
group. The Group Manager also maintains the group keying material
and performs the group rekeying process to distribute updated
keying material to the group members.
o The joining node acts as Client (C), and requests to join an o The Group Manager is the Key Distribution Center (KDC), acting as
OSCORE group by accessing the related group-membership endpoint at a Resource Server.
the Group Manager.
o The Authorization Server (AS) authorizes joining nodes to join o The Authorization Server associated to the Group Manager is the
OSCORE groups under their respective Group Manager. Multiple AS.
Group Managers can be associated to the same AS. The AS MAY
release Access Tokens for other purposes than joining OSCORE
groups under registered Group Managers. For example, the AS may
also release Access Tokens for accessing resources hosted by
members of OSCORE groups.
All communications between the involved entities rely on the CoAP All communications between the involved entities rely on the CoAP
protocol and MUST be secured. protocol and MUST be secured.
In particular, communications between the joining node and the Group In particular, communications between the Client and the Group
Manager leverage protocol-specific transport profiles of ACE to Manager leverage protocol-specific transport profiles of ACE to
achieve communication security, proof-of-possession and server achieve communication security, proof-of-possession and server
authentication. To this end, the AS MAY signal the specific authentication. Note that it is expected that in the commonly
transport profile to use, consistently with requirements and referred base-case of this specification, the transport profile to
assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].
Note that in the commonly referred base-case the transport profile to
use is pre-configured and well-known to nodes participating in use is pre-configured and well-known to nodes participating in
constrained applications. constrained applications.
With reference to the AS, communications between the joining node and
the AS (/token endpoint) as well as between the Group Manager and the
AS (/introspect endpoint) can be secured by different means, for
instance using DTLS [RFC6347] or OSCORE [RFC8613]. Further details
on how the AS secures communications (with the joining node and the
Group Manager) depend on the specifically used transport profile of
ACE, and are out of the scope of this specification.
2.1. Overview of the Joining Process 2.1. Overview of the Joining Process
A node performs the following steps in order to join an OSCORE group. A node performs the steps described in Section 4.2 of
The format and processing of messages exchanged among the [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The
participants follow what is defined in [I-D.ietf-ace-key-groupcomm], format and processing of messages exchanged among the participants
and are further specified in Section 3 and Section 4 of this are further specified in Section 3 and Section 4 of this document.
document. The Group Manager acts as the Key Distribution Center
(KDC) defined in [I-D.ietf-ace-key-groupcomm].
1. The joining node requests an Access Token from the AS, in order
to access a group-membership resource on the Group Manager and
hence join the associated OSCORE group (see Section 3). The
joining node will start or continue using a secure communication
association with the Group Manager, according to the response
from the AS.
2. The joining node transfers authentication and authorization
information to the Group Manager, by posting the obtained Access
Token to the /authz-info endpoint at the Group Manager (see
Section 4). After that, a joining node MUST have a secure
communication association established with the Group Manager,
before starting to join an OSCORE group under that Group Manager
(see Section 4). Possible ways to provide a secure communication
association are DTLS [RFC6347] and OSCORE [RFC8613].
3. The joining node starts the joining process to become a member of
the OSCORE group, by accessing the related group-membership
resource hosted by the Group Manager (see Section 4).
4. At the end of the joining process, the joining node has received
from the Group Manager the parameters and keying material to
securely communicate with the other members of the OSCORE group.
5. The joining node and the Group Manager maintain the secure
association, to support possible future communications. These
especially include key management operations, such as retrieval
of updated keying material from the Group Manager or
participation to a group rekeying process (see Section 2.2).
All further communications between the joining node and the Group
Manager MUST be secured, for instance with the same secure
association mentioned in step 2.
2.2. Overview of the Group Rekeying Process 2.2. Overview of the Group Rekeying Process
If the application requires backward and forward security, the Group If the application requires backward and forward security, the Group
Manager MUST generate new security parameters and group keying Manager MUST generate new security parameters and group keying
material, and distribute them to the group (rekeying) upon membership material, and distribute them to the group (rekeying) upon membership
changes. changes.
That is, the group is rekeyed when a node joins the group as a new That is, the group is rekeyed when a node joins the group as a new
member, or after a current member leaves the group. By doing so, a member, or after a current member leaves the group. By doing so, a
skipping to change at page 8, line 44 skipping to change at page 6, line 38
3. Joining Node to Authorization Server 3. Joining Node to Authorization Server
This section describes how the joining node interacts with the AS in This section describes how the joining node interacts with the AS in
order to be authorized to join an OSCORE group under a given Group order to be authorized to join an OSCORE group under a given Group
Manager. In particular, it considers a joining node that intends to Manager. In particular, it considers a joining node that intends to
contact that Group Manager for the first time. contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined the messages Authorization Request and Authorization Response defined
in Section 3 of [I-D.ietf-ace-key-groupcomm]. in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is
defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions
In case the specific AS associated to the Group Manager is unknown to or modifications to that specification are defined here.
the joining node, the latter can rely on mechanisms like the
Unauthorized Resource Request message described in Section 5.1.1 of
[I-D.ietf-ace-oauth-authz] to discover the correct AS to contact.
3.1. Authorization Request 3.1. Authorization Request
The joining node contacts the AS, in order to request an Access Token The Authorization Request message defined in Section 3.1 of
for accessing the group-membership resource hosted by the Group [I-D.ietf-ace-key-groupcomm], with the following additions:
Manager and associated to the OSCORE group. The Access Token request
sent to the /token endpoint follows the format of the Authorization
Request message defined in Section 3.1 of
[I-D.ietf-ace-key-groupcomm]. In particular:
o The 'scope' parameter MUST be present and MUST include: o The 'scope' parameter MUST be present.
* in the first element, the name of the OSCORE group to join o The group name of the OSCORE group to join under the Group Manager
under the Group Manager, encoded as a CBOR text string. is encoded as a CBOR text string.
* in the second element, the role (encoded as a text string) or o The role in the OSCORE group to join is encoded as a text string.
CBOR array of roles that the joining node intends to have in Accepted values of roles are: "requester", "responder", and
the group it intends to join. Accepted values of roles are: "monitor". Possible combinations are: ["requester" ,
"requester", "responder", and "monitor". Possible combinations "responder"]; ["requester" , "monitor"].
are: ["requester" , "responder"]; ["requester" , "monitor"].
o The 'audience' parameter MUST be present and is set to the o The 'audience' parameter MUST be present.
identifier of the Group Manager.
3.2. Authorization Response 3.2. Authorization Response
The AS is responsible for authorizing the joining node to join The Authorization Response message defined in Section 3.2 of
specific OSCORE groups, according to join policies enforced on behalf [I-D.ietf-ace-key-groupcomm], with the following additions:
of the respective Group Manager.
In case of successful authorization, the AS releases an Access Token
bound to a proof-of-possession key associated to the joining node.
Then, the AS provides the joining node with the Access Token as part
of an Access Token response, which follows the format of the
Authorization Response message defined in Section 3.2 of
[I-D.ietf-ace-key-groupcomm].
The AS MUST include the 'exp' parameter in the response to the
joining node. Other means for the AS to specify the lifetime of
Access Tokens are out of the scope of this specification.
The AS must include the 'scope' parameter in the response to the
joining node, when the value included in the Access Token differs
from the one specified by the joining node in the request. In such a
case, the second element of 'scope' MUST be present and includes the
role or CBOR array of roles that the joining node is actually
authorized to take in the group, encoded as specified in Section 3.1
of this document.
The AS MAY also include the 'profile' parameter in the response to o The AS MUST include the 'exp' parameter. Other means for the AS
the joining node, in order to indicate the specific transport profile to specify the lifetime of Access Tokens are out of the scope of
of ACE to use for securing communications between the joining node this specification.
and the Group Manager (see Section 5.6.4.3 of
[I-D.ietf-ace-oauth-authz]).
In particular, if symmetric keys are used, the AS generates a proof- o The AS MUST include the 'scope' parameter, when the value included
of-possession key, binds it to the Access Token, and provides it to in the Access Token differs from the one specified by the joining
the joining node in the 'cnf' parameter of the Access Token response. node in the request. In such a case, the second element of
Instead, if asymmetric keys are used, the joining node provides its 'scope' MUST be present and includes the role or CBOR array of
own public key to the AS in the 'req_cnf' parameter of the Access roles that the joining node is actually authorized to take in the
Token request. Then, the AS uses it as proof-of-possession key bound OSCORE group, encoded as specified in Section 3.1 of this
to the Access Token, and provides the joining node with the Group document.
Manager's public key in the 'rs_cnf' parameter of the Access Token
response.
4. Joining Node to Group Manager 4. Joining a Group
The following subsections describe the interactions between the The following subsections describe the interactions between the
joining node and the Group Manager, i.e. the sending of the Access joining node and the Group Manager, i.e. the sending of the Access
Token and the Request-Response exchange to join the OSCORE group. Token and the Request-Response exchange to join the OSCORE group.
The message exchange between the joining node and the KDC consists of
the messages defined in Section 3.3 and 4.2 of
[I-D.ietf-ace-key-groupcomm]. Note that what is defined in
[I-D.ietf-ace-key-groupcomm] applies, and only additions or
modifications to that specification are defined here.
4.1. Token Post 4.1. Token Post
The joining node posts the Access Token to the /authz-info endpoint The Token post exchange is defined in Section 3.3 of
at the Group Manager, according to the Token post defined in [I-D.ietf-ace-key-groupcomm].
Section 3.3 of [I-D.ietf-ace-key-groupcomm].
At this point in time, the joining node might not have all the
necessary information concerning the public keys in the OSCORE group,
as well as concerning the algorithm and related parameters for
computing countersignatures in the OSCORE group. In such a case, the
joining node MAY use the 'sign_info' and 'pub_key_enc' parameters
defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for
such information.
Alternatively, the joining node may retrieve this information by
other means, e.g. by using the approach described in
[I-D.tiloca-core-oscore-discovery].
If the Access Token is valid, the Group Manager responds to the POST
request with a 2.01 (Created) response, according to what is
specified in the signalled transport profile of ACE. The Group
Manager MUST use the Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz].
The payload of the 2.01 (Created) response is a CBOR map, which MUST
include the 'rsnonce' parameter defined in Section 3.3.3 of
[I-D.ietf-ace-key-groupcomm], and MAY include the 'sign_info' Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
parameter as well as the 'pub_key_enc' parameter, defined in its following applies.
Sections 3.3.1 and 3.3.2, respectively. Note that this deviates from
the default payload format for this response message as defined in
the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]).
The 'rsnonce' parameter includes a dedicated nonce N_S generated by o The 'rsnonce' parameter contains a dedicated 8-byte nonce N_S
the Group Manager. The joining node may use this nonce in order to generated by the Group Manager. The joining node may use this
prove the possession of its own private key, upon joining the group nonce in order to prove the possession of its own private key,
(see Section 4.2). upon joining the group (see Section 4.2).
If present in the response: o If 'sign_info' is present in the response:
o 'sign_alg', i.e. the first element of the 'sign_info' parameter, * 'sign_alg' takes value from Tables 5 and 6 of [RFC8152].
takes value from Tables 5 and 6 of [RFC8152].
o 'sign_parameters', i.e. the second element of the 'sign_info' * 'sign_parameters' takes values from the "Counter Signature
parameter, takes values from the "Counter Signature Parameters" Parameters" Registry (see Section 9.1 of
Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]). Its structure depends on
Its structure depends on the value of 'sign_alg'. If no the value of 'sign_alg'. If no parameters of the counter
parameters of the counter signature algorithm are specified, signature algorithm are specified, 'sign_parameters' MUST be
'sign_parameters' MUST be encoding the CBOR simple value Null. encoding the CBOR simple value Null.
o 'sign_key_parameters', i.e. the third element of the 'sign_info' * 'sign_key_parameters' takes values from the "Counter Signature
parameter, takes values from the "Counter Signature Key Key Parameters" Registry (see Section 9.2 of
Parameters" Registry (see Section 9.2 of [I-D.ietf-core-oscore-groupcomm]). Its structure depends on
[I-D.ietf-core-oscore-groupcomm]). Its structure depends on the the value of 'sign_alg'. If no parameters of the key used with
value of 'sign_alg'. If no parameters of the key used with the the counter signature algorithm are specified,
counter signature algorithm are specified, 'sign_key_parameters' 'sign_key_parameters' MUST be encoding the CBOR simple value
MUST be encoding the CBOR simple value Null. Null.
o 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation * 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation
Key' column of the "CWT Confirmation Method" Registry defined in Key' column of the "CWT Confirmation Method" Registry defined
[I-D.ietf-ace-cwt-proof-of-possession], so indicating that public in [I-D.ietf-ace-cwt-proof-of-possession], so indicating that
keys in the OSCORE group are encoded as COSE Keys [RFC8152]. public keys in the OSCORE group are encoded as COSE Keys
Future specifications may define additional values for this [RFC8152]. Future specifications may define additional values
parameter. for this parameter.
The CBOR map specified as payload of the 2.01 (Created) response may Note that, other than through the above parameters as defined in
include further parameters, e.g. according to the signalled transport Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY
profile of ACE. have previously retrieved this information by other means, e.g. by
using the approach described in
[I-D.tiloca-core-oscore-discovery].
Finally, the joining node establishes a secure channel with the Group Additionally, if allowed by the used transport profile of ACE, the
Manager, according to what is specified in the Access Token response joining node may instead provide the Access Token to the Group
and the signalled transport profile of ACE. Manager by other means, e.g. during a secure session establishment
(see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]).
4.2. Joining Request 4.2. Sending the Joining Request
Once a secure communication channel with the Group Manager has been The joining node requests to join the OSCORE group, by sending a
established, the joining node requests to join the OSCORE group, by Joining Request message to the related group-membership resource at
sending a Joining Request message to the related group-membership the Group Manager, as per Section 4.2 of
resource at the Group Manager, as per Section 4.2 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
In particular, the joining node sends a CoAP POST request to the Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
endpoint /group-oscore/NAME at the Group Manager, where NAME is the following applies.
name of the OSCORE group to join. This Joining Request is formatted
as defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. o The string "group-oscore" is used instead of "ace-group" (see
Specifically: Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path
to the group-membership resource. The url-path /group-oscore/ is
a default name of this specifications: implementations are not
required to use this name, and can define their own instead.
o The 'scope' parameter MUST be present. o The 'scope' parameter MUST be present.
o The 'get_pub_keys' parameter is present only if the joining node o The 'get_pub_keys' parameter is present only if the joining node
wants to retrieve the public keys of the group members from the wants to retrieve the public keys of the group members from the
Group Manager during the joining process (see Section 5). Group Manager during the joining process (see Section 5).
Otherwise, this parameter MUST NOT be present. Otherwise, this parameter MUST NOT be present.
o The 'client_cred' parameter, if present, includes the public key o 'cnonce' contains a dedicated 8-byte nonce N_C generated by the
of the joining node. In case the joining node knows the encoding joining node.
of public keys in the OSCORE group, as well as the
countersignature algorithm and possible associated parameters used
in the OSCORE group, the included public key MUST be compatible
with those criteria. That is, the public key MUST be encoded
according to the encoding of public keys in the OSCORE group, and
MUST be compatible with the countersignature algorithm and
possible associated parameters used in the OSCORE group. This
parameter MAY be omitted if: i) the joining node is asking to
access the group exclusively as monitor; or ii) the Group Manager
already acquired this information, for instance during a past
joining process. In any other case, this parameter MUST be
present.
Furthermore, if the 'client_cred' parameter is present, the CBOR map o The signature encoded in the 'client_cred_verify' parameter is
specified as payload of the Joining Request MUST also include the computed by the joining node by using the same private key and
following parameters. countersignature algorithm it intends to use for signing messages
in the OSCORE group. Moreover, N_S is as defined in
Section 4.2.1.
o 'cnonce', as defined in Section 5.1.2 of 4.2.1. Value of the N_S Challenge
[I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C
generated by the Client.
o The 'client_cred_verify' parameter, including a signature encoded The N_S challenge takes one of the following values.
as a CBOR byte string, computed by the joining node to prove
possession of its own private key. The signature is computed over
N_S concatenated with N_C, where N_S is the nonce received in the
'rsnonce' parameter of the 2.01 (Created) response to the Token
POST (see Section 4.1), while N_C is the nonce generated by the
Client and specified in the 'cnonce' parameter above. The joining
node computes the signature by using the same private key and
countersignature algorithm it intends to use for signing messages
in the OSCORE group.
4.3. Joining Response 1. If the joining node has posted the Access Token to the /authz-
info endpoint of the Group Manager as in Section 4.1, N_S takes
the same value of the 'rsnonce' parameter in the 2.01 (Created)
response to the Token POST.
The Group Manager processes the Joining Request as defined in 2. If the Token posting has relied on the DTLS profile of ACE
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Also, the Group [I-D.ietf-ace-dtls-authorize] and the joining node included the
Manager MUST return a 4.00 (Bad Request) response in case the Joining Access Token as content of the "psk_identity" field of the
Request includes the 'client_cred' parameter but does not include ClientKeyExchange message [RFC6347], N_S is an exporter value
both the 'cnonce' and 'client_cred_verify' parameters. computed as defined in Section 7.5 of [RFC8446]. Specifically,
N_S is exported from the DTLS session between the joining node
and the Group Manager, using an empty 'context_value', 32 bytes
as 'key_length', and the exporter label "EXPORTER-ACE-Sign-
Challenge" defined in Section 7 of
[I-D.ietf-ace-mqtt-tls-profile].
If the request processing yields a positive outcome, the Group 3. If the joining node is in fact re-joining the group, without
Manager performs the further following checks. posting again the same and still valid Access Token:
o In case the Joining Request includes the 'client_cred' parameter, * If the joining node and the Group Manager communicates using
the Group Manager checks that the public key of the joining node DTLS, N_S is an exporter value, computed as described in point
has an accepted format. That is, the public key has to be encoded (2) above.
as expected in the OSCORE group, and has to be compatible with the
counter signature algorithm and possible associated parameters * If the joining node and the Group Manager communicates using
used in the OSCORE group. The joining process fails if the public OSCORE [RFC8613], the N_S is the output PRK of a HKDF-Extract
key of the joining node does not have an accepted format. step [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In
particular, 'salt' takes (x1 | x2), where x1 is the ID Context
of the OSCORE Security Context between the joining node and
the Group Manager, x2 is the Sender ID of the joining node in
that Context, and | denotes byte string concatenation. Also,
'IKM' is the OSCORE Master Secret of the OSCORE Security
Context between the joining node and the Group Manager. The
HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms
defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to
implement.
It is up to applications to define how N_S is computed in further
alternative settings.
4.3. Processing the Joining Request
The Group Manager processes the Joining Request as defined in
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the
following applies.
o In case the Joining Request does not include the 'client_cred' o In case the Joining Request does not include the 'client_cred'
parameter, the Group Manager checks whether it is storing a public parameter, the joining process fails if the Group Manager either:
key for the joining node, which is compatible with the encoding, i) does not store a public key with an accepted format for the
counter signature algorithm and possible associated parameters joining node; or ii) stores multiple public keys with an accepted
used in the OSCORE group. The joining process fails if the Group format for the joining node.
Manager either: i) does not store a public key with an accepted
format for the joining node; or ii) stores multiple public keys
with an accepted format for the joining node.
o In case the Joining Request includes the 'client_cred_verify' o To compute the signature contained in 'client_cred_verify', the GM
parameter, the Group Manager verifies the signature contained in considers: i) as signed value, N_S concatenated with N_C, where
the parameter. To this end, it considers: i) as signed value, N_S N_S is determined as described in Section 4.2.1, while N_C is the
concatenated with N_C, where N_S is the nonce previously provided nonce provided in the 'cnonce' parameter of the Joining Request;
in the 'rsnonce' parameter of the 2.01 (Created) response to the ii) the countersignature algorithm used in the OSCORE group, and
Token POST (see Section 4.1), while N_C is the nonce provided in possible correponding parameters; and iii) the public key of the
the 'cnonce' parameter of the Joining Request; ii) the joining node, either retrieved from the 'client_cred' parameter,
countersignature algorithm used in the OSCORE group, and possible or already stored as acquired from previous interactions with the
correponding parameters; and iii) the public key of the joining joining node.
node, either retrieved from the 'client_cred' parameter, or
already stored as acquired from previous interactions with the
joining node. The joining process fails if the Group Manager does
not successfully verify the signature.
If the joining process has failed, the Group Manager MUST reply to o A 4.00 Bad Request response from the Group Manager to the joining
the joining node with a 4.00 (Bad Request) response. The payload of node MUST have content format application/ace-group+cbor. The
this response is a CBOR map, which includes a 'sign_info' parameter response payload is a CBOR map which MUST contain the 'sign_info'
and a 'pub_key_enc' parameter, formatted as in the Token POST as well as the 'pub_key_enc' parameters.
response in Section 4.1.
Upon receiving this response, the joining node SHOULD send a new o The Group Manager MUST return a 4.00 (Bad Request) response in
Joining Request to the Group Manager, which contains: case the Joining Request includes the 'client_cred' parameter but
does not include both the 'cnonce' and 'client_cred_verify'
parameters.
o The 'client_cred' parameter, including a public key compatible o The Group Manager MUST return a 4.00 (Bad Request) response in
with the encoding, countersignature algorithm and possible case it cannot retrieve a public key with an accepted format for
associated parameters indicated by the Group Manager. the joining node, either from the 'client_cred' parameter or as
already stored.
o The 'client_cred_verify' parameter, including a signature computed o When receiving a 4.00 Bad Request response, the joining node
as described in Section 4.2, by using the public key indicated in SHOULD send a new Joining Request to the Group Manager,
the current 'client_cred' parameter, with the countersignature containing:
algorithm and possible associated parameters indicated by the
Group Manager.
Otherwise, in case of success, the Group Manager updates the group * The 'client_cred' parameter, including a public key compatible
membership by registering the joining node as a new member of the with the encoding, countersignature algorithm and possible
OSCORE group. If the joining node is not exclusively configured as associated parameters indicated by the Group Manager.
monitor, the Group Manager performs also the following actions.
o The Group Manager selects an available OSCORE Sender ID in the * The 'client_cred_verify' parameter, including a signature
OSCORE group, and exclusively assigns it to the joining node. computed as described in Section 4.2, by using the public key
indicated in the current 'client_cred' parameter, with the
countersignature algorithm and possible associated parameters
indicated by the Group Manager.
o If the 'client_cred' parameter was present in the request, the 4.4. Joining Response
Group Manager adds the specified public key of the joining node to
the list of public keys of the current group members.
o If the 'client_cred' parameter was not present in the request, the If the processing of the Joining Request described in Section 4.3 is
Group Manager retrieves the already stored public key of the successful, the Group Manager updates the group membership by
joining node, as acquired from previous interactions (see also registering the joining node NODENAME as a new member of the OSCORE
Section 5). Then, the Group Manager adds the retrieved public key group GROUPNAME, as described in Section 4.1.2.1 of
to the list of public keys of the current group members. [I-D.ietf-ace-key-groupcomm].
If the joining node is not exclusively configured as monitor, the
Group Manager performs also the following actions.
o The Group Manager selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node.
o The Group Manager stores the association between i) the public key o The Group Manager stores the association between i) the public key
of the joining node; and ii) the Group Identifier (Gid) associated of the joining node; and ii) the Group Identifier (Gid), i.e. the
to the OSCORE group together with the OSCORE Sender ID assigned to OSCORE ID Context, associated to the OSCORE group together with
the joining node in the group. The Group Manager MUST keep this the OSCORE Sender ID assigned to the joining node in the group.
association updated over time. The Group Manager MUST keep this association updated over time.
Then, the Group Manager replies to the joining node providing the Then, the Group Manager replies to the joining node, providing the
updated security parameters and keying meterial necessary to updated security parameters and keying meterial necessary to
participate in the group communication. This success Joining participate in the group communication. This success Joining
Response is formatted as defined in Section 4.1.2.1 of Response is formatted as defined in Section 4.1.2.1 of
[I-D.ietf-ace-key-groupcomm]. In particular: [I-D.ietf-ace-key-groupcomm], with the following additions:
o The 'kty' parameter identifies a key of type o The 'gkty' parameter identifies a key of type
"Group_OSCORE_Security_Context object", defined in Section 15.1 of "Group_OSCORE_Security_Context object", defined in Section 15.1 of
this specification. this specification.
o The 'key' parameter includes what the joining node needs in order o The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of to set up the OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm]. This parameter has as value a [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a
Group_OSCORE_Security_Context object, which is defined in this Group_OSCORE_Security_Context object, which is defined in this
specification and extends the OSCORE_Security_Context object specification and extends the OSCORE_Security_Context object
encoded in CBOR as defined in Section 3.2.1 of encoded in CBOR as defined in Section 3.2.1 of
[I-D.ietf-ace-oscore-profile]. In particular, it contains the [I-D.ietf-ace-oscore-profile]. In particular, it contains the
skipping to change at page 15, line 40 skipping to change at page 12, line 36
* The 'hkdf' parameter, if present, has as value the KDF * The 'hkdf' parameter, if present, has as value the KDF
algorithm used in the group. algorithm used in the group.
* The 'alg' parameter, if present, has as value the AEAD * The 'alg' parameter, if present, has as value the AEAD
algorithm used in the group. algorithm used in the group.
* The 'salt' parameter, if present, has as value the OSCORE * The 'salt' parameter, if present, has as value the OSCORE
Master Salt. Master Salt.
* The 'contextId' parameter MUST be present and has as value the * The 'contextId' parameter MUST be present and has as value the
Group Identifier (Gid) associated to the OSCORE group. Group Identifier (Gid), i.e. the OSCORE ID Context of the
OSCORE group.
* The 'rpl' parameter, if present, specifies the OSCORE Replay * The 'rpl' parameter, if present, specifies the OSCORE Replay
Window Size and Type value. Window Size and Type value.
* The 'cs_alg' parameter MUST be present and specifies the * The 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the group. This algorithm used to countersign messages in the group. This
parameter takes values from Tables 5 and 6 of [RFC8152]. parameter takes values from Tables 5 and 6 of [RFC8152].
* The 'cs_params' parameter MAY be present and specifies the * The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm. additional parameters for the counter signature algorithm.
skipping to change at page 16, line 25 skipping to change at page 13, line 23
encoding of the public keys of the group members. This encoding of the public keys of the group members. This
parameter is a CBOR integer, whose value is 1 ("COSE_Key") parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in Confirmation Method" Registry defined in
[I-D.ietf-ace-cwt-proof-of-possession], so indicating that [I-D.ietf-ace-cwt-proof-of-possession], so indicating that
public keys in the OSCORE group are encoded as COSE Keys public keys in the OSCORE group are encoded as COSE Keys
[RFC8152]. Future specifications may define additional values [RFC8152]. Future specifications may define additional values
for this parameter. If this parameter is not present, 1 for this parameter. If this parameter is not present, 1
("COSE_Key") MUST be assumed as default value. ("COSE_Key") MUST be assumed as default value.
o The 'num' parameter MUST be present and specifies the current o The 'num' parameter MUST be present.
version number of the group keying material.
o The 'profile' parameter MUST be present and has value o The 'ace-groupcomm-profile' parameter MUST be present and has
coap_group_oscore_app (TBD), which is defined in Section 15.3 of value coap_group_oscore_app (TBD), which is defined in
this specification. Section 15.3 of this specification.
o The 'exp' parameter MUST be present and specifies the expiration o The 'exp' parameter MUST be present.
time in seconds after which the OSCORE Security Context derived
from the 'key' parameter is not valid anymore.
o The 'pub_keys' parameter is present only if the 'get_pub_keys' o The 'pub_keys' parameter, if present, includes the public keys of
parameter was present in the Joining Request. If present, this the group members that are relevant to the joining node. That is,
parameter includes the public keys of the group members that are it includes: i) the public keys of the responders currently in the
relevant to the joining node. That is, it includes: i) the public group, in case the joining node is configured (also) as requester;
keys of the responders currently in the group, in case the joining and ii) the public keys of the requesters currently in the group,
node is configured (also) as requester; and ii) the public keys of in case the joining node is configured (also) as responder or
the requesters currently in the group, in case the joining node is monitor. If public keys are encoded as COSE_Keys, each of them
configured (also) as responder or monitor. If public keys are has as 'kid' the Sender ID that the corresponding owner has in the
encoded as COSE_Keys, each of them has as 'kid' the Sender ID that group, thus used as group member identifier.
the corresponding owner has in the group, thus used as group
member identifier.
o The 'group_policies' parameter SHOULD be present and includes a o The 'group_policies' parameter SHOULD be present, and SHOULD
list of parameters indicating particular policies enforced in the include the elements "Sequence Number Synchronization Method" and
group. In particular, if the field "Sequence Number "Key Update Check Interval" defined in Section 4.1.2. of
Synchronization Method" is present, it indicates the method to
achieve synchronization of sequence numbers among group members
(see Appendix E of [I-D.ietf-core-oscore-groupcomm]), by
specifying the corresponding value from the "Sequence Number
Synchronization Method" Registry defined in Section 8.6 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
Finally, the joining node uses the information received in the Finally, the joining node uses the information received in the
Joining Response to set up the OSCORE Security Context, as described Joining Response to set up the OSCORE Security Context, as described
in Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the in Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the
joining node can exchange group messages secured with Group OSCORE as joining node can exchange group messages secured with Group OSCORE as
described in [I-D.ietf-core-oscore-groupcomm]. described in [I-D.ietf-core-oscore-groupcomm].
If the application requires backward security, the Group Manager MUST If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to all the current group members (see Section 13). provide it to the current group members upon the new node's joining
(see Section 13). As a consequence, the joining node is not able to
access secure communication in the group occurred prior its joining.
5. Public Keys of Joining Nodes 5. Public Keys of Joining Nodes
Source authentication of OSCORE messages exchanged within the group Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures (see Sections 2 and is ensured by means of digital counter signatures (see Sections 2 and
3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members
must be able to retrieve each other's public key from a trusted key must be able to retrieve each other's public key from a trusted key
repository, in order to verify source authenticity of incoming group repository, in order to verify source authenticity of incoming group
messages. messages.
skipping to change at page 19, line 14 skipping to change at page 15, line 49
6. Retrieval of Updated Keying Material 6. Retrieval of Updated Keying Material
At some point, a group member considers the OSCORE Security Context At some point, a group member considers the OSCORE Security Context
invalid and to be renewed. This happens, for instance, after a invalid and to be renewed. This happens, for instance, after a
number of unsuccessful security processing of incoming messages from number of unsuccessful security processing of incoming messages from
other group members, or when the Security Context expires as other group members, or when the Security Context expires as
specified by the 'exp' parameter of the Joining Response. specified by the 'exp' parameter of the Joining Response.
When this happens, the group member retrieves updated security When this happens, the group member retrieves updated security
parameters and group keying material, by sending a Key Distribution parameters and group keying material. This can occur in the two
Request message to the Group Manager, as per Section 4.3 of different ways described below.
[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET
request to the endpoint /group-oscore/NAME at the Group Manager, 6.1. Retrieval of Group Keying Material
where NAME is the name of the OSCORE group. The Key Distribution
Request is formatted as defined in Section 4.1.2.2 of If the group member wants to retrieve only the latest group keying
[I-D.ietf-ace-key-groupcomm]. material, it sends a Key Distribution Request to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to The Group Manager processes the Key Distribution Request according to
Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key
Distribution Response is formatted as defined in Section 4.1.2.2 of Distribution Response is formatted as defined in Section 4.1.2.2 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
Upon receiving the Key Distribution Response, the group member Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters and group keying material, retrieves the updated security parameters and group keying material,
and use them to set up the new OSCORE Security Context as described and, if they differ from the current ones, use them to set up the new
in Section 2 of [I-D.ietf-core-oscore-groupcomm]. OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm].
6.2. Retrieval of Group Keying Material and Sender ID
If the group member wants to retrieve the latest group keying
material as well as the Sender ID that it has in the OSCORE group, it
sends a Key Distribution Request to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME/NODENAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to
Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key
Distribution Response is formatted as defined in Section 4.1.6.2 of
[I-D.ietf-ace-key-groupcomm]. Note that the current Sender ID of the
group member is not specified as a separate parameter, but rather
included as 'clientId' in the 'key' parameter.
Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters, group keying material and
Sender ID, and, if they differ from the current ones, use them to set
up the new OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm].
7. Retrieval of New Keying Material 7. Retrieval of New Keying Material
As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a
group member may at some point experience a wrap-around of its own group member may at some point experience a wrap-around of its own
Sender Sequence Number in the group. Sender Sequence Number in the group.
When this happens, the group member MUST send a Key Renewal Request When this happens, the group member MUST send a Key Renewal Request
message to the Group Manager, as per Section 4.4 of message to the Group Manager, as per Section 4.4 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT
request to the endpoint /group-oscore/NAME/node at the Group Manager, request to the endpoint /group-oscore/GROUPNAME/NODENAME at the Group
where NAME is the name of the OSCORE group. Manager.
Upon receiving the Key Renewal Request, the Group Manager processes Upon receiving the Key Renewal Request, the Group Manager processes
it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and
performs one of the following actions. performs one of the following actions.
1. The Group Manager replies to the group member with a 4.06 (Not 1. The Group Manager replies to the group member with a 4.06 (Not
Acceptable) error response, and rekeys the whole OSCORE group as Acceptable) error response, and rekeys the whole OSCORE group as
discussed in Section 13. discussed in Section 13.
2. The Group Manager generates a new Sender ID for that group member 2. The Group Manager generates a new Sender ID for that group member
skipping to change at page 20, line 19 skipping to change at page 17, line 33
'clientId' defined in Section 15.5 of this document, specifying 'clientId' defined in Section 15.5 of this document, specifying
the new Sender ID of the group member encoded as a CBOR byte the new Sender ID of the group member encoded as a CBOR byte
string. string.
8. Retrieval of Public Keys of Group Members 8. Retrieval of Public Keys of Group Members
A group member may need to retrieve the public keys of other group A group member may need to retrieve the public keys of other group
members. To this end, the group member sends a Public Key Request members. To this end, the group member sends a Public Key Request
message to the Group Manager, as per Section 4.5 of message to the Group Manager, as per Section 4.5 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to
the endpoint /group-oscore/NAME/pub-key at the Group Manager, where the endpoint /group-oscore/GROUPNAME/pub-key at the Group Manager.
NAME is the name of the OSCORE group.
If the Public Key Request uses the method POST, the Public Key If the Public Key Request uses the method FETCH, the Public Key
Request is formatted as defined in Section 4.1.3.1 of Request is formatted as defined in Section 4.1.3.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, each element of the [I-D.ietf-ace-key-groupcomm]. In particular, each element of the
'get_pub_keys' parameter is a CBOR byte string, which encodes the 'get_pub_keys' parameter is a CBOR byte string, which encodes the
Sender ID of the group member for which the associated public key is Sender ID of the group member for which the associated public key is
requested. requested.
Upon receiving the Public Key Request, the Group Manager processes it Upon receiving the Public Key Request, the Group Manager processes it
as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm],
depending on the request method being POST or GET, respectively. If depending on the request method being FETCH or GET, respectively.
the Public Key Request uses the method POST, the Group Manager Additionally, if the Public Key Request uses the method FETCH, the
silently ignores identifiers included in the 'get_pub_keys' parameter Group Manager silently ignores identifiers included in the
of the request that are not associated to any current group member. 'get_pub_keys' parameter of the request that are not associated to
any current group member.
The success Public Key Response is formatted as defined in The success Public Key Response is formatted as defined in
Section 4.1.3.1 of [I-D.ietf-ace-key-groupcomm]. Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending
on the request method being FETCH or GET, respectively.
9. Retrieval of Group Policies 9. Retrieval of Group Policies
A group member may request the current policies used in the OSCORE A group member may request the current policies used in the OSCORE
group. To this end, the group member sends a Policies Request, as group. To this end, the group member sends a Policies Request, as
per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In particular, it per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In particular, it
sends a CoAP GET request to the endpoint /group-oscore/NAME/policies sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/
at the Group Manager, where NAME is the name of the OSCORE group. policies at the Group Manager, where GROUPNAME is the name of the
OSCORE group.
Upon receiving the Policies Request, the Group Manager processes it Upon receiving the Policies Request, the Group Manager processes it
as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success
Policies Response is formatted as defined in Section 4.1.4.1 of Policies Response is formatted as defined in Section 4.1.4.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
10. Retrieval of Keying Material Version 10. Retrieval of Keying Material Version
A group member may request the current version of the keying material A group member may request the current version of the keying material
used in the OSCORE group. To this end, the group member sends a used in the OSCORE group. To this end, the group member sends a
Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm].
In particular, it sends a CoAP GET request to the endpoint /group- In particular, it sends a CoAP GET request to the endpoint /group-
oscore/NAME/ctx-num at the Group Manager, where NAME is the name of oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the
the OSCORE group. name of the OSCORE group.
Upon receiving the Version Request, the Group Manager processes it as Upon receiving the Version Request, the Group Manager processes it as
per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success
Version Response is formatted as defined in Section 4.1.5.1 of Version Response is formatted as defined in Section 4.1.5.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
11. Request to Leave the Group 11. Request to Leave the Group
A group member may request to leave the OSCORE group. To this end, A group member may request to leave the OSCORE group. To this end,
the group member sends a Group Leaving Request, as per Section 4.8 of the group member sends a Group Leaving Request, as per Section 4.8 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE
request to the endpoint /group-oscore/NAME/node at the Group Manager, request to the endpoint /group-oscore/GROUPNAME/NODENAME at the Group
where NAME is the name of the OSCORE group to leave. Manager.
The Leaving Request is formatted as defined in Section 4.1.6.1 of
[I-D.ietf-ace-key-groupcomm], and MUST have an empty CBOR Map as
payload.
Upon receiving the Leaving Request, the Group Manager processes it as Upon receiving the Group Leaving Request, the Group Manager processes
per Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm].
12. Removal of a Group Member 12. Removal of a Group Member
Other than after a spontaneous request to the Group Manager as Other than after a spontaneous request to the Group Manager as
described in Section 11, a node may be forcibly removed from the described in Section 11, a node may be forcibly removed from the
OSCORE group, e.g. due to expired or revoked authorization. OSCORE group, e.g. due to expired or revoked authorization.
In either case, if the leaving node is not configured exclusively as In either case, if the leaving node is not configured exclusively as
monitor, the Group Manager performs the following actions. monitor, the Group Manager performs the following actions.
o The Group Manager frees the OSCORE Sender ID value of the leaving o The Group Manager frees the OSCORE Sender ID value of the leaving
node, which becomes available for possible upcoming joining nodes. node, which becomes available for possible upcoming joining nodes.
o The Group Manager cancels the association between, on one hand, o The Group Manager cancels the association between, on one hand,
the public key of the leaving node and, on the other hand, the the public key of the leaving node and, on the other hand, the
Group Identifier (Gid) associated to the OSCORE group together Group Identifier (Gid) associated to the OSCORE group together
with the freed OSCORE Sender ID value. The Group Manager deletes with the freed OSCORE Sender ID value. The Group Manager deletes
the public key of the leaving node, if that public key has no the public key of the leaving node, if that public key has no
remaining association with any pair (Group ID, Sender ID). remaining association with any pair (Gid, Sender ID).
If the application requires forward security, the Group Manager MUST If the application requires forward security, the Group Manager MUST
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to the remaining group members (see Section 13). As a provide it to the remaining group members (see Section 13). As a
consequence, the leaving node is not able to acquire the new security consequence, the leaving node is not able to acquire the new security
parameters and group keying material distributed after its leaving. parameters and group keying material distributed after its leaving.
Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
apply here as well, considering the Group Manager acting as KDC. apply here as well, considering the Group Manager acting as KDC.
13. Group Rekeying Process 13. Group Rekeying Process
In order to rekey the OSCORE group, the Group Manager distributes a In order to rekey the OSCORE group, the Group Manager distributes a
new Group ID of the group and a new OSCORE Master Secret for that new Group Identifier (Gid), i.e. a new OSCORE ID Context, and a new
group. When doing so, the Group Manager MUST increment the version OSCORE Master Secret for that group. When doing so, the Group
number of the group keying material. Also, the Group Manager MUST Manager MUST increment the version number of the group keying
preserve the same unchanged Sender IDs for all group members. This material. Also, the Group Manager MUST preserve the same unchanged
avoids affecting the retrieval of public keys from the Group Manager Sender IDs for all group members. This avoids affecting the
as well as the verification of message countersignatures. retrieval of public keys from the Group Manager as well as the
verification of message countersignatures.
The Group Manager MUST support at least the following group rekeying The Group Manager MUST support at least the following group rekeying
scheme. Future application profiles may define alternative message scheme. Future application profiles may define alternative message
formats and distribution schemes. formats and distribution schemes.
The Group Manager uses the same format of the Joining Response The Group Manager uses the same format of the Joining Response
message in Section 4.3. In particular: message in Section 4.4. In particular:
o Only the parameters 'kty', 'key', 'num', 'profile' and 'exp' are o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile'
present. and 'exp' are present.
o The 'ms' parameter of the 'key' parameter specifies the new OSCORE o The 'ms' parameter of the 'key' parameter specifies the new OSCORE
Master Secret value. Master Secret value.
o The 'contextId' parameter of the 'key' parameter specifies the new o The 'contextId' parameter of the 'key' parameter specifies the new
Group ID. Group ID.
The Group Manager separately sends a group rekeying message to each The Group Manager separately sends a group rekeying message to each
group member to be rekeyed. Each rekeying message MUST be secured group member to be rekeyed. Each rekeying message MUST be secured
with the pairwise secure communication channel between the Group with the pairwise secure communication channel between the Group
skipping to change at page 23, line 8 skipping to change at page 20, line 19
the Group Manager. In particular, if a group member and the Group the Group Manager. In particular, if a group member and the Group
Manager use OSCORE [RFC8613] to secure their pairwise communications, Manager use OSCORE [RFC8613] to secure their pairwise communications,
the group member MUST create a Replay Window in its own Recipient the group member MUST create a Replay Window in its own Recipient
Context upon establishing the OSCORE Security Context with the Group Context upon establishing the OSCORE Security Context with the Group
Manager, e.g. by means of the OSCORE profile of ACE Manager, e.g. by means of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
Group members and the Group Manager SHOULD additionally support Group members and the Group Manager SHOULD additionally support
alternative rekeying approaches that do not require group members to alternative rekeying approaches that do not require group members to
act (also) as servers. A number of such approaches are defined in act (also) as servers. A number of such approaches are defined in
Section 4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group
member may subscribe for updates to the group-membership resource of member may subscribe for updates to the group-membership resource of
the group, at the endpoint /group-oscore/NAME of the Group Manager, the group, at the endpoint /group-oscore/GROUPNAME/NODENAME of the
where NAME is the name of the OSCORE group. This can rely on CoAP Group Manager. This can rely on CoAP Observe [RFC7641] or on a full-
Observe [RFC7641] or on a full-fledged Pub-Sub model fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group
[I-D.ietf-core-coap-pubsub] with the Group Manager acting as Broker. Manager acting as Broker.
14. Security Considerations 14. Security Considerations
The method described in this document leverages the following The method described in this document leverages the following
management aspects related to OSCORE groups and discussed in the management aspects related to OSCORE groups and discussed in the
sections of [I-D.ietf-core-oscore-groupcomm] referred below. sections of [I-D.ietf-core-oscore-groupcomm] referred below.
o Management of group keying material (see Section 2.1 of o Management of group keying material (see Section 2.1 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager is [I-D.ietf-core-oscore-groupcomm]). The Group Manager is
responsible for the renewal and re-distribution of the keying responsible for the renewal and re-distribution of the keying
skipping to change at page 23, line 36 skipping to change at page 20, line 47
the group upon changes in its membership. In particular, renewing the group upon changes in its membership. In particular, renewing
the group keying material is required upon a new node's joining or the group keying material is required upon a new node's joining or
a current node's leaving, in case backward security and forward a current node's leaving, in case backward security and forward
security have to be preserved, respectively. security have to be preserved, respectively.
o Provisioning and retrieval of public keys (see Section 2 of o Provisioning and retrieval of public keys (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key
repository of public keys of group members, and provides them upon repository of public keys of group members, and provides them upon
request. request.
o Synchronization of sequence numbers (see Section 5 of o Synchronization of sequence numbers (see Section 5.1 of
[I-D.ietf-core-oscore-groupcomm]). This concerns how a responder [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder
node that has just joined an OSCORE group can synchronize with the node that has just joined an OSCORE group can synchronize with the
sequence number of requesters in the same group. sequence number of requesters in the same group.
Before sending the Joining Response, the Group Manager MUST verify Before sending the Joining Response, the Group Manager MUST verify
that the joining node actually owns the associated private key. To that the joining node actually owns the associated private key. To
this end, the Group Manager can rely on the proof-of-possession this end, the Group Manager can rely on the proof-of-possession
challenge-response defined in Section 4. Alternatively, the joining challenge-response defined in Section 4. Alternatively, the joining
node can use its own public key as asymmetric proof-of-possession key node can use its own public key as asymmetric proof-of-possession key
to establish a secure channel with the Group Manager, e.g. as in to establish a secure channel with the Group Manager, e.g. as in
skipping to change at page 24, line 32 skipping to change at page 21, line 43
Note to RFC Editor: Please replace all occurrences of "[[This Note to RFC Editor: Please replace all occurrences of "[[This
specification]]" with the RFC number of this specification and delete specification]]" with the RFC number of this specification and delete
this paragraph. this paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
15.1. ACE Groupcomm Key Registry 15.1. ACE Groupcomm Key Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 8.3 of [I-D.ietf-ace-key-groupcomm]. Key" Registry defined in Section 8.4 of [I-D.ietf-ace-key-groupcomm].
o Name: Group_OSCORE_Security_Context object o Name: Group_OSCORE_Security_Context object
o Key Type Value: TBD o Key Type Value: TBD
o Profile: "coap_group_oscore_app", defined in Section 15.3 of this o Profile: "coap_group_oscore_app", defined in Section 15.3 of this
specification. specification.
o Description: A Group_OSCORE_Security_Context object encoded as o Description: A Group_OSCORE_Security_Context object encoded as
described in Section 4.3 of this specification. described in Section 4.4 of this specification.
o Reference: [[This specification]] o Reference: [[This specification]]
15.2. OSCORE Security Context Parameters Registry 15.2. OSCORE Security Context Parameters Registry
IANA is asked to register the following entries in the "OSCORE IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" Registry defined in Section 9.2 of Security Context Parameters" Registry defined in Section 9.2 of
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
o Name: cs_alg o Name: cs_alg
skipping to change at page 26, line 8 skipping to change at page 23, line 20
o Registry: ACE Public Key Encoding o Registry: ACE Public Key Encoding
o Description: Encoding of Public Keys to be used with the OSCORE o Description: Encoding of Public Keys to be used with the OSCORE
Counter Signature Algorithm Counter Signature Algorithm
o Reference: [[This specification]] o Reference: [[This specification]]
15.3. ACE Groupcomm Profile Registry 15.3. ACE Groupcomm Profile Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 8.4 of Profile" Registry defined in Section 8.5 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: coap_group_oscore_app o Name: coap_group_oscore_app
o Description: Application profile to provision keying material for o Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm]. as per [I-D.ietf-core-oscore-groupcomm].
o CBOR Value: TBD o CBOR Value: TBD
o Reference: [[This specification]] o Reference: [[This specification]]
15.4. Sequence Number Synchronization Method Registry 15.4. Sequence Number Synchronization Method Registry
IANA is asked to register the following entries in the "Sequence IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 8.6 of Number Synchronization Method" Registry defined in Section 8.7 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: Best effort o Name: Best effort
o Value: 1 o Value: 1
o Description: No action is taken. o Description: No action is taken.
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1). o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1).
skipping to change at page 27, line 8 skipping to change at page 24, line 22
o Value: 3 o Value: 3
o Description: Challenge response using the Echo Option for CoAP o Description: Challenge response using the Echo Option for CoAP
from [I-D.ietf-core-echo-request-tag]. from [I-D.ietf-core-echo-request-tag].
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3). o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3).
15.5. ACE Groupcomm Parameters Registry 15.5. ACE Groupcomm Parameters Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Parameters" Registry defined in Section 8.2 of Parameters" Registry defined in Section 8.3 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: clientId o Name: clientId
o CBOR Key: TBD o CBOR Key: TBD
o CBOR Type: Byte string o CBOR Type: Byte string
o Reference: [[This document]] (Section 7). o Reference: [[This document]] (Section 7).
skipping to change at page 27, line 31 skipping to change at page 24, line 45
16.1. Normative References 16.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-key-groupcomm] [I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-ietf-ace-key-groupcomm-03 Communication using ACE", draft-ietf-ace-key-groupcomm-04
(work in progress), November 2019. (work in progress), January 2020.
[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-25 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-30
(work in progress), October 2019. (work in progress), January 2020.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-08 (work in progress), July 2019. oscore-profile-08 (work in progress), July 2019.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-05 (work in progress), draft-ietf-core-oscore-groupcomm-06 (work in progress),
July 2019. November 2019.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Resource Identifier (URI): Generic Syntax", STD 66, Key Derivation Function (HKDF)", RFC 5869,
RFC 3986, DOI 10.17487/RFC3986, January 2005, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
16.2. Informative References 16.2. Informative References
[I-D.dijk-core-groupcomm-bis] [I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-01 (work in progress), July 2019. dijk-core-groupcomm-bis-02 (work in progress), November
2019.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-08 (work in progress), April 2019. authorize-09 (work in progress), December 2019.
[I-D.ietf-ace-mqtt-tls-profile]
Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in
progress), December 2019.
[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-09 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), September 2019. progress), September 2019.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-08 (work in progress), November 2019. request-tag-08 (work in progress), November 2019.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca- Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-03 (work in progress), July 2019. core-oscore-discovery-04 (work in progress), November
2019.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
Appendix A. Profile Requirements Appendix A. Profile Requirements
This appendix lists the specifications on this application profile of This appendix lists the specifications on this application profile of
ACE, based on the requiremens defined in Appendix A of ACE, based on the requiremens defined in Appendix A of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o REQ1 - Specify the encoding and value of the identifier of group o REQ1 - Specify the encoding and value of the identifier of group
of 'scope': see Section 3.1. of 'scope': see Section 3.1.
o REQ2 - Specify the encoding and value of the identifier of roles o REQ2 - Specify the encoding and value of the identifier of roles
of 'scope': see Section 3.1. of 'scope': see Section 3.1.
o REQ3 (Optional) - Specify the acceptable values for 'sign_alg': o REQ3 - if used, specify the acceptable values for 'sign_alg':
values from Tables 5 and 6 of [RFC8152]. values from Tables 5 and 6 of [RFC8152].
o REQ4 (Optional) - Specify the acceptable values for o REQ4 - If used, specify the acceptable values for
'sign_parameters': values from the "Counter Signature Parameters" 'sign_parameters': values from the "Counter Signature Parameters"
Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).
o REQ5 (Optional) - Specify the acceptable values for o REQ5 - If used, specify the acceptable values for
'sign_key_parameters': values from the "Counter Signature Key 'sign_key_parameters': values from the "Counter Signature Key
Parameters" Registry (see Section 9.2 of Parameters" Registry (see Section 9.2 of
[I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
o REQ6 (Optional) - Specify the acceptable values for 'pub_key_enc': o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1
1 ("COSE_Key") from the 'Confirmation Key' column of the "CWT ("COSE_Key") from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in Confirmation Method" Registry defined in
[I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may
define additional values for this parameter. define additional values for this parameter.
o REQ7 - Format of the 'key' value: see Section 4.3. o REQ7 - Format of the 'key' value: see Section 4.4.
o REQ8 - Acceptable values of 'kty': Group_OSCORE_Security_Context o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context
object (see Section 4.3). object (see Section 4.4).
o REQ9: Specify the format of the identifiers of group members: see o REQ9: Specify the format of the identifiers of group members: see
Section 4.3 and Section 8. Section 4.4 and Section 8.
o REQ10 (Optional) - Specify the format and content of
'group_policies' entries: three values are defined and registered,
as content of the entry "Sequence Number Synchronization Method"
(see Section 15.4).
o REQ11 - Communication protocol that the members of the group must
use: CoAP, possibly over IP multicast.
o REQ12 - Security protocols that the group members must use to o REQ10 - Specify the communication protocol that the members of the
protect their communication: Group OSCORE. group must use: CoAP, possibly over IP multicast.
o REQ13 - Profile identifier: coap_group_oscore_app o REQ11 - Specify the security protocols that the group members must
use to protect their communication: Group OSCORE.
o REQ14 (Optional) - Specify the encoding of public keys, of o REQ12 - Specify and register the application profile identifier:
'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. coap_group_oscore_app (see Section 15.3).
o REQ15 - Specify policies at the KDC to handle member ids that are o REQ13 - Specify policies at the KDC to handle member ids that are
not included in 'get_pub_keys': see Section 8. not included in 'get_pub_keys': see Section 8.
o REQ16 - Specify the format and content of 'group_policies': see o REQ14 - If used, specify the format and content of
Section 4.3. 'group_policies' and its entries: see Section 4.4, and the three
values defined and registered, as content of the entry "Sequence
Number Synchronization Method" (see Section 15.4).
o REQ17 - Specify the format of newly-generated individual keying o REQ15 - Specify the format of newly-generated individual keying
material for group members, or of the information to derive it, material for group members, or of the information to derive it,
and corresponding CBOR label: see Section 7. and corresponding CBOR label: see Section 7.
o REQ18 - Specify how the communication is secured between the o REQ16 - Specify how the communication is secured between the
Client and KDC: by means of any transport profile of ACE Client and KDC: by means of any transport profile of ACE
[I-D.ietf-ace-oauth-authz] between Client and Group Manager that [I-D.ietf-ace-oauth-authz] between Client and Group Manager that
complies with the requirements in Appendix C of complies with the requirements in Appendix C of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
o REQ17: Specify how the nonce N_S is generated, if the token is not
being posted (e.g. if it is used directly to validate TLS
instead): see Section 4.2.1.
o REQ18: Specify if 'mgt_key_material' used, and if yes specify its
format and content: not used in this version of the profile.
o OPT1 (Optional) - Specify the encoding of public keys, of o OPT1 (Optional) - Specify the encoding of public keys, of
'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no.
o OPT2 (Optional) - Specify the negotiation of parameter values for o OPT2 (Optional) - Specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' and signature algorithm and signature keys, if 'sign_info' and
'pub_key_enc' are not used: possible early discovery by using the 'pub_key_enc' are not used: possible early discovery by using the
approach based on the CoRE Resource Directory described in approach based on the CoRE Resource Directory described in
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
o OPT3 (Optional) - Specify the format and content of o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the
'mgt_key_material': no. default is not used: no.
o OPT4 (Optional) - Specify policies that instruct clients to retain o OPT4 (Optional) - Specify policies that instruct clients to retain
unsuccessfully decrypted messages and for how long, so that they unsuccessfully decrypted messages and for how long, so that they
can be decrypted after getting updated keying material: no. can be decrypted after getting updated keying material: no.
o OPT5 (Optional) - Specify the behavior of the handler in case of
failure to retrieve a public key for the specific node: send a
4.00 Bad Request response to a Joining Request (see Section 4.3).
o OPT6 (Optional) - Specify possible or required payload formats for
specific error cases: send a 4.00 Bad Request response to a
Joining Request (see Section 4.3).
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -02 to -03 B.1. Version -03 to -04
o New abstract.
o Moved general content to draft-ietf-ace-key-groupcomm
o Terminology: node name; node resource.
o Creation and pointing at node resource.
o Updated Group Manager API (REST methods and offered services).
o Size of challenges 'cnonce' and 'rsnonce'.
o Value of 'rsnonce' for reused or non-traditionally-posted tokens.
o Removed reference to RFC 7390.
o New requirements from draft-ietf-ace-key-groupcomm
o Editorial improvements.
B.2. Version -02 to -03
o New sections, aligned with the interface of ace-key-groupcomm . o New sections, aligned with the interface of ace-key-groupcomm .
o Exchange of information on the countersignature algorithm and o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 4.1). related parameters, during the Token POST (Section 4.1).
o Nonce 'rsnonce' from the Group Manager to the Client o Nonce 'rsnonce' from the Group Manager to the Client
(Section 4.1). (Section 4.1).
o Client PoP signature in the Key Distribution Request upon joining o Client PoP signature in the Key Distribution Request upon joining
skipping to change at page 32, line 5 skipping to change at page 30, line 18
o Local actions on the Group Manager, upon a new node's joining o Local actions on the Group Manager, upon a new node's joining
(Section 4.2). (Section 4.2).
o Local actions on the Group Manager, upon a node's leaving o Local actions on the Group Manager, upon a node's leaving
(Section 12). (Section 12).
o IANA registration in ACE Groupcomm Parameters Registry. o IANA registration in ACE Groupcomm Parameters Registry.
o More fulfilled profile requirements (Appendix A). o More fulfilled profile requirements (Appendix A).
B.2. Version -01 to -02 B.3. Version -01 to -02
o Editorial fixes. o Editorial fixes.
o Changed: "listener" to "responder"; "pure listener" to "monitor". o Changed: "listener" to "responder"; "pure listener" to "monitor".
o Changed profile name to "coap_group_oscore_app", to reflect it is o Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile. an application profile.
o Added the 'type' parameter for all requests to a Join Resource. o Added the 'type' parameter for all requests to a Join Resource.
skipping to change at page 32, line 43 skipping to change at page 31, line 8
o Extended security considerations: proof-of-possession of signature o Extended security considerations: proof-of-possession of signature
keys; collision of OSCORE Group Identifiers (Section 8). keys; collision of OSCORE Group Identifiers (Section 8).
o Registered three entries in the IANA Registry "Sequence Number o Registered three entries in the IANA Registry "Sequence Number
Synchronization Method Registry" (Section 9). Synchronization Method Registry" (Section 9).
o Registered one public key encoding in the "ACE Public Key o Registered one public key encoding in the "ACE Public Key
Encoding" IANA Registry (Section 9). Encoding" IANA Registry (Section 9).
B.3. Version -00 to -01 B.4. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
o Added negotiation of countersignature algorithm/parameters between o Added negotiation of countersignature algorithm/parameters between
Client and Group Manager (Section 4). Client and Group Manager (Section 4).
o Updated format of the Key Distribution Response as a whole o Updated format of the Key Distribution Response as a whole
(Section 4.3). (Section 4.3).
 End of changes. 134 change blocks. 
597 lines changed or deleted 500 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/