Draft: draft-ietf-core-oscore-groupcomm

Commentary: Changes affect the following Sections : 2.2 2.4 2.4.1 2.4.1.1 and 2.4.1.2 6.1 and 6.2 10.10 and 10.11 Appendix E ( was E.3 ) 
 Addressed in 
 I support this . The reason for having multiple externalaad for groupcomm was that one of them coincided with OSCORE . This is no longer the case . Moreover the differences between the two externalaad currently in the draft is small .
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)
I-D.ietf-cose-rfc8152bis-algs 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.
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)
I-D.ietf-cose-rfc8152bis-algs and provides end-to-end encryption,
integrity, replay protection and binding of response to request
between a sender and a recipient, independent of the transport layer
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.
Just like OSCORE, Group OSCORE is independent of transport layer and
works wherever CoAP does.  Group communication for CoAP I-D.ietf-
core-groupcomm-bis uses UDP/IP multicast as the underlying data
transport.
Just like OSCORE, Group OSCORE is independent of the transport layer
and works wherever CoAP does.  Group communication for CoAP I-D.ietf-
core-groupcomm-bis uses UDP/IP multicast as the underlying data
transport.
Readers are expected to be familiar with the terms and concepts
described in CoAP RFC7252 including "endpoint", "client", "server",
"sender" and "recipient"; group communication for CoAP I-D.ietf-core-
groupcomm-bis; CBOR I-D.ietf-cbor-7049bis; COSE I-D.ietf-cose-
rfc8152bis-algs and related counter signatures I-D.ietf-cose-
countersign.
Readers are expected to be familiar with the terms and concepts
described in CoAP RFC7252 including "endpoint", "client", "server",
"sender" and "recipient"; group communication for CoAP I-D.ietf-core-
groupcomm-bis; CBOR RFC8949; COSE I-D.ietf-cose-rfc8152bis-algs and
related counter signatures I-D.ietf-cose-countersign.
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" (see Section 2.1 of I-D.ietf-
core-groupcomm-bis), not to be confused with "CoAP group" or
"application group".
Group: a set of endpoints that share group keying material and
security parameters (Common Context, see sec-context).  That is,
unless otherwise specified, the term group used in this
specification refers to a "security group" (see Section 2.1 of I-
D.ietf-core-groupcomm-bis), not to be confused with "CoAP group"
or "application group".
This format is consistent with every counter signature algorithm
currently considered in I-D.ietf-cose-rfc8152bis-algs, i.e. with
algorithms that have only the COSE key type as their COSE capability.
sec-future-cose-algs describes how Counter Signature Parameters can
be generalized for possible future registered algorithms having a
different set of COSE capabilities.
This format is consistent with every elliptic curve Diffie-Hellman
algorithm currently considered in I-D.ietf-cose-rfc8152bis-algs, i.e.
with algorithms that have only the COSE key type as their COSE
capability. sec-future-cose-algs describes how Secret Derivation
Parameters can be generalized for possible future registered
algorithms having a different set of COSE capabilities.
With the exception of the public key of the sender endpoint, a
receiver endpoint can derive a complete Security Context from a
received Group OSCORE message and the Common Context.  The public
keys in the Recipient Contexts can be retrieved from the Group
Manager (see group-manager) upon joining the group.  A public key can
alternatively be acquired from the Group Manager at a later time, for
example the first time a message is received from a particular
endpoint in the group (see ssec-verify-request and ssec-verify-
response).
With the exception of the public key of the sender endpoint and the
possibly associated pairwise keys, a receiver endpoint can derive a
complete Security Context from a received Group OSCORE message and
the Common Context.  The public keys in the Recipient Contexts can be
retrieved from the Group Manager (see group-manager) upon joining the
group.  A public key can alternatively be acquired from the Group
Manager at a later time, for example the first time a message is
received from a particular endpoint in the group (see ssec-verify-
request and ssec-verify-response).
Furthermore, sufficiently large replay windows should be considered,
to handle Partial IV values moving forward fast.  This can happen
when a client engages in frequent or long sequences of one-to-one
exchanges with servers in the group, such as a large number of block-
wise transfers to a single server.  When receiving following group
requests from that client, other servers in the group may believe to
have lost synchronization with the client's Sender Sequence Number.
If these servers use an Echo exchange to re-gain synchronization (see
ssec-synch-challenge-response), this in itself may consume a
considerable amount of client's Sender Sequence Numbers, hence later
resulting in the servers possibly performing a new Echo exchange.
Certain signature schemes, such as EdDSA and ECDSA, support a secure
combined signature and encryption scheme.  This section specifies the
derivation of "pairwise keys", for use in the pairwise mode of Group
OSCORE defined in sec-pairwise-protection.
An endpoint admits a maximum amount of Recipient Contexts for a same
Security Context, e.g. due to memory limitations.  After reaching
that limit, the creation of a new Recipient Context results in an
overflow.  When this happens, the endpoint has to delete a current
Recipient Context to install the new one.  It is up to the
application to define policies for selecting the current Recipient
Context to delete.  A newly installed Recipient Context that has
required to delete another Recipient Context is initialized with an
invalid Replay Window, and accordingly requires the endpoint to take
appropriate actions (see ssec-loss-mutable-context-overflow).
Certain signature schemes, such as EdDSA and ECDSA, support a secure
combined signature and encryption scheme.  This section specifies the
derivation of "pairwise keys", for use in the pairwise mode defined
in sec-pairwise-protection.
The Shared Secret is computed as a static-static Diffie-Hellman
shared secret NIST-800-56A, where the endpoint uses its private
key and the public key of the other endpoint X.
The Recipient Key and the public key are from the Recipient
Context associated to endpoint X.
The Sender Key and private key are from the Sender Context.
info and L are defined as in Section 3.2.1 of RFC8613.
The Sender Key and private key are from the Sender Context.  The
Sender Key is used as salt in the HKDF, when deriving the Pairwise
Sender Key.
The Recipient Key and the public key are from the Recipient
Context associated to endpoint X.  The Recipient Key is used as
salt in the HKDF, when deriving the Pairwise Recipient Key.
info and L are as defined in Section 3.2.1 of RFC8613.
After establishing a partially or completely new Security Context
(see sec-group-key-management and ssec-sec-context-persistence), the
old pairwise keys MUST be deleted.  Since new Sender/Recipient Keys
are derived from the new group keying material (see ssec-sender-
recipient-context), every group member MUST use the new Sender/
Recipient Keys when deriving new pairwise keys.
After establishing a partially or completely new Security Context
(see ssec-sec-context-persistence and sec-group-key-management), the
old pairwise keys MUST be deleted.  Since new Sender/Recipient Keys
are derived from the new group keying material (see ssec-sender-
recipient-context), every group member MUST use the new Sender/
Recipient Keys when deriving new pairwise keys.
If it is not feasible or practically possible to store and maintain
up-to-date the mutable part in non-volatile memory (e.g., due to
limited number of write operations), the endpoint MUST be able to
detect a loss of the mutable Security Context.
When a loss of mutable Security Context is detected (e.g., following
a reboot), the endpoint MUST NOT protect further messages using this
Security Context to avoid reusing a nonce with the same AEAD key, and
SHOULD instead retrieve new security parameters from the Group
Manager (see ssec-loss-mutable-context).
An endpoint that has lost its mutable Security Context, e.g. due to a
reboot, needs to prevent the re-use of a nonce with the same AEAD
key, and to handle incoming replayed messages.
To this end, after a loss of mutable Security Context, the endpoint
SHOULD inform the Group Manager, retrieve new Security Context
parameters from the Group Manager (see sec-group-re-join), and use
them to derive a new Sender Context (see ssec-sender-recipient-
context).  In particular, regardless the exact actions taken by the
Group Manager, the endpoint resets its Sender Sequence Number to 0,
and derives a new Sender Key. This is in turn used to possibly derive
new Pairwise Sender Keys.
From then on, the endpoint MUST use its latest installed Sender
Context to protect outgoing messages.
If an endpoint is not able to establish an updated Sender Context,
e.g. because of lack of connectivity with the Group Manager, the
endpoint MUST NOT protect further messages using the current Security
Context.
In order to handle the update of Replay Window in Recipient Contexts,
three approaches are discussed in synch-ex.  In particular, the
approach specified in ssec-synch-challenge-response and based on the
Echo Option I-D.ietf-core-echo-request-tag is a variant of the
approach defined in Appendix B.1.2 of RFC8613 as applicable to Group
OSCORE.
If it is not feasible or practically possible to store and maintain
up-to-date the mutable part in non-volatile memory (e.g., due to
limited number of write operations), the endpoint MUST be able to
detect a loss of the mutable Security Context and MUST accordingly
take the actions defined in ssec-loss-mutable-context.
An endpoint may lose its mutable Security Context, e.g. due to a
reboot (see ssec-loss-mutable-context-total) or to an overflow of
Recipient Contexts (see ssec-loss-mutable-context-overflow).
In such a case, the endpoint needs to prevent the re-use of a nonce
with the same AEAD key, and to handle incoming replayed messages.
In case a loss of the Sender Context and/or of the Recipient Contexts
is detected (e.g. following a reboot), the endpoint MUST NOT protect
further messages using this Security Context to avoid reusing an AEAD
nonce with the same AEAD key.
In particular, before resuming its operations in the group, the
endpoint MUST retrieve new Security Context parameters from the Group
Manager (see sec-group-re-join) and use them to derive a new Sender
Context (see ssec-sender-recipient-context).  Since this includes a
newly derived Sender Key, the server will not reuse the same pair
(key, nonce), even when using the Partial IV of (old re-injected)
requests to build the AEAD nonce for protecting the corresponding
responses.
From then on, the endpoint MUST use the latest installed Sender
Context to protect outgoing messages.  Also, newly created Recipient
Contexts will have a Replay Window which is initialized as valid.
If not able to establish an updated Sender Context, e.g. because of
lack of connectivity with the Group Manager, the endpoint MUST NOT
protect further messages using the current Security Context and MUST
NOT accept incoming messages from other group members, as currently
unable to detect possible replays.
After reaching the maximum amount of Recipient Contexts, an endpoint
will experience an overflow when installing a new Recipient Context,
as it requires to first delete an existing one (see ssec-sender-
recipient-context).
Every time this happens, the Replay Window of the new Recipient
Context is initialized as not valid.  Therefore, the endpoint MUST
take the following actions, before accepting request messages from
the client associated to the new Recipient Context.
When receiving a first request to process with the new Recipient
Context, use the approach specified in sec-synch-challenge-
response and based on the Echo Option for CoAP I-D.ietf-core-echo-
request-tag, if supported.  In particular, the endpoint MUST use
its Partial IV when generating the AEAD nonce and MUST include the
Partial IV in the response message conveying the Echo Option.  If
the endpoint supports the CoAP Echo Option, it is RECOMMENDED to
take this approach.
If it is configured exclusively as silent server, the endpoint MUST
wait for the next group rekeying to occur, in order to derive a new
Security Context and re-initialize the Replay Window of each
Recipient Contexts as valid.
The endpoint SHOULD inform the Group Manager, retrieve new Security
Context parameters from the Group Manager (see sec-group-re-join),
and use them to derive a new Sender Context (see ssec-sender-
recipient-context).  In particular, regardless the exact actions
taken by the Group Manager, the endpoint resets its Sender Sequence
Number to 0, and derives a new Sender Key. This is in turn used to
possibly derive new Pairwise Sender Keys.
The endpoint SHOULD inform the Group Manager, retrieve new Security
Context parameters from the Group Manager (see sec-group-re-join),
and use them to derive a new Sender Context (see ssec-sender-
recipient-context).
The Group Manager can assist an endpoint with an incomplete Sender
Context to retrieve missing data of the Security Context and thereby
become fully operational in the group again.  The two main options
for the Group Manager are described in this section: i) assignment of
a new Sender ID to the endpoint (see new-sender-id); and ii)
establishment of a new Security Context for the group (see new-sec-
context).  Update of Replay Window in Recipient Contexts is discussed
in sec-synch-seq-num.
The Group Manager can assist an endpoint with an incomplete Sender
Context to retrieve missing data of the Security Context and thereby
become fully operational in the group again.  The two main options
for the Group Manager are described in this section: i) assignment of
a new Sender ID to the endpoint (see new-sender-id); and ii)
establishment of a new Security Context for the group (see new-sec-
context).  The update of the Replay Window in each of the Recipient
Contexts is discussed in sec-synch-seq-num.
The Group Manager may assign a new Sender ID to an endpoint, while
leaving the Gid, Master Secret and Master Salt unchanged in the
group.  In this case, the Group Manager MUST assign a Sender ID that
has never been assigned before in the group.
Having retrieved the new Sender ID, and potentially other missing
data of the immutable Security Context, the endpoint can derive a new
Sender Context (see ssec-sender-recipient-context).  When doing so,
the endpoint re-initilizes the Sender Sequence Number in its Sender
Context to 0.
The Group Manager may assign a new Sender ID to an endpoint, while
leaving the Gid, Master Secret and Master Salt unchanged in the
group.  In this case, the Group Manager MUST assign a Sender ID that
has never been assigned before in the group under the current Gid
value.
Having retrieved the new Sender ID, and potentially other missing
data of the immutable Security Context, the endpoint can derive a new
Sender Context (see ssec-sender-recipient-context).  When doing so,
the endpoint resets the Sender Sequence Number in its Sender Context
to 0, and derives a new Sender Key. This is in turn used to possibly
derive new Pairwise Sender Keys.
The assignment of a new Sender ID may be the result of different
processes.  The endpoint may request a new Sender ID, e.g. because of
exhaustion of Sender Sequence Numbers (see ssec-wrap-around-partial-
iv).  An endpoint may request to re-join the group, e.g. because of
losing its mutable Security Context (see ssec-loss-mutable-context),
and receive as response a new Sender ID together with the latest
immutable Security Context.
The assignment of a new Sender ID may be the result of different
processes.  The endpoint may request a new Sender ID, e.g. because of
exhaustion of Sender Sequence Numbers (see ssec-wrap-around-partial-
iv).  An endpoint may request to re-join the group, e.g. because of
losing its mutable Security Context (see ssec-loss-mutable-context),
and is provided with a new Sender ID together with the latest
immutable Security Context.
The Group Manager assigns unique Group Identifiers (Gids) to
different groups under its control, as well as unique Sender IDs (and
thereby Recipient IDs) to the members of those groups.  The Group
Manager MUST NOT reassign a Sender ID within the same group, and MUST
NOT reassign a Gid value to the same group.  According to a
hierarchical approach, the Gid value assigned to a group is
associated to a dedicated space for the values of Sender ID and
Recipient ID of the members of that group.
In addition, the Group Manager maintains records of the public keys
of endpoints in a group, and provides information about the group and
its members to other members and selected roles.  Upon nodes'
joining, the Group Manager collects such public keys and MUST verify
proof-of-possession of the respective private key.
The Group Manager assigns unique Group Identifiers (Gids) to
different groups under its control, as well as unique Sender IDs (and
thereby Recipient IDs) to the members of those groups.  According to
a hierarchical approach, the Gid value assigned to a group is
associated to a dedicated space for the values of Sender ID and
Recipient ID of the members of that group.
The Group Manager MUST NOT reassign a Gid value to the same group,
and MUST NOT reassign a Sender ID within the same group under the
same Gid value.
In addition, the Group Manager maintains records of the public keys
of endpoints in a group, and provides information about the group and
its members to other group members and selected roles.  Upon nodes'
joining, the Group Manager collects such public keys and MUST verify
proof-of-possession of the respective private key.
A group member can retrieve from the Group Manager the public key and
other information associated to another group member, with which it
can generate the corresponding Recipient Context.  An application can
configure a group member to asynchronously retrieve information about
Recipient Contexts, e.g. by Observing RFC7641 a resource at the Group
Manager to get updates on the group membership.
A group member can retrieve from the Group Manager the public key and
other information associated to another member of the group, with
which it can generate the corresponding Recipient Context.  In
particular, the requested public key is provided together with the
Sender ID of the associated group member.  An application can
configure a group member to asynchronously retrieve information about
Recipient Contexts, e.g. by Observing RFC7641 a resource at the Group
Manager to get updates on the group membership.
The Group Manager MUST NOT reassign a Gid value to the same group.
That is, each group can have a given Gid at most once during its
lifetime.  An example of Gid format supporting this operation is
provided in gid-ex.
The Group Manager MUST NOT reassign a previously used Sender ID
('kid') with the same Gid, Master Secret and Master Salt.  Even if
Gid and Master Secret are renewed as described in this section, the
Group Manager MUST NOT reassign an endpoint's Sender ID ('kid')
within a same group (see new-sender-id).
The Group Manager MUST NOT reassign a Gid value to the same group.
That is, every group can have a given Gid at most once during its
lifetime.  An example of Gid format supporting this operation is
provided in gid-ex.
The Group Manager MUST NOT reassign a previously used Sender ID
('kid') with the same Gid, Master Secret and Master Salt.  That is,
the Group Manager MUST NOT reassign a Sender ID value within a same
group under the same Gid value (see new-sender-id).  Within this
restriction, the Group Manager can assign a Sender ID used under an
old Gid value, thus avoiding Sender ID values to irrecoverably grow
in size.
Even when an endpoint joining a group is recognized as a current
member of that group, e.g. through the ongoing secure communication
association, the Group Manager MUST assign a new Sender ID different
than the one currently used by the endpoint in the group, unless the
group is rekeyed first and a new Gid value is established.
fig-key-material-diagram overviews the different keying material
components, considering their relation and possible reuse across
group rekeying.
Generating and managing Sender IDs within its OSCORE groups, as
well as assigning and providing them to new endpoints during the
join process, or to current group members upon request of renewal.
This includes ensuring that each Sender ID is unique within each
of the OSCORE groups, and that it is not reassigned within the
same group.
Defining communication policies for each of its OSCORE groups, and
signalling them to new endpoints during the join process.
Generating and managing Sender IDs within its OSCORE groups, as
well as assigning and providing them to new endpoints during the
join process, or to current group members upon request of renewal
or re-joining.
This includes ensuring that each Sender ID: is unique within each
of the OSCORE groups; and is not reassigned within the same group
under the same Gid value, i.e. not even to a current group member
re-joining the same group without a rekeying happening first.
Defining communication policies for each of its OSCORE groups, and
signaling them to new endpoints during the join process.
In particular, the Countersign_structure contains the context text
string "CounterSignature0", the external_aad as defined in sec-
cose-object-ext-aad-sign of this specification, and the ciphertext
of the COSE object as payload.
The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint
transmitting the message.  That is, unlike in RFC8613, the 'kid'
parameter is always present in all messages, both requests and
responses.
In particular, the Countersign_structure contains the context text
string "CounterSignature0", the external_aad as defined in sec-
cose-object-ext-aad of this specification, and the ciphertext of
the COSE object as payload.
The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint
transmitting the message, if the request was protected in group mode.
That is, unlike in RFC8613, the 'kid' parameter is always present in
responses to a request that was protected in group mode.
The external_aad of the Additional Authenticated Data (AAD) is
different compared to OSCORE.  In particular, there is one
external_aad used for encryption (both in group mode and pairwise
mode), and another external_aad used for signing (only in group
mode).
The external_aad for encryption (see Section 4.3 of I-D.ietf-cose-
rfc8152bis-struct), used both in group mode and pairwise mode,
includes also the counter signature algorithm and related signature
parameters, as well as the value of the 'kid context' in the COSE
object of the request (see fig-ext-aad-encryption).
The external_aad of the Additional Authenticated Data (AAD) is
different compared to OSCORE, and is defined in this section.
The same external_aad structure is used in group mode and pairwise
mode for encryption (see Section 5.3 of I-D.ietf-cose-rfc8152bis-
struct), as well as in group mode for signing (see Section 4.4 of I-
D.ietf-cose-rfc8152bis-struct).
In particular, the external_aad includes also the counter signature
algorithm and related signature parameters, the value of the 'kid
context' in the COSE object of the request, and the OSCORE option of
the protected message.
'par_countersign_key', which specifies the parameters
associated to the keys used with the countersignature algorithm
indicated in 'alg_countersign'.  These parameters are encoded
as a CBOR array 'countersign_key_type_capab', whose exact
structure and value depend on the value of 'alg_countersign'.
In particular, 'countersign_key_type_capab' is the array of
COSE capabilities for the COSE key type of the keys used with
the countersignature algorithm.  This is the second element of
the CBOR array Counter Signature Parameters from the Common
Context.
Examples of 'par_countersign_key' are in sec-cs-params-ex.
The external_aad for signing (see Section 4.3 of I-D.ietf-cose-
rfc8152bis-struct) used in group mode is identical to the
external_aad for encryption (see sec-cose-object-ext-aad-enc) with
the addition of the OSCORE option (see fig-ext-aad-signing).
the value of the OSCORE Option present in the protected message,
encoded as a binary string.
Note for implementation: this construction requires the OSCORE option
of the message to be generated before calculating the signature.
Also, the aad_array needs to be large enough to contain the largest
possible OSCORE option.
This format is consistent with every counter signature
algorithm currently considered in I-D.ietf-cose-rfc8152bis-
algs, i.e. with algorithms that have only the COSE key type as
their COSE capability. sec-future-cose-algs describes how
'par_countersign' can be generalized for possible future
registered algorithms having a different set of COSE
capabilities.
In case Observe RFC7641 is used, this enables endpoints to safely
keep an observation active beyond a possible change of Gid, i.e.
of ID Context, following a group rekeying (see sec-group-key-
management).  In fact, it ensures that every notification
cryptographically matches with only one observation request,
rather than with multiple ones that were protected with different
keying material but share the same 'request_kid' and 'request_piv'
values.
The new element 'OSCORE_option', containing the value of the
OSCORE Option present in the protected message, encoded as a
binary string.  This prevents the attack described in ssec-cross-
group-injection when using the group mode, as further explained in
sssec-cross-group-injection-group-mode.
Note for implementation: this construction requires the OSCORE
option of the message to be generated and finalized before
computing the ciphertext of the COSE_Encrypt0 object (when using
the group mode or the pairwise mode) and before calculating the
counter signature (when using the group mode).  Also, the
aad_array needs to be large enough to contain the largest possible
OSCORE option.
This specification defines the usage of the sixth least
significant bit, called the "Group Flag", in the first byte of the
OSCORE option containing the OSCORE flag bits.  This flag bit is
specified in iana-cons-flag-bits.
This specification defines the usage of the sixth least
significant bit, called "Group Flag", in the first byte of the
OSCORE option containing the OSCORE flag bits.  This flag bit is
specified in iana-cons-flag-bits.
The examples assume that the plaintext (see Section 5.3 of RFC8613)
is 6 bytes long, and that the AEAD tag is 8 bytes long, hence
resulting in a ciphertext which is 14 bytes long.  When using the
group mode, COUNTERSIGN denotes the COSE_CounterSignature0 byte
string as described in sec-cose-object, and is 64 bytes long.
The examples assume that the plaintext (see Section 5.3 of RFC8613)
is 6 bytes long, and that the AEAD tag is 8 bytes long, hence
resulting in a ciphertext which is 14 bytes long.  When using the
group mode, the COSE_CounterSignature0 byte string as described in
sec-cose-object is assumed to be 64 bytes long.
Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid =
0x52 and no Partial IV.
The requirements and properties described in Section 7 of RFC8613
also apply to OSCORE used in group communication.  In particular,
Group OSCORE provides message binding of responses to requests, which
enables absolute freshness of responses that are not notifications,
relative freshness of requests and notification responses, and replay
protection of requests.
A new server joining a group may not be aware of the current Partial
IVs (Sender Sequence Numbers of the clients).  Hence, when receiving
a request from a particular client for the first time, the new server
is not able to verify if that request is a replay.  The same holds
when a server loses its mutable Security Context (see ssec-loss-
mutable-context), for instance after a device reboot.
The exact way to address this issue is application specific, and
depends on the particular use case and its replay requirements.  The
list of methods to handle the update of a Replay Window is part of
the group communication policy, and different servers can use
different methods. synch-ex describes three possible approaches that
can be considered to address the issue discussed above.
Upon receiving a protected message, a recipient endpoint retrieves a
Security Context as in RFC8613.  An endpoint MUST be able to
distinguish between a Security Context to process OSCORE messages as
in RFC8613 and a Security Context to process Group OSCORE messages as
defined in this specification.
Response with ciphertext = 0x60b035059d9ef5667c5a0710823b and no
Partial IV.
The requirements and properties described in Section 7 of RFC8613
also apply to Group OSCORE.  In particular, Group OSCORE provides
message binding of responses to requests, which enables absolute
freshness of responses that are not notifications, relative freshness
of requests and notification responses, and replay protection of
requests.  In addition, the following holds for Group OSCORE.
Sender Sequence Numbers seen by a server as Partial IV values in
request messages can spontaneously increase at a fast pace, for
example when a client exchanges unicast messages with other servers
using the Group OSCORE Security Context.  As in OSCORE RFC8613, a
server always needs to accept such increases and accordingly updates
the Replay Window in each of its Recipient Contexts.
As discussed in ssec-loss-mutable-context, a newly created Recipient
Context would have an invalid Replay Window, if its installation has
required to delete another Recipient Context.  Hence, the server is
not able to verify if a request from the client associated to the new
Recipient Context is a replay.  When this happens, the server MUST
validate the Replay Window of the new Recipient Context, before
accepting messages from the associated client (see ssec-loss-mutable-
context).
When receiving a request from a client for the first time, the server
is not synchronized with the client's Sender Sequence Number, i.e. it
is not able to verify if that request is fresh.  This applies to a
server that has just joined the group, with respect to already
present clients, and recurs as new clients are added as group
members.
During its operations in the group, the server may also lose
synchronization with a client's Sender Sequence Number.  This can
happen, for instance, if the server has rebooted or has deleted its
previously synchronized version of the Recipient Context for that
client (see ssec-loss-mutable-context).
If the application requires message freshness, e.g. according to
time- or event-based policies, the server has to (re-)synchronize
with a client's Sender Sequence Number before delivering request
messages from that client to the application.  To this end, the
server can use the approach in sec-synch-challenge-response based on
the Echo Option for CoAP I-D.ietf-core-echo-request-tag, as a variant
of the approach defined in Appendix B.1.2 of RFC8613 applicable to
Group OSCORE.
Upon receiving a protected message, a recipient endpoint retrieves a
Security Context as in RFC8613.  An endpoint MUST be able to
distinguish between a Security Context to process OSCORE messages as
in RFC8613 and a Group OSCORE Security Context to process Group
OSCORE messages as defined in this specification.
As per Section 6.1 of RFC8613, this holds also when retrieving a
Security Context which is valid but not associated to an OSCORE
group.  Future specifications may define how to process incoming
messages protected with a Security Contexts as in RFC8613, when
the Group Flag bit is set to 1.
As per I-D.ietf-core-groupcomm-bis, group requests sent over
multicast MUST be Non-Confirmable, and thus are not retransmitted by
the CoAP messaging layer.  Instead, applications should store such
outgoing messages for a pre-defined, sufficient amount of time, in
order to correctly perform possible retransmissions at the
application layer.  According to Section 5.2.3 of RFC7252, responses
to Non-Confirmable group requests SHOULD also be Non-Confirmable, but
endpoints MUST be prepared to receive Confirmable responses in reply
to a Non-Confirmable group request.  Confirmable group requests are
acknowledged in non-multicast environments, as specified in RFC7252.
As per I-D.ietf-core-groupcomm-bis, group requests sent over
multicast MUST be Non-Confirmable, and thus are not retransmitted by
the CoAP messaging layer.  Instead, applications should store such
outgoing messages for a predefined, sufficient amount of time, in
order to correctly perform possible retransmissions at the
application layer.  According to Section 5.2.3 of RFC7252, responses
to Non-Confirmable group requests SHOULD also be Non-Confirmable, but
endpoints MUST be prepared to receive Confirmable responses in reply
to a Non-Confirmable group request.  Confirmable group requests are
acknowledged in non-multicast environments, as specified in RFC7252.
Furthermore, endpoints in the group locally perform error handling
and processing of invalid messages according to the same principles
adopted in RFC8613.  However, a recipient MUST stop processing and
silently reject any message which is malformed and does not follow
the format specified in sec-cose-object, or which is not
cryptographically validated in a successful way.  In either case, it
is RECOMMENDED that the recipient does not send back any error
message.  This prevents servers from replying with multiple error
messages to a client sending a group request, so avoiding the risk of
flooding and possibly congesting the network.
Furthermore, endpoints in the group locally perform error handling
and processing of invalid messages according to the same principles
adopted in RFC8613.  However, a recipient MUST stop processing and
silently reject any message which is malformed and does not follow
the format specified in sec-cose-object of this specification, or
which is not cryptographically validated in a successful way.  In
either case, it is RECOMMENDED that the recipient does not send back
any error message.  This prevents servers from replying with multiple
error messages to a client sending a group request, so avoiding the
risk of flooding and possibly congesting the network.
The client MUST store the value of the 'kid context' parameter
from the original Observe request, and retain it for the whole
duration of the observation.  Upon establishing a new Security
Context with a new ID Context as Gid (see new-sec-context), the
client MUST NOT update the stored value associated to a
particular Observe request.
The client MUST store the value of the 'kid context' parameter
from the original Observe request, and retain it for the whole
duration of the observation.  Upon establishing a new Security
Context with a new Gid as ID Context (see new-sec-context), the
client MUST NOT update the stored value associated to a
particular Observe request.
If the server discards the request due to 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 server discards the request due to not retrieving a
Security Context associated to the OSCORE group, the server MAY
respond with a 4.01 (Unauthorized) error message.  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 signature verification fails, the server SHALL stop
processing the request and MAY respond with a 4.00 (Bad
Request) response.  If the verification fails, the same steps
are taken as if the decryption had failed.  In particular, the
Replay Window is only updated if both the signature
verification and the decryption succeed.
If the signature verification fails, the server SHALL stop
processing the request and MAY respond with a 4.00 (Bad
Request) response.  The server MAY set an Outer Max-Age option
with value zero.  The diagnostic payload MAY contain a string,
which, if present, MUST be "Decryption failed" as if the
decryption had failed.  Furthermore, the Replay Window MUST be
updated only if both the signature verification and the
decryption succeed.
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.  For
an example where this is not fulfilled, see Section 6.2.1 in I-
D.tiloca-core-observe-multicast-notifications.
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.  For
an example where this is not fulfilled, see Section 7.2.1 in I-
D.tiloca-core-observe-multicast-notifications.
The server MUST store the value of the 'kid context' parameter
from the original Observe request, and retain it for the whole
duration of the observation, beyond a possible change of ID
Context following a group rekeying (see sec-group-key-management).
That is, upon establishing a new Security Context with a new ID
Context as Gid (see new-sec-context), the server MUST NOT update
the stored value associated to the ongoing observation.
The server MUST store the value of the 'kid context' parameter
from the original Observe request, and retain it for the whole
duration of the observation, beyond a possible change of ID
Context following a group rekeying (see sec-group-key-management).
That is, upon establishing a new Security Context with a new Gid
as ID Context (see new-sec-context), the server MUST NOT update
the stored value associated to the ongoing observation.
The server MUST use the stored value of the 'kid' parameter from
the original Observe request (see ssec-verify-request-observe), 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).
The server MUST use the stored value of the 'kid context'
parameter from the original Observe request (see ssec-verify-
request-observe), as value for the 'request_kid_context' parameter
in the two external_aad structures (see sec-cose-object-ext-aad-
enc and sec-cose-object-ext-aad-sign).
The server MUST use the stored value of the 'kid' parameter from
the original Observe request (see ssec-verify-request-observe), as
value for the 'request_kid' parameter in the external_aad
structure (see sec-cose-object-ext-aad).
The server MUST use the stored value of the 'kid context'
parameter from the original Observe request (see ssec-verify-
request-observe), as value for the 'request_kid_context' parameter
in the external_aad structure (see sec-cose-object-ext-aad).
For each ongoing observation, the server MUST include in the first
notification protected with the new Security Context also the 'kid
context' parameter, which is set to the ID Context (Gid) of the new
Security Context.  It is OPTIONAL for the server to include the ID
Context (Gid) in the 'kid context' parameter also in further
following notifications for those observations.
For each ongoing observation, the server can help the client to
synchronize, by including also the 'kid context' parameter in
notifications following a group rekeying, with value set to the ID
Context (Gid) of the new Security Context.
If there is a known upper limit to the duration of a group rekeying,
the server SHOULD include the 'kid context' parameter during that
time.  Otherwise, the server SHOULD include it until the Max-Age has
expired for the last notification sent before the installation of the
new Security Context.
In step 2, the decoding of the compressed COSE object is modified
as described in compression of this document.  If the received
'kid context' matches an existing ID Context (Gid) but the
received 'kid' does not match any Recipient ID in this Security
Context, then the client MAY create a new Recipient Context for
this Recipient ID and initialize it according to Section 3 of
RFC8613, and also retrieve the associated public key.  If the
application does not specify dynamic derivation of new Recipient
Contexts, then the client SHALL stop processing the response.
In step 2, the decoding of the compressed COSE object is modified
as described in compression of this document.  In particular, a
'kid' may not be present, if the response is a reply to a request
protected in pairwise mode.  In such a case, the client assumes
the response 'kid' to be exactly the one of the server to which
the request protected in pairwise mode was intended for.
If the response 'kid context' matches an existing ID Context (Gid)
but the received/assumed 'kid' does not match any Recipient ID in
this Security Context, then the client MAY create a new Recipient
Context for this Recipient ID and initialize it according to
Section 3 of RFC8613, and also retrieve the associated public key.
If the application does not specify dynamic derivation of new
Recipient Contexts, then the client SHALL stop processing the
response.
The client MUST use the stored value of the 'kid' parameter from
the original Observe request (see ssec-protect-request-observe),
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).
The client MUST use the stored value of the 'kid context'
parameter from the original Observe request (see ssec-protect-
request-observe), as value for the 'request_kid_context' parameter
in the two external_aad structures (see sec-cose-object-ext-aad-
enc and sec-cose-object-ext-aad-sign).
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 new-sender-id), as well as when
it establishes a new Security Context with a new ID Context (Gid)
following a group rekeying (see sec-group-key-management).
When using the pairwise mode of Group OSCORE, messages are protected
and processed as in mess-processing, with the modifications described
in this section.  The security objectives of the pairwise mode are
discussed in ssec-sec-objectives.
The client MUST use the stored value of the 'kid' parameter from
the original Observe request (see ssec-protect-request-observe),
as value for the 'request_kid' parameter in the external_aad
structure (see sec-cose-object-ext-aad).
The client MUST use the stored value of the 'kid context'
parameter from the original Observe request (see ssec-protect-
request-observe), as value for the 'request_kid_context' parameter
in the external_aad structure (see sec-cose-object-ext-aad).
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 new-sender-id), as well as when
it installs a new Security Context with a new ID Context (Gid)
following a group rekeying (see sec-group-key-management).
When using the pairwise mode of Group OSCORE, messages are protected
and processed as in RFC8613, with the modifications described in this
section.  The security objectives of the pairwise mode are discussed
in ssec-sec-objectives.
If the signature algorithm used in the group supports ECDH (e.g.,
ECDSA, EdDSA), the pairwise mode MUST be supported by endpoints that
use the CoAP Echo Option I-D.ietf-core-echo-request-tag and/or block-
wise transfers RFC7959, for instance for responses after the first
block-wise request, which possibly targets all servers in the group
and includes the CoAP Block2 option (see Section 2.3.6 of I-D.ietf-
core-groupcomm-bis).  This prevents the attack described in ssec-
unicast-requests, which leverages requests sent over unicast to a
single group member and protected with the group mode.
The external_aad defined in sec-cose-object-ext-aad-enc of this
document is used for the encryption process.
Senders MUST NOT use the pairwise mode to protect a message intended
for multiple recipients.  The pairwise mode is defined only between
two endpoints and the keying material is thus only available to one
recipient.
If the signature algorithm used in the group supports ECDH (e.g.,
ECDSA, EdDSA), the pairwise mode MUST be supported by endpoints that
use the CoAP Echo Option I-D.ietf-core-echo-request-tag and/or block-
wise transfers RFC7959, for instance for responses after the first
block-wise request, which possibly targets all servers in the group
and includes the CoAP Block2 option (see Section 3.7 of I-D.ietf-
core-groupcomm-bis).  This prevents the attack described in ssec-
unicast-requests, which leverages requests sent over unicast to a
single group member and protected with the group mode.
Senders cannot use the pairwise mode to protect a message intended
for multiple recipients.  In fact, the pairwise mode is defined only
between two endpoints and the keying material is thus only available
to one recipient.
However, a sender can use the pairwise mode to protect a message sent
to (but not intended for) multiple recipients, if interested in a
response from only one of them.  For instance, this is useful to
support the address discovery service defined in ssec-pre-conditions,
when a single 'kid' value is indicated in the payload of a request
sent to multiple recipients, e.g. over multicast.
In order to protect an outgoing message in pairwise mode, the sender
needs to know the public key and the Recipient ID for the recipient
endpoint, as stored in the Recipient Context associated to that
endpoint (see Pairwise Sender Context of pairwise-implementation).
In order to protect an outgoing message in pairwise mode, the sender
needs to know the public key and the Recipient ID for the recipient
endpoint, as stored in the Recipient Context associated to that
endpoint (see pairwise-implementation).
To make addressing information of individual endpoints available,
servers in the group MAY expose a resource to which a client can send
a group request targeting a server or a set of servers, identified by
their 'kid' value(s).  The specified set may be empty, hence
identifying all the servers in the group.  Further details of such an
interface are out of scope for this document.
When using the pairwise mode, the request is protected as defined in
ssec-protect-request, with the following differences.
The counter signature is not computed and therefore not included
in the message.  The payload of the protected request thus
terminates with the encoded ciphertext of the COSE object, just
like in RFC8613.
Note that, like in the group mode, the external_aad for encryption is
generated as in sec-cose-object-ext-aad-enc, and the Partial IV is
the current fresh value of the client's Sender Sequence Number (see
pairwise-seqno).
Upon receiving a request with the Group Flag set to 0, following the
procedure in sec-message-reception, the server MUST process it as
defined in ssec-verify-request, with the following differences.
If the server discards the request due to not retrieving a
Security Context associated to the OSCORE group or to not
supporting the pairwise mode, 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.
To make addressing information of individual endpoints available,
servers in the group MAY expose a resource to which a client can send
a group request targeting a set of servers, identified by their 'kid'
values specified in the request payload.  The specified set may be
empty, hence identifying all the servers in the group.  Further
details of such an interface are out of scope for this document.
The pairwise mode protects messages between two members of a group,
essentially following RFC8613, but with the following notable
differences.
The external_aad defined in sec-cose-object-ext-aad of this
document is used for the encryption process.
When using the pairwise mode, the request is protected as defined in
Section 8.1 of RFC8613, with the differences summarized in sec-
differences-oscore-pairwise of this document.  The following
difference also applies.
If Observe RFC7641 is supported, what defined in ssec-protect-
request-observe of this document holds.
Upon receiving a request with the Group Flag set to 0, following the
procedure in sec-message-reception, the server MUST process it as
defined in Section 8.2 of RFC8613, with the differences summarized in
sec-differences-oscore-pairwise of this document.  The following
differences also apply.
If the server discards the request due to not retrieving a
Security Context associated to the OSCORE group or to not
supporting the pairwise mode, the server MAY respond with a 4.01
(Unauthorized) error message or a 4.02 (Bad Option) error message,
respectively.  When doing so, the server MAY set an Outer Max-Age
option with value zero, and MAY include a descriptive string as
diagnostic payload.
When using the pairwise mode, a response is protected as defined in
ssec-protect-response, with the following differences.
The counter signature is not computed and therefore not included
in the message.  The payload of the protected response thus
terminates with the encoded ciphertext of the COSE object, just
like in RFC8613.
Upon receiving a response with the Group Flag set to 0, following the
procedure in sec-message-reception, the client MUST process it as
defined in ssec-verify-response, with the following differences.
If Observe RFC7641 is supported, what defined in ssec-verify-
request-observe of this document holds.
When using the pairwise mode, a response is protected as defined in
Section 8.3 of RFC8613, with the differences summarized in sec-
differences-oscore-pairwise of this document.  The following
differences also apply.
As discussed in new-sender-id, the server can obtain a new Sender
ID from the Group Manager.  In such a case, the server can help
the client to synchronize, by including the 'kid' parameter in a
response protected in pairwise mode, even when the request was
also protected in pairwise mode.
That is, when responding to a request protected in pairwise mode,
the server SHOULD include the 'kid' parameter in a response
protected in pairwise mode, if it is replying to that client for
the first time since the assignment of its new Sender ID.
If Observe RFC7641 is supported, what defined in ssec-protect-
response-observe of this document holds.
Upon receiving a response with the Group Flag set to 0, following the
procedure in sec-message-reception, the client MUST process it as
defined in Section 8.4 of RFC8613, with the differences summarized in
sec-differences-oscore-pairwise of this document.  The following
differences also apply.
If Observe RFC7641 is supported, what defined in ssec-verify-
response-observe of this document holds.
The same considerations on unprotected message fields for OSCORE
discussed in Appendix D.5 of RFC8613 hold for Group OSCORE, with the
following difference.  The counter signature included in a Group
OSCORE message protected in group mode is computed also over the
value of the OSCORE option, which is part of the Additional
Authenticated Data used in the signing process.  This is further
discussed in ssec-cross-group-injection of this document.
The same considerations on unprotected message fields for OSCORE
discussed in Appendix D.5 of RFC8613 hold for Group OSCORE, with the
following differences.  First, the 'kid context' of request messages
is part of the Additional Authenticated Data, thus safely enabling to
keep observations active beyond a possible change of ID Context
(Gid), following a group rekeying (see sec-cose-object-ext-aad).
Second, the counter signature included in a Group OSCORE message
protected in group mode is computed also over the value of the OSCORE
option, which is also part of the Additional Authenticated Data used
in the signing process.  This is further discussed in ssec-cross-
group-injection of this document.
Instead, the pairwise mode described in sec-pairwise-protection
protects messages by using pairwise symmetric keys, derived from the
static-static Diffie-Hellman shared secret computed from the
asymmetric keys of the sender and recipient endpoint (see sec-
derivation-pairwise).  Therefore, in the parwise mode, the AEAD
algorithm provides both pairwise data-confidentiality and source
authentication of messages, without using counter signatures.
Instead, the pairwise mode described in sec-pairwise-protection
protects messages by using pairwise symmetric keys, derived from the
static-static Diffie-Hellman shared secret computed from the
asymmetric keys of the sender and recipient endpoint (see sec-
derivation-pairwise).  Therefore, in the pairwise mode, the AEAD
algorithm provides both pairwise data-confidentiality and source
authentication of messages, without using counter signatures.
Uniqueness of Sender IDs within the group is enforced by the Group
Manager, which never reassigns the same Sender ID within the same
group.
Uniqueness of Sender IDs within the group is enforced by the Group
Manager, which never reassigns the same Sender ID within the same
group under the same Gid value.
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.  As a consequence, 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.  In
such a case, as specified in ssec-protect-response, the server MUST
protect the potential response using the new Security Context.
Specifically, the server MUST include its Sender Sequence Number as
Partial IV in the response and use it to build the AEAD nonce to
protect the response.  This prevents the AEAD nonce from the request
from being reused with the new Security Context.
This may result in a client using an old Security Context to protect
a request, and a server using a different new Security Context to
protect a corresponding response.  As a consequence, clients may
receive a response protected with a Security Context different from
the one used to protect the corresponding request.
In particular, a server may first get a 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.  In such a
case, as specified in ssec-protect-response, the server MUST protect
the potential response using the new Security Context.  Specifically,
the server MUST include its Sender Sequence Number as Partial IV in
the response and use it to build the AEAD nonce to protect the
response.  This prevents the AEAD nonce from the request from being
reused with the new Security Context.
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.
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 a 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.
As discussed in sssec-cross-group-injection-group-mode, the attack is
practically infeasible if the message is protected in group mode,
since the counter signature is bound also to the OSCORE option,
through the Additional Authenticated Data used in the signing process
(see sec-cose-object-ext-aad-sign).
As discussed in sssec-cross-group-injection-group-mode, the attack is
practically infeasible if the message is protected in group mode,
thanks to the counter signature also bound to the OSCORE option
through the Additional Authenticated Data used in the signing process
(see sec-cose-object-ext-aad).
A malicious endpoint Z is also member of both G1 and G2.  Hence, Z
is able to derive the symmetric keys associated to X in G1 and G2.
When X sends a message M1 addressed to Y in G1 and protected in
pairwise mode, Z can intercept M1, and forge a valid message M2 to be
injected in G2, making it appear as still sent by X to Y and valid to
be accepted.
More in detail, Z intercepts and stops message M1, and forges a
message M2 by changing the value of the OSCORE option from M1 as
follows: the 'kid context' is changed from G1 to G2; and the 'kid' is
changed from Sid1 to Sid2.  Then, Z injects message M2 as addressed
to Y in G2.
Upon receiving M2, there is a probability equal to 2^-64 that Y
successfully verifies the same unchanged MAC by using Sid2 as
'request_kid' and using the Pairwise Recipient Key associated to X in
G2.
A malicious endpoint Z is also member of both G1 and G2.  Hence, Z
is able to derive the Sender Keys used by X in G1 and G2.
When X sends a message M1 addressed to Y in G1 and protected in
pairwise mode, Z can intercept M1, and attempt to forge a valid
message M2 to be injected in G2, making it appear as still sent by X
to Y and valid to be accepted.
More in detail, Z intercepts and stops message M1, and forges a
message M2 by changing the value of the OSCORE option from M1 as
follows: the 'kid context' is set to G2 (rather than G1); and the
'kid' is set to Sid2 (rather than Sid1).  Then, Z injects message M2
as addressed to Y in G2.
Upon receiving M2, there is a probability equal to 2^-64 that Y
successfully verifies the same unchanged MAC by using the Pairwise
Recipient Key associated to X in G2.
When a Group OSCORE message is protected with the group mode, the
counter signature is computed also over the value of the OSCORE
option, which is part of the Additional Authenticated Data used in
the signing process (see sec-cose-object-ext-aad-sign).
That is, the countersignature is computed also over: the ID Context
(Group ID) and the Partial IV, which are always present in group
requests; as well as the Sender ID of the message originator, which
is always present in all group requests and responses.
When a Group OSCORE message is protected with the group mode, the
counter signature is computed also over the value of the OSCORE
option, which is part of the Additional Authenticated Data used in
the signing process (see sec-cose-object-ext-aad).
That is, other than over the ciphertext, the countersignature is
computed over: the ID Context (Gid) and the Partial IV, which are
always present in group requests; as well as the Sender ID of the
message originator, which is always present in group requests as well
as in responses to requests protected in group mode.
If the countersignature did not cover the OSCORE option, the attack
would be possible also in group mode, since the same unchanged
countersignature from messsage M1 would be also valid in message M2.
Also, the following attack simplifications would hold, since Z is
able to derive the Sender/Recipient Keys of X and Y in G1 and G2.
If M2 is used as a request, Z can check offline if a performed
forgery is actually valid before sending the forged message to G2.
That is, this attack would have a complexity of 2^64 offline
calculations.
If M2 is used as a response, Z can also change the response
Partial IV, until the same unchanged MAC is successfully verified
by using Sid2 as 'request_kid' and the symmetric key associated to
X in G2.  Since the Partial IV is 5 bytes in size, this requires
2^40 operations to test all the Partial IVs, which can be done in
real-time.  Also, the probability that a single given message M1
can be used to forge a response M2 for a given request would be
equal to 2^-24, since there are more MAC values (8 bytes in size)
than Partial IV values (5 bytes in size).
Note that, by changing the Partial IV as discussed above, any
member of G1 would also be able to forge a valid signed response
message M2 to be injected in G1.
If the countersignature did not cover the OSCORE option, the attack
would still be possible against response messages protected in group
mode, since the same unchanged countersignature from message M1 would
be also valid in message M2.
Also, the following attack simplifications would hold, since Z is
able to derive the Sender/Recipient Keys of X and Y in G1 and G2.
That is, Z can also set a convenient Partial IV in the response,
until the same unchanged MAC is successfully verified by using G2 as
'request_kid_context', Sid2 as 'request_kid', and the symmetric key
associated to X in G2.
Since the Partial IV is 5 bytes in size, this requires 2^40
operations to test all the Partial IVs, which can be done in real-
time.  The probability that a single given message M1 can be used to
forge a response M2 for a given request would be equal to 2^-24,
since there are more MAC values (8 bytes in size) than Partial IV
values (5 bytes in size).
Note that, by changing the Partial IV as discussed above, any member
of G1 would also be able to forge a valid signed response message M2
to be injected in the same group G1.
A client can instead use the pairwise mode as defined in sec-
pairwise-protection-req, in order to protect a request sent to a
single group member by using pairwise keying material (see sec-
derivation-pairwise).  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.
A client supporting the pairwise mode SHOULD use it to protect
requests sent to a single group member over unicast, instead of using
the group mode.  For an example where this is not fulfilled, see
Section 6.2.1 in I-D.tiloca-core-observe-multicast-notifications.
With particular reference to block-wise transfers RFC7959,
Section 2.3.6 of I-D.ietf-core-groupcomm-bis points out that, while
an initial request including the CoAP Block2 option can be sent over
multicast, any other request in a transfer has to occur over unicast,
individually addressing the servers in the group.
Additional considerations are discussed in ssec-synch-challenge-
response, with respect to requests including a CoAP Echo Option I-
D.ietf-core-echo-request-tag that has to be sent over unicast, as a
challenge-response method for servers to achieve synchronization of
clients' Sender Sequence Number.
A client can instead use the pairwise mode as defined in sec-
pairwise-protection-req, in order to protect a request sent to a
single group member by using pairwise keying material (see sec-
derivation-pairwise).  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.
A client supporting the pairwise mode SHOULD use it to protect
requests sent to a single group member over unicast, instead of using
the group mode.  For an example where this is not fulfilled, see
Section 7.2.1 in I-D.tiloca-core-observe-multicast-notifications.
With particular reference to block-wise transfers RFC7959,
Section 3.7 of I-D.ietf-core-groupcomm-bis points out that, while an
initial request including the CoAP Block2 option can be sent over
multicast, any other request in a transfer has to occur over unicast,
individually addressing the servers in the group.
Additional considerations are discussed in sec-synch-challenge-
response, with respect to requests including a CoAP Echo Option I-
D.ietf-core-echo-request-tag that has to be sent over unicast, as a
challenge-response method for servers to achieve synchronization of
clients' Sender Sequence Number.
As in OSCORE, also Group OSCORE relies on sender sequence numbers
included in the COSE message field 'Partial IV' and used to build
AEAD nonces.
As in OSCORE RFC8613, also Group OSCORE relies on Sender Sequence
Numbers included in the COSE message field 'Partial IV' and used to
build AEAD nonces.
As discussed in sec-synch-seq-num, an endpoint that has just joined a
group is exposed to replay attack, as it is not aware of the Sender
Sequence Numbers currently used by other group members. synch-ex
describes how endpoints can synchronize with others' Sender Sequence
Number.
Unless exchanges in a group rely only on unicast messages, Group
OSCORE cannot be used with reliable transport.  Thus, unless only
unicast messages are sent in the group, it cannot be defined that
only messages with sequence numbers that are equal to the previous
sequence number + 1 are accepted.
The processing of response messages described in Section 2.3.1 of I-
D.ietf-core-groupcomm-bis also ensures that a client accepts a single
valid response to a given request from each replying server, unless
CoAP observation is used.
As discussed in Section 12.5 of RFC8613, a server may use the CoAP
Echo Option I-D.ietf-core-echo-request-tag to verify the aliveness of
the client that originated a received request.  This would also allow
the server to (re-)synchronize with the client's Sender Sequence
Number, as well as to ensure that the request is fresh and has not
been replayed or (purposely) delayed, if it is the first one received
from that client after having joined the group or rebooted (see ssec-
synch-challenge-response).
Since one-to-many communication such as multicast usually involves
unreliable transports, the simplification of the Replay Window to a
size of 1 suggested in Section 7.4 of RFC8613 is not viable with
Group OSCORE, unless exchanges in the group rely only on unicast
messages.
As discussed in sec-synch-seq-num, a Replay Window may be initialized
as not valid, following the loss of mutable Security Context ssec-
loss-mutable-context.  In particular, ssec-loss-mutable-context-total
and ssec-loss-mutable-context-overflow define measures that endpoints
need to take in such a situation, before resuming to accept incoming
messages from other group members.
As discussed in sec-freshness, a server may not be able to assert
whether an incoming request is fresh, in case it does not have or has
lost synchronization with the client's Sender Sequence Number.
If freshness is relevant for the application, the server may
(re-)synchronize with the client's Sender Sequence Number at any
time, by using the approach described in sec-synch-challenge-response
and based on the CoAP Echo Option I-D.ietf-core-echo-request-tag, as
a variant of the approach defined in Appendix B.1.2 of RFC8613
applicable to Group OSCORE.
Building on Section 12.5 of RFC8613, a server may use the CoAP Echo
Option I-D.ietf-core-echo-request-tag to verify the aliveness of the
client that originated a received request, by using the approach
described in sec-synch-challenge-response of this specification.
Furthermore, the following privacy considerations hold, about the
OSCORE option that may reveal information on the communicating
endpoints.
The 'kid' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, may reveal
information about the Sender Endpoint.  Since both requests and
responses always include the 'kid' parameter, this may reveal
information about both a client sending a group request and all
the possibly replying servers sending their own individual
response.
Furthermore, the following privacy considerations hold about the
OSCORE option, which may reveal information on the communicating
endpoints.
The 'kid' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, may reveal
information about the Sender Endpoint.  When both a request and
the corresponding responses include the 'kid' parameter, this may
reveal information about both a client sending a request and all
the possibly replying servers sending their own individual
response.
Furthermore, using the mechanisms described in ssec-synch-challenge-
response to achieve sequence number synchronization with a client may
reveal when a server device goes through a reboot.  This can be
mitigated by the server device storing the precise state of the
replay window of each known client on a clean shutdown.
Furthermore, using the mechanisms described in sec-synch-challenge-
response to achieve Sender Sequence Number synchronization with a
client may reveal when a server device goes through a reboot.  This
can be mitigated by the server device storing the precise state of
the Replay Window of each known client on a clean shutdown.
Note to RFC Editor: Please replace all occurrences of "[This
Document]" with the RFC number of this specification and delete this
paragraph.
Note to RFC Editor: Please replace "[This Document]" with the RFC
number of this specification and delete this paragraph.