Draft: draft-ietf-core-oscore-groupcomm

Commentary: By Appendix A - I think there may be a problem with the term " member of a group " between this document and draft - dijk - core - groupcomm . This document includes all clients , while that document only incudes the servers . This may cause future problems . 
 By Section 3.1.1 - The MAY include does not appear to match the CDDL structure below - which is correct ? 
 By Section 3.1 - s / is extended as follows / is built differently./ From the current sentence , I expected the as follows to be in the next sentence . 
 by Section 2.2 - remove /including a Partial IV/ from the second paragraph . A better answer would be /for that group/ 
 by Section 2.1 - I am wondering if this section should contain some information about how a client / server should handle key material in the event of a roll over . 
 By Section 2.1 - If I do n't distribute a master salt - does that mean the old value is absent or kept ? Working is a little bit ambiguous . 
 By Section 1 - In the last paragraph you might want to mention that using DTLS for doing hop - by - hop protection protects the routing information of the packet from observers . 
 By In section 8.4 it might be useful to distinguish between two different instances of the first case . There is a difference between a server which receives a message using an old context , which it makes more sense to ignore and a client receiving a response from a server that is using the same context as the request was sent in . It makes more sense to hang onto the context in the second case than in the first case . There is also a question of should the server respond in a different context than the response was in . That point also should be clarified . 
 by In working through all of the roll over cases I am dealing with , I have a question . The key identifier is a required field in all response messages . Is the group identifier a required field in all response messages or is it only required under certain circumstances ? The circumstances would be if the key context is not the same as the ( original ? ) request . Not too sure what the answer is going to be if you are looking at a sequence of observe responses where you would really like to stop sending the group identifier if it is not needed any more .
This document describes a mode for protecting group communication
over the Constrained Application Protocol (CoAP).  The proposed mode
relies on Object Security for Constrained RESTful Environments
(OSCORE) and the CBOR Object Signing and Encryption (COSE) format.
In particular, it defines how OSCORE is used in a group communication
setting, while fulfilling the same security requirements for group
requests and responses.  Source authentication of all messages
exchanged within the group is provided by means of digital signatures
produced by the sender and embedded in the protected CoAP messages.
The Constrained Application Protocol (CoAP) RFC7252 is a web transfer
protocol specifically designed for constrained devices and networks
RFC7228.
Group communication for CoAP I-D.dijk-core-groupcomm-bis addresses
use cases where deployed devices benefit from a group communication
model, for example to reduce latencies, improve performance and
reduce bandwidth utilisation.  Use cases include lighting control,
integrated building control, software and firmware updates, parameter
and configuration updates, commissioning of constrained networks, and
emergency multicast (see sec-use-cases).  Furthermore, RFC7390
recognizes the importance to introduce a secure mode for CoAP group
communication.  This specification defines such a mode.
Object Security for Constrained RESTful Environments (OSCORE) RFC8613
describes a security protocol based on the exchange of protected CoAP
messages.  OSCORE builds on CBOR Object Signing and Encryption (COSE)
RFC8152 and provides end-to-end encryption, integrity, replay
protection and binding of response to request between a sender and a
receipient, also in the presence of intermediaries.  To this end, a
CoAP message is protected by including its payload (if any), certain
options, and header fields in a COSE object, which replaces the
authenticated and encrypted fields in the protected message.
This document defines Group OSCORE, providing end-to-end security of
CoAP messages exchanged between members of a group, and preserving
independence of transport layer.  In particular, the described
approach defines how OSCORE should be used in a group communication
setting, so that end-to-end security is assured in the same way as
OSCORE for unicast communication.  That is, end-to-end security is
provided for CoAP multicast requests sent by a client to the group,
and for related CoAP responses sent by multiple servers.  Group
OSCORE provides source authentication of all CoAP messages exchanged
within the group, by means of digital signatures produced through
private keys of sender devices and embedded in the protected CoAP
messages.
As defined in the latest I-D.dijk-core-groupcomm-bis, Group OSCORE is
the security protocol to use for applications that rely on CoAP group
communication.  As in OSCORE, it is still possible to simultaneously
rely on DTLS RFC6347 to protect hop-by-hop communication between a
sender and a proxy (and vice versa), and between a proxy and a
recipient (and vice versa).  Note that DTLS cannot be used to secure
messages sent over multicast.
This document defines Group Object Security for Constrained RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g. using IP
multicast.  In particular, the described approach defines how OSCORE
should be used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and the corresponding CoAP responses.
The Constrained Application Protocol (CoAP) RFC7252 is a web transfer
protocol specifically designed for constrained devices and networks
RFC7228.  Group communication for CoAP I-D.dijk-core-groupcomm-bis
addresses use cases where deployed devices benefit from a group
communication model, for example to reduce latencies, improve
performance and reduce bandwidth utilization.  Use cases include
lighting control, integrated building control, software and firmware
updates, parameter and configuration updates, commissioning of
constrained networks, and emergency multicast (see sec-use-cases).
This specification defines the security protocol for Group
communication for CoAP I-D.dijk-core-groupcomm-bis.
Object Security for Constrained RESTful Environments (OSCORE) RFC8613
describes a security protocol based on the exchange of protected CoAP
messages.  OSCORE builds on CBOR Object Signing and Encryption (COSE)
RFC8152 and provides end-to-end encryption, integrity, replay
protection and binding of response to request between a sender and a
recipient, independent of transport also in the presence of
intermediaries.  To this end, a CoAP message is protected by
including its payload (if any), certain options, and header fields in
a COSE object, which replaces the authenticated and encrypted fields
in the protected message.
This document defines Group OSCORE, providing the same end-to-end
security properties as OSCORE in the case where CoAP requests have
multiple recipients.  In particular, the described approach defines
how OSCORE should be used in a group communication setting to provide
source authentication for CoAP group requests, sent by a client to
multiple servers, and the corresponding CoAP responses.
Group OSCORE provides source authentication of CoAP requests by means
of digital signatures produced with the private key of the client and
embedded in the protected CoAP messages.  CoAP responses from the
server may be digitally signed by the private key of the server or
integrity protected with a symmetric key derived from a pairwise
security context derived from client and server asymmetric keys.
Just like OSCORE, Group OSCORE is independent of transport layer and
works wherever CoAP does.  Group communication for CoAP I-D.dijk-
core-groupcomm-bis uses UDP/IP multicast as the underlying data
transport.
As with OSCORE, it is possible to combine Group OSCORE with
communication security on other layers.  One example is the use of
transport layer security, such as DTLS RFC6347, between one client
and one proxy (and vice versa), or between one proxy and one server
(and vice versa), in order to protect the routing information of
packets from observers.  Note that DTLS cannot be used to secure
messages sent over IP multicast.
In the signature mode, Group OSCORE requests and responses are
digitally signed.  The signature mode supports all COSE algorithms
as well as signature verification by intermediaries.
The pairwise mode allows two group members to exchange (unicast)
OSCORE requests and responses protected with symmetric keys.
These symmetric keys are derived from Diffie-Hellman shared
secrets, calculated with the asymmetric keys of the two group
members.  This allows for shorter integrity tags and therefore
lower message overhead.
In the (hybrid) optimized mode, the CoAP requests are digitally
signed as in the signature mode, and the CoAP responses are
integrity protected with the symmetric key of the pairwise mode.
The signature and optimized modes are detailed in the body of this
document.  The pairwise mode is detailed in sec-pairwise-protection.
Unless otherwise stated, this specification refers to the signature
mode.
Group: a set of endpoints that share group keying material and
security parameters (Common Context, see sec-context).  The term
group used in this specification refers thus to a "security
group", not to be confused with network/multicast group or
application group.
Group: a set of endpoints that share group keying material and
security parameters (Common Context, see sec-context).  Unless
specified otherwise, the term group used in this specification
refers thus to a "security group", not to be confused with
CoAP/network/multicast group or application group.
Silent server: member of a group that never responds to requests.
Note that a silent server can act as a client, the two roles are
independent.
Silent server: member of a group that never responds to requests.
Note that an endpoint can implement both a silent server and a
client, the two roles are independent.
The ID Context parameter contains the Gid of the group, which
is used to retrieve the Security Context for processing
messages intended to the endpoints of the group (see mess-
processing).  The choice of the Gid is application specific.
An example of specific formatting of the Gid is given in gid-
ex.  The application needs to specify how to handle possible
collisions between Gids, see ssec-gid-collision.
A new parameter Counter Signature Algorithm is included.  Its
value identifies the digital signature algorithm used to
compute a counter signature on the COSE object (see Section 4.5
of RFC8152) which provides source authentication within the
group.  Its value is immutable once the Common Context is
established.  The used Counter Signature Algorithm MUST be
selected among the signing ones defined in the COSE Algorithms
Registry (see section 16.4 of RFC8152).  The EdDSA signature
algorithm ed25519 RFC8032 is mandatory to implement.  If
Elliptic Curve Digital Signature Algorithm (ECDSA) is used, it
is RECOMMENDED that implementations implement "deterministic
ECDSA" as specified in RFC6979.
A new parameter Counter Signature Parameters is included.  This
parameter identifies the parameters associated to the digital
signature algorithm specified in the Counter Signature
Algorithm.  This parameter MAY be empty and is immutable once
the Common Context is established.  The exact structure of this
parameter depends on the value of Counter Signature Algorithm,
and is defined in the Counter Signature Parameters Registry
(see iana-cons-cs-params), where each entry indicates a
specified structure of the Counter Signature Parameters.
A new parameter Counter Signature Key Parameters is included.
This parameter identifies the parameters associated to the keys
used with the digital signature algorithm specified in the
Counter Signature Algorithm.  This parameter MAY be empty and
is immutable once the Common Context is established.  The exact
structure of this parameter depends on the value of Counter
Signature Algorithm, and is defined in the Counter Signature
Key Parameters Registry (see iana-cons-cs-key-params), where
each entry indicates a specified structure of the Counter
Signature Key Parameters.
one Sender Context, unless the endpoint is configured exclusively
as silent server.  The Sender Context is used to secure outgoing
messages and is initialized according to Section 3 of RFC8613,
once the endpoint has joined the group.  The Sender Context of a
given endpoint matches the corresponding Recipient Context in all
the endpoints receiving a protected message from that endpoint.
Besides, in addition to what is defined in RFC8613, the Sender
Context stores also the endpoint's private key.
one Recipient Context for each distinct endpoint from which
messages are received, used to process incoming messages.  The
recipient may generate a Recipient Context whenever in possession
of all the required pieces of information on the corresponding
endpoint, e.g. they may be provided to the recipient upon joining
the group.  Alternatively, the recipient may generate a Recipient
Context upon receiving an incoming message from another endpoint
in the group for the first time (see ssec-verify-request and ssec-
verify-response).  Each Recipient Context matches the Sender
Context of the endpoint from which protected messages are
received.  Besides, in addition to what is defined in RFC8613,
each Recipient Context stores also the public key of the
associated other endpoint from which messages are received.  Note
that each Recipient Context includes a Replay Window, unless the
recipient acts only as client and hence processes only responses
as incoming messages.
The table in fig-additional-context-information overviews the new
information included in the OSCORE Security Context, with respect to
what defined in Section 3 of RFC8613.
Upon receiving a secure CoAP message, a recipient uses the sender's
public key, in order to verify the counter signature of the COSE
Object (see sec-cose-object).
If not already stored in the Recipient Context associated to the
sender, the recipient retrieves the sender's public key from the
Group Manager, which collects public keys upon endpoints' joining the
group, acts as trusted key repository and ensures the correct
association between the public key and the identifier of the sender,
for instance by means of public key certificates.
For very constrained devices, it may be not feasible to
simultaneously handle the ongoing processing of a just received
message and the parallel retrieval of the sender's public key.  Such
devices can be configured to drop that received message altogether,
switch to the retrieval of the sender's public key, and thus have it
available to verify following messages from that sender.
Note that a group member can retrieve public keys from the Group
Manager and generate the Recipient Context associated to another
group member at any point in time, as long as this is done before
verifying a received secure CoAP message.  The exact configuration is
application dependent.  For example, an application can configure a
group member to retrieve all the required information and to create
the Recipient Context exactly upon receiving a message from another
group member for the first time.  As an alternative, the application
can configure a group member to asynchronously retrieve the required
information and update its list of Recipient Contexts well before
receiving any message, e.g. by Observing RFC7641 the Group Manager to
get updates on the group membership.
It is RECOMMENDED that the Group Manager collects public keys and
provides them to group members upon request as described in I-D.ietf-
ace-key-groupcomm-oscore, where the join process is based on the ACE
framework for Authentication and Authorization in constrained
environments I-D.ietf-ace-oauth-authz.  Further details about how
public keys can be handled and retrieved in the group is out of the
scope of this document.
An endpoint receives its own Sender ID from the Group Manager upon
joining the group.  That Sender ID is valid only within that group,
and is unique within the group.  An endpoint uses its own Sender ID
(together with other data) to generate unique AEAD nonces for
outgoing messages, as in RFC8613.  Endpoints which are configured
only as silent servers do not have a Sender ID.
The Sender/Recipient Keys and the Common IV are derived according to
the same scheme defined in Section 3.2 of RFC8613.  The mandatory-to-
implement HKDF and AEAD algorithms for Group OSCORE are the same as
in RFC8613.
In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed.  When doing so, a new value for the
Master Salt parameter MAY also be distributed, and the Group Manager
SHOULD preserve the current value of the Sender ID of each group
member.  An example of Gid format supporting this operation is
provided in gid-ex.  Then, each group member re-derives the keying
material stored in its own Sender Context and Recipient Contexts as
described in sec-context, using the updated Gid.
After a new Gid has been distributed, a same Recipient ID ('kid')
should not be considered as a persistent and reliable indicator of
the same group member.  Such an indication can be actually achieved
only by verifying countersignatures of received messages.
As a consequence, group members may end up retaining stale Recipient
Contexts, that are no longer useful to verify incoming secure
messages.  Applications may define policies to delete (long-)unused
Recipient Contexts and reduce the impact on storage space.
If the application requires so (see ssec-sec-assumptions), it is
RECOMMENDED to adopt a group key management scheme, and securely
distribute a new value for the Gid and for the Master Secret
parameter of the group's Security Context, before a new joining
endpoint is added to the group or after a currently present endpoint
leaves the group.  This is necessary to preserve backward security
and forward security in the group, if the application requires it.
One Common Context, shared by all the endpoints in the group.
Three new parameters are included in the Common Context: Counter
Signature Algorithm, Counter Signature Parameters and Counter
Signature Key Parameters.
One Sender Context, extended with the endpoint's private key.  The
Sender Context is omitted if the endpoint is configured
exclusively as silent server.
One Recipient Context for each endpoint from which messages are
received.  The Recipient Context is extended with the public key
of the associated endpoint.
The ID Context parameter (see Sections 3.3 and 5.1 of RFC8613) in the
Common Context SHALL contain the Group Identifier (Gid) of the group.
The choice of the Gid is application specific.  An example of
specific formatting of the Gid is given in gid-ex.  The application
needs to specify how to handle possible collisions between Gids, see
ssec-gid-collision.
The Counter Signature Algorithm identifies the digital signature
algorithm used to compute a counter signature on the COSE object (see
Section 4.5 of RFC8152).  Its value is immutable once the Common
Context is established.  The used Counter Signature Algorithm MUST be
selected among the signing ones defined in the COSE Algorithms
Registry (see section 16.4 of RFC8152).  The EdDSA signature
algorithm Ed25519 RFC8032 is mandatory to implement.  If Elliptic
Curve Digital Signature Algorithm (ECDSA) is used, it is RECOMMENDED
that implementations implement "deterministic ECDSA" as specified in
RFC6979.
The Counter Signature Parameters identifies the parameters associated
to the digital signature algorithm specified in the Counter Signature
Algorithm.  This parameter MAY be empty and is immutable once the
Common Context is established.  The exact structure of this parameter
depends on the value of Counter Signature Algorithm, and is defined
in the Counter Signature Parameters Registry (see iana-cons-cs-
params), where each entry indicates a specified structure of the
Counter Signature Parameters.
The Counter Signature Key Parameters identifies the parameters
associated to the keys used with the digital signature algorithm
specified in the Counter Signature Algorithm.  This parameter MAY be
empty and is immutable once the Common Context is established.  The
exact structure of this parameter depends on the value of Counter
Signature Algorithm, and is defined in the Counter Signature Key
Parameters Registry (see iana-cons-cs-key-params), where each entry
indicates a specified structure of the Counter Signature Key
Parameters.
OSCORE specifies the derivation of Sender Context and Recipient
Context, specifically Sender/Recipient Keys and Common IV, from a set
of input parameters (see Section 3.2 of RFC8613).  This derivation
applies also to Group OSCORE, and the mandatory-to-implement HKDF and
AEAD algorithms are the same as in RFC8613.  However, for Group
OSCORE the Sender Context and Recipient Context additionally contain
asymmetric keys.
The Sender Context needs to be configured with the private key of the
endpoint.  The private key is used to generate a signature (see sec-
cose-object) included in the sent OSCORE message.  How the private
key is established is out of scope for this specification.
Each Recipient Context needs to be configured with the public key of
the associated endpoint.  The public key is used to verify a
signature (see sec-cose-object) included in the received OSCORE
message.
The input parameters for deriving the Recipient Context parameters
and the public key of the associated endpoint may be provided to the
recipient endpoint upon joining the group.  These parameters may
alternatively be acquired at a later time, for example the first time
a message is received from this particular endpoint in the group (see
ssec-verify-request and ssec-verify-response).  The received message
together with the Common Context contains the necessary information
to derive a security context for verifying a message, except for the
public key of the associated endpoint.
For severely constrained devices, it may be not feasible to
simultaneously handle the ongoing processing of a recently received
message in parallel with the retrieval of the associated endpoint's
public key.  Such devices can be configured to drop a received
message for which there is no Recipient Context, and instead retrieve
the public key in order to have it available to verify subsequent
messages from that endpoint.
Note that each Recipient Context includes a Replay Window, unless the
recipient acts only as client and hence processes only responses as
incoming messages.
Endpoints communicating with Group OSCORE need, in addition to the
OSCORE input parameters, also to be provisioned with information
about the group(s) and other endpoints in the group(s).
The Group Manager is an entity responsible for the group, including
the Group Identifier (Gid), as well as Sender ID and Recipient ID of
the group members (see sec-group-manager).  The Group Manager records
the public keys of endpoints joining the group and provides
information about the group and its members to other members.
An endpoint receives the Group Identifier and OSCORE input
parameters, including its own Sender ID, from the Group Manager upon
joining the group.  That Sender ID is valid only within that group,
and is unique within the group.  Endpoints which are configured only
as silent servers do not have a Sender ID.
A group member can retrieve public keys and other information
associated to another group member from the Group Manager, from which
it can generate the Recipient Context.  An application can configure
a group member to asynchronously retrieve information about Recipient
Contexts, e.g. by Observing RFC7641 the Group Manager to get updates
on the group membership.
According to this specification, it is RECOMMENDED to use a Group
Manager as described in I-D.ietf-ace-key-groupcomm-oscore, where the
join process is based on the ACE framework for authentication and
authorization in constrained environments I-D.ietf-ace-oauth-authz.
Further details about how public keys can be handled and retrieved in
the group is out of the scope of this document.
In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed.  An example of Gid format supporting
this operation is provided in gid-ex.  When distributing the new Gid
and Master Secret, the Group Manager MAY distribute also a new value
for the Master Salt parameter, and SHOULD preserve the current value
of the Sender ID of each group member.
Then, each group member re-derives the keying material stored in its
own Sender Context and Recipient Contexts as described in sec-
context, using the updated Gid and Master Secret parameter.  The
Master Salt used for the re-derivations is the updated Master Salt
parameter if provided by the Group Manager, or the empty byte string
otherwise.  From then on, each group member MUST use its latest
installed Sender Context to protect outgoing messages.
After a new Gid has been distributed, a same Recipient ID ('kid')
should not be considered as a persistent and reliable indicator of
the same group member.  Such an indication can be actually achieved
only by verifying countersignatures of received messages.  As a
consequence, group members may end up retaining stale Recipient
Contexts, that are no longer useful to verify incoming secure
messages.  Applications may define policies to delete (long-)unused
Recipient Contexts and reduce the impact on storage space.
The distribution of a new Gid and Master Secret may result in
temporarily misaligned Security Contexts among group members.  In
particular, this may result in a group member not able to process
messages received right after a new Gid and Master Secret have been
distributed.  A discussion on practical consequences and possible
ways to address them is provided in ssec-key-rotation.
If required by the application (see ssec-sec-assumptions), it is
RECOMMENDED to adopt a group key management scheme, and securely
distribute a new value for the Gid and for the Master Secret
parameter of the group's Security Context, before a new joining
endpoint is added to the group or after a currently present endpoint
leaves the group.  This is necessary to preserve backward security
and forward security in the group, if the application requires it.
When a wrap-around happens, the endpoint MUST NOT transmit further
messages including a Partial IV until it has derived a new Sender
Context, in order to avoid reusing nonces with the same keys.
The Group Manager renews the OSCORE Security Context in the group
(see sec-group-key-management).
Either case, same considerations from sec-group-key-management hold
about possible retaining of stale Recipient Contexts.
Building on Section 5 of RFC8613, this section defines how to use
COSE RFC8152 to wrap and protect data in the original message.
OSCORE uses the untagged COSE_Encrypt0 structure with an
Authenticated Encryption with Associated Data (AEAD) algorithm.  For
Group OSCORE, the following modifications apply.
The external_aad of the Additional Authenticated Data (AAD) is
extended as follows.  In particular, it has one structure used for
the encryption process producing the ciphertext, and one structure
used for the signing process producing the counter signature.
When a wrap-around happens, the endpoint MUST NOT transmit further
messages for that group until it has derived a new Sender Context, in
order to avoid reusing nonces with the same keys.
The Group Manager renews the Security Context in the group (see
sec-group-key-management).
In either case, same considerations from sec-group-key-management
hold about possible retaining of stale Recipient Contexts.
Certain signature schemes, such as EdDSA and ECDSA, support a secure
combined signature and encryption scheme.  This section specifies the
derivation of pairwise encryption keys for use in the pairwise and
optimized modes of Group OSCORE.
Two group members can derive a symmetric pairwise key, from their
Sender/Recipient Key and a static-static Diffe-Hellman shared secret.
The key derivation is as follows, and uses the same construction used
in Section 3.2.1 of RFC8613.
The Sender/Recipient key is the Sender Key of the sender, i.e. the
Recipient Key that the recipient stores in its own Recipient
Context corresponding to the sender.
The Shared Secret is computed as a static-static Diffie-Hellman
shared secret, where the sender uses its own private key and the
recipient's public key, while the recipient uses its own private
key and the senders's public key.
info and L are defined as in Section 3.2.1 of RFC8613.
The security of using the same key pair for Diffie-Hellman and for
signing is proven in Degabriele.  The derivation of pairwise keys
defined above is compatible with ECDSA and EdDSA asymmetric keys, but
is not compatible with RSA asymmetric keys.
If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
4.2 of RFC7748, before using the X25519 and X448 functions defined in
Section 5 of RFC7748.
In order to optimize performance, an endpoint A may derive a pairwise
key used with an endpoint B in the OSCORE group only once, and then
store it in its own Security Context for future retrieval.  This can
work as follows.
The Recipient ID of B for A, i.e. the Sender ID of B.
The Pairwise Key derived as defined in sec-derivation-pairwise,
with A acting as sender and B acting as recipient.
More generally, A has one of such Paiwise Sender Contexts within its
own Sender Context, for each different intended recipient.
Furthermore, A can additionally store in its own Recipient Context
associated to B the Pairwise Key to use for incoming traffic from B.
That is, this Pairwise Key is derived as defined in sec-derivation-
pairwise, with A acting as recipient and B acting as sender.
Building on Section 5 of RFC8613, this section defines how to use
COSE RFC8152 to wrap and protect data in the original message.
OSCORE uses the untagged COSE_Encrypt0 structure with an
Authenticated Encryption with Associated Data (AEAD) algorithm.  For
the signature mode of Group OSCORE the following modifications apply.
CounterSignature0 : its value is set to the counter signature of
the COSE object, computed by the sender as described in
Appendix A.2 of RFC8152, by using its own private key and
according to the Counter Signature Algorithm and Counter Signature
Parameters in the Security Context.  In particular, the
Sig_structure contains the external_aad as defined in sec-cose-
object-ext-aad-sign and the ciphertext of the COSE_Encrypt0 object
as payload.
The value of the 'kid context' parameter in the 'unprotected' field
of requests messages MUST be set to the ID Context, i.e. the Group
Identifier value (Gid) of the group's Security Context.  That is,
unlike in RFC8613, the 'kid context' parameter is always present in
requests.
The external_aad of the Additional Authenticated Data (AAD) is built
differently.  In particular, it has one structure used for the
encryption process producing the ciphertext, and one structure used
for the signing process producing the counter signature.
CounterSignature0 : its value is set to the counter signature of
the COSE object, computed by the sender using its own private key
as described in Appendix A.2 of RFC8152.  In particular, the
Sig_structure contains the external_aad as defined in sec-cose-
object-ext-aad-sign and the ciphertext of the COSE_Encrypt0 object
as payload.
The OSCORE compression defined in Section 6 of RFC8613 is used, with
the following additions for the encoding of the OSCORE Option and the
OSCORE Payload.
The fourth least significant bit MUST be set to 1 in every
message, to indicate the presence of the 'kid' parameter for
all group requests and responses.  That is, unlike in RFC8613,
the 'kid' parameter is always present in all messages.
The fifth least significant bit MUST be set to 1 for group
requests, to indicate the presence of the 'kid context'
parameter in the compressed COSE object.  The 'kid context' MAY
be present in responses if the application requires it.  In
such a case, the kid context flag MUST be set to 1.
The flag bits are registered in the OSCORE Flag Bits registry
specified in Section 13.7 of RFC8613.
The 'kid context' value encodes the Group Identifier value (Gid)
of the group's Security Context.
The remaining bytes in the OSCORE Option value encode the value of
the 'kid' parameter, which is always present both in group
requests and in responses.
The payload of the OSCORE message SHALL encode the ciphertext of the
COSE object concatenated with the value of the CounterSignature0 of
the COSE object, computed as in Appendix A.2 of RFC8152 according to
the Counter Signature Algorithm and Counter Signature Parameters in
the Security Context.
The OSCORE header compression defined in Section 6 of RFC8613 is
used, with the following differences.
The payload of the OSCORE message SHALL encode the ciphertext of
the COSE object concatenated with the value of the
CounterSignature0 of the COSE object, computed as described in
sec-cose-object-unprotected-field.
This specification defines the usage of the sixth least
significant bit, namely the Pairwise Flag bit, in the first byte
of the OSCORE option containing the OSCORE flag bits.  This flag
bit is registered in iana-cons-flag-bits of this specification.
The Pairwise Flag bit is set to 1 if the OSCORE message is
protected using pairwise keying material, which is shared with a
single group member as single intended recipient and derived as
defined in sec-derivation-pairwise.  This is used, for instance,
to send responses with the optimized mode defined in sec-
optimized-mode.  In any other case, especially when the OSCORE
message is protected as per ssec-protect-request and ssec-protect-
response, this bit MUST be set to 0.
The recipient does not support this feature, i.e. it is not
capable or willing to process OSCORE messages protected using
pairwise keying material.
The recipient can not retrieve a Security Context which is both
valid to process the message and also associated to an OSCORE
group.
In step 2, the decoding of the compressed COSE object follows
compression of this specification.  If the received Recipient ID
('kid') does not match with any Recipient Context for the
retrieved Gid ('kid context'), then the server MAY create a new
Recipient Context and initializes it according to Section 3 of
RFC8613, also retrieving the client's public key.  Such a
configuration is application specific.  If the application does
not specify dynamic derivation of new Recipient Contexts, then the
server SHALL stop processing the request.
In step 5, the counter signature is computed and the format of the
OSCORE message is modified as described in sec-cose-object and
compression of this specification.  In particular, the payload of
the OSCORE message includes also the counter signature.
If Observe RFC7641 is supported, for each newly started observation,
the client MUST store the value of the 'kid' parameter from the
original Observe request.
The client MUST NOT update the stored value, even in case it is
individually rekeyed and receives a new Sender ID from the Group
Manager (see ssec-wrap-around-partial-iv).
If the Pairwise Flag bit is set to 1, and the server discards
the request due to not supporting this feature or not
retrieving a Security Context associated to the OSCORE group,
the server MAY respond with a 4.02 (Bad Option) error.  When
doing so, the server MAY set an Outer Max-Age option with value
zero, and MAY include a descriptive string as diagnostic
payload.
If the received Recipient ID ('kid') does not match with any
Recipient Context for the retrieved Gid ('kid context'), then
the server MAY create a new Recipient Context and initializes
it according to Section 3 of RFC8613, also retrieving the
client's public key.  Such a configuration is application
specific.  If the application does not specify dynamic
derivation of new Recipient Contexts, then the server SHALL
stop processing the request.
A server SHOULD NOT process a request if the received Recipient ID
('kid') is equal to its own Sender ID in its own Sender Context.
If Observe RFC7641 is supported, for each newly started observation,
the server MUST store the value of the 'kid' parameter from the
original Observe request.
The server MUST NOT update the stored value, even in case the
observer client is individually rekeyed and starts using a new Sender
ID received from the Group Manager (see ssec-wrap-around-partial-iv).
In step 5, the counter signature is computed and the format of the
OSCORE mesage is modified as described in compression of this
specification.  In particular, the payload of the OSCORE message
includes also the counter signature.
Note that the server MUST always protect a response by using its own
Sender Context from the latest owned Security Context.
Encode the Partial IV (Sender Sequence Number in network byte
order), which is set to the Sender Sequence Number of the server;
increment the Sender Sequence Number by one; compute the AEAD
nonce from the Sender ID, Common IV, and Partial IV.
Include in the respose the 'Partial IV' parameter, which is set to
the encoded Partial IV value above.
Include in the response the 'kid context' parameter, which is set
to the ID Context of the new Security Context, i.e. the new Group
Identifier (Gid).
If Observe RFC7641 is supported, the server may have ongoing
observations, started by Observe requests protected with an old
Security Context.
After completing the establishment of a new Security Context, the
server MUST protect the following notifications with its own Sender
Context from the new Security Context.
For each ongoing observation, the server SHOULD include in the first
notification protected with the new Security Context also the 'kid
context' parameter, which is set to the ID Context of the new
Security Context, i.e. the new Group Identifier (Gid).  It is
OPTIONAL for the server to include the 'kid context' parameter, as
set to the new Gid, also in further following notifications for those
observations.
Furthermore, for each ongoing observation, the server MUST use the
stored value of the 'kid' parameter from the original Observe
request, as value for the 'request_kid' parameter in the two
external_aad structures (see sec-cose-object-ext-aad-enc and sec-
cose-object-ext-aad-sign), when protecting notifications for that
observation.
Note that, as discussed in ssec-key-rotation, a client may receive a
response protected with a Security Context different from the one
used to protect the corresponding group request.
If Observe RFC7641 is supported, for each ongoing observation, the
client MUST use the stored value of the 'kid' parameter from the
original Observe request, as value for the 'request_kid' parameter in
the two external_aad structures (see sec-cose-object-ext-aad-enc and
sec-cose-object-ext-aad-sign), when verifying notifications for that
observation.
This ensures that the client can correctly verify notifications, even
in case it is individually rekeyed and starts using a new Sender ID
received from the Group Manager (see ssec-wrap-around-partial-iv).
For use cases that do not require an intermediary performing
signature verification and that use a compatible signature algorithm,
the optimized mode defined in this section provides significant
smaller message sizes and increases the security by making responses
confidential to other group members than the intended recipient.
The OSCORE header compression defined in compression is used, with
the following difference: the payload of the OSCORE message SHALL
encode the ciphertext without the tag, concatenated with the value of
the CounterSignature0 of the COSE object computed as described in
sec-cose-object-unprotected-field.
The optimized compressed request is compatible with all AEAD
algorithms defined in RFC8152, but would not be compatible with AEAD
algorithms that do not have a well-defined tag.
An optimized response is protected as defined in ssec-protect-
response, with the following differences.
The server MUST set to 1 the sixth least significant bit of the
OSCORE flag bits in the OSCORE option, i.e. the Pairwise Flag.
The COSE_Encrypt0 object included in the optimized response is
encrypted using a symmetric pairwise key K, that the server
derives as defined in sec-derivation-pairwise.  In particular, the
Sender/Recipient Key is the Sender Key of the server from its own
Sender Context, i.e. the Recipient Key that the client stores in
its own Recipient Context corresponding to the server.
The Counter Signature is not computed.  That is, unlike defined in
compression, the payload of the OSCORE message terminates with the
encoded ciphertext of the COSE object.
Note that no changes are made to the AEAD nonce and AAD.
Upon receiving a response with the Pairwise Flag set to 1, the client
MUST process it as defined in ssec-verify-response, with the
following differences.
No countersignature to verify is included.
The COSE_Encrypt0 object included in the optimized response is
decrypted and verified using the same symmetric pairwise key K,
that the client derives as described above for the server side and
as defined in sec-derivation-pairwise.
A group member can receive a message shortly after the group has been
rekeyed, and new security parameters and keying material have been
distributed by the Group Manager.  In the following two cases, this
may result in misaligned Security Contexts between the sender and the
recipient.
In the first case, the sender protects a message using the old
Security Context, i.e. before having installed the new Security
Context.  However, the recipient receives the message after having
installed the new Security Context, hence not being able to correctly
process it.  A possible way to ameliorate this issue is to preserve
the old, recent, Security Context for a maximum amount of time
defined by the application.  By doing so, the recipient can still try
to process the received message using the old retained Security
Context as second attempt.  This tolerance preserves the processing
of secure messages throughout a long-lasting key rotation, as group
rekeying processes may likely take a long time to complete,
especially in large scale groups.  On the other hand, a former
(compromised) group member can abusively take advantage of this, and
send messages protected with the old retained Security Context.
Therefore, a conservative application policy should not admit the
retention of old Security Contexts.
In the second case, the sender protects a message using the new
Security Context, but the recipient receives that request before
having installed the new Security Context.  Therefore, the recipient
would not be able to correctly process the request and hence discards
it.  If the recipient receives the new Security Context shortly after
that and the sender endpoint uses CoAP retransmissions, the former
will still be able to receive and correctly process the message.  In
any case, the recipient should actively ask the Group Manager for an
updated Security Context according to an application-defined policy,
for instance after a given number of unsuccessfully decrypted
incoming messages.
A group member can receive a message shortly after the group has been
rekeyed, and new security parameters and keying material have been
distributed by the Group Manager.
This may result in a client using an old Security Context to protect
a group request, and a server using a different new Security Context
to protect a corresponding response.  That is, clients may receive a
response protected with a Security Context different from the one
used to protect the corresponding group request.
In particular, a server may first get a group request protected with
the old Security Context, then install the new Security Context, and
only after that produce a response to send back to the client.  Since
a sender always protects an outgoing message using the latest owned
Security Context, the server discussed above protects the possible
response using the new Security Context.  Then, the client will
process that response using the new Security Context, provided that
it has installed the new security parameters and keying material
before the message reception.
In case block-wire transfer RFC7959 is used, the same considerations
from Section 7.2 of I-D.ietf-ace-key-groupcomm hold.
Furthermore, as described below, a group rekeying may temporarily
result in misaligned Security Contexts between the sender and
recipient of a same message.
In this case, the sender protects a message using the old Security
Context, i.e. before having installed the new Security Context.
However, the recipient receives the message after having installed
the new Security Context, hence not being able to correctly process
it.
A possible way to ameliorate this issue is to preserve the old,
recent, Security Context for a maximum amount of time defined by the
application.  By doing so, the recipient can still try to process the
received message using the old retained Security Context as second
attempt.  This makes particular sense when the recipient is a client,
that would hence be able to process incoming responses protected with
the old, recent, Security Context used to protect the associated
group request.  Instead, a recipient server would better and more
simply discard an incoming group request which is not successfully
processed with the new Security Context.
This tolerance preserves the processing of secure messages throughout
a long-lasting key rotation, as group rekeying processes may likely
take a long time to complete, especially in large scale groups.  On
the other hand, a former (compromised) group member can abusively
take advantage of this, and send messages protected with the old
retained Security Context.  Therefore, a conservative application
policy should not admit the retention of old Security Contexts.
In this case, the sender protects a message using the new Security
Context, but the recipient receives that message before having
installed the new Security Context.  Therefore, the recipient would
not be able to correctly process the message and hence discards it.
If the recipient installs the new Security Context shortly after that
and the sender endpoint uses CoAP retransmissions, the former will
still be able to receive and correctly process the message.
In any case, the recipient should actively ask the Group Manager for
an updated Security Context according to an application-defined
policy, for instance after a given number of unsuccessfully decrypted
incoming messages.
With reference to the processing defined in ssec-protect-request and
ssec-optimized-request, it is NOT RECOMMENDED for a client to use
Group OSCORE for securing a request sent to a single group member
over unicast.
If the client uses its own Sender Key to protect a unicast request to
a group member, an on-path adversary can, right then or later on,
redirect that request to one/many different group member(s) over
unicast, or to the whole OSCORE group over multicast.  By doing so,
the adversary can induce the target group member(s) to perform
actions intended to one group member only.  Note that the adversary
can be external, i.e. (s)he does not need to also be a member of the
OSCORE group.
This is due to the fact that the client is not able to indicate the
single intended recipient in a way which is secure and possible to
process for Group OSCORE on the server side.  In particular, Group
OSCORE does not protect network addressing information such as the IP
address of the intended recipient server.  It follows that the
server(s) receiving the redirected request cannot assert whether that
was the original intention of the client, and would thus simply
assume so.
The impact of such an attack depends especially on the REST method of
the request, i.e. the Inner CoAP Code of the OSCORE request message.
In particular, safe methods such as GET and FETCH would trigger
(several) unintended responses from the targeted server(s), while not
resulting in destructive behavior.  On the other hand, non safe
methods such as PUT, POST and PATCH/iPATCH would result in the target
server(s) taking active actions on their resources and possible
cyber-physical environment, with the risk of destructive consequences
and possible implications for safety.
Additional considerations are discussed in ssec-synch-challenge-
response, with respect to unicast requests including an Echo Option
I-D.ietf-core-echo-request-tag, as a challenge-response method for
servers to achieve synchronization of client Sender Sequence Numbers.
A client may instead use the pairwise mode defined in sec-pairwise-
protection-req, in order to protect a request sent to a single group
member using pairwise keying material.  This prevents the attack
discussed above by construction, as only the intended server is able
to derive the pairwise keying material used by the client to protect
the request.
Note that the Partial IV of an endpoint does not necessarily grow
monotonically.  For instance, upon wrap-around of the endpoint Sender
Sequence Number, the Partial IV also wraps-around, since 0 becomes
the next Sender Sequence Number used as Partial IV.  As discussed in
ssec-wrap-around-partial-iv, this results either in the endpoint
being individually rekeyed and getting a new Sender ID, or in the
establishment of a new Security Context in the group.  Therefore,
uniqueness of (key, nonce) pairs (see ssec-key-nonce-uniqueness) is
preserved also when a new Security Context is established.
IANA is asked to add the following value entry to the "OSCORE Flag
Bits" subregistry defined in Section 13.7 of RFC8613 as part of the
"CoRE Parameters" registry.