Draft: draft-ietf-core-oscore-groupcomm

Commentary: This PR is about the following points : Explicit handling of multiple non - notification responses from the same server to the same group request . The handling relies on the same rationale used for notifications , in order to detect replays and ensure ordering of responses from the same server . From a general point of view , this relates to the issue at Improved presentation of the security properties ensured by Group OSCORE , by following more closely the parlance and structure used for OSCORE in RFC 8613 . Improved listing of operations defined for the group mode that are inherited by the pairwise mode . Have " SHOULD " ( not " MUST " ) for using the group mode to protect a request intended to multiple recipients . An exception is a Deterministic Request as defined in [ 1 ] , which is always protected with the pairwise mode , even in the case where it is intended to multiple servers . Editorial fixes . [ 1 ]
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 RFC9053 and related
countersignatures 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; Observe RFC7641; CBOR RFC8949; COSE RFC9053 and
related countersignatures I-D.ietf-cose-countersign.
Non-Notification Group Exchange: the exchange of messages between
a client and the servers in the group, as pertaining to a group
request from the client and the corresponding responses from the
servers that are _not_ Observe notifications RFC7641.  This is
irrespective of the group request being an Observe request or not.
The client terminates a Non-Notification Group Exchange when
freeing up the CoAP Token value used for the group request, for
which no further responses will be accepted afterwards.
An endpoint can eventually exhaust the Sender Sequence Number, which
is incremented for each new outgoing message including a Partial IV.
This is the case for group requests, Observe notifications RFC7641
and, optionally, any other response.
An endpoint can eventually exhaust the Sender Sequence Number, which
is incremented for each new outgoing message including a Partial IV.
This is the case for requests, Observe notifications RFC7641 and,
potentially, other responses.
For each ongoing Non-Notification Group Exchange where it is a
client and that it wants to keep active, it resets to 0 the
Response Number of each associated server (see sec-long-term-
observations).
This ensures that an Observe notification RFC7641 can never
successfully match against the Observe requests of two
different observations.  In fact, the excluded elder members
would eventually re-join the group, thus terminating any of
their ongoing (long-lasting) observations (see sec-long-term-
observations).  Therefore, it is ensured by construction that
no observer client can have two different ongoing observations
such that the two respective Observe requests were protected
using the same Partial IV, Gid and Sender ID.
This ensures that: i) an Observe notification RFC7641 can never
successfully match against the Observe requests of two
different observations; and ii) a non-notification response can
never successfully match against the group requests of two
different Non-Notification Group Exchanges.  In fact, the
excluded elder members would eventually re-join the group, thus
terminating any of their ongoing (long-lasting) observations
(see sec-long-term-observations) and Non-Notification Group
Exchanges (see sec-replay-protection-non-notifications).
Therefore, it is ensured by construction that no client can
have with the same server two ongoing observations, or two
ongoing Non-Notification Group Exchanges, or one ongoing
observation and one ongoing Non-Notification Group Exchange,
such that the two respective requests were protected using the
same Partial IV, Gid and Sender ID.
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.
This enables endpoints to safely keep an observation RFC7641 or a
Non-Notification Group Exchange 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 response,
regardless whether it is an Observe notification or not,
cryptographically matches with only one request, rather than with
multiple ones that were protected with different keying material
but share the same 'request_kid' and 'request_piv' values.
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.
Like OSCORE, also Group OSCORE provides message binding of responses
to requests, as well as uniqueness of AEAD (key, nonce) pair (see
Sections 7.1 and 7.2 of RFC8613, respectively).
Furthermore, the following also holds for Group OSCORE.
A client maintains for each ongoing Non-Notification Group Exchange
one Response Number for each different server.  Then, separately for
each server, the client uses the associated Response Number to
perform ordering and replay protection of non-notification responses
received from that server (see sec-replay-protection-non-
notifications).
Group OSCORE allows to preserve an observation active indefinitely,
even in case the group is rekeyed, with consequent change of ID
Context, or in case the observer client obtains a new Sender ID.
As defined in mess-processing when discussing support for Observe,
this is achieved by the client and server(s) storing the 'kid' and
'kid context' used in the original Observe request, throughout the
whole duration of the observation.
Upon leaving the group or before re-joining the group, a group member
MUST terminate all the ongoing observations that it has started in
the group as observer client.
Group OSCORE allows to preserve a Non-Notification Group Exchange and
an observation active indefinitely, even in case the group is
rekeyed, with consequent change of ID Context, or in case the client
obtains a new Sender ID.
As defined in mess-processing, this is achieved by the client and
server(s) storing the 'kid' and 'kid context' used in the original
request, throughout the whole duration of the Non-Notification Group
Exchange or of the observation.
Upon leaving the group or before re-joining the group, a group member
MUST terminate all the ongoing Non-Notification Group Exchanges and
observations that it has started in the group as a client, and hence
frees up the CoAP Token associated with the corresponding request.
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 RFC9175, as a variant of the approach
defined in Appendix B.1.2 of RFC8613 applicable to Group OSCORE.
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 RFC9175, as a variant of the approach
defined in Section B.1.2 of RFC8613 applicable to Group OSCORE.
Assuming an honest server, the message binding guarantees that a
response is not older than its request.  Hence, the following holds.
For non-notification responses to a non-group request, there is at
most a single such response and only from one, individually
targeted server in the group.  Therefore, absolute freshness of
such responses is guaranteed.
For non-notification responses to a group request, multiple such
responses can be received from the same server in reply to the
same group request, until the CoAP Token value associated with the
group request is freed up I-D.ietf-core-groupcomm-bis.  Therefore,
the absolute freshness of such responses gets weaker with time.
For notifications, the absolute freshness gets weaker with time,
and it is RECOMMENDED that the client regularly re-register the
observation.
For requests, notifications, and non-notification responses to
group requests, Group OSCORE also provides relative freshness.
That is, the received Partial IV allows a recipient to determine
the relative order of requests or responses.
It is not guaranteed that a misbehaving server did not create the
response before receiving the request, i.e., Group OSCORE does not
verify server aliveness.
Like in OSCORE RFC8613, the replay protection relies on the Partial
IV of incoming messages.  The operation of validating the Partial IV
and performing replay protection MUST be atomic.
The protection from replay of requests is performed as per
Section 7.4 of RFC8613, separately for each client by leveraging the
Replay Window in the corresponding Recipient Context.  When
supporting Observe RFC7641, the protection from replay of
notifications is performed as per Section 7.4.1 of RFC8613.
This section refers specifically to non-notification responses to a
group request.  A client can receive multiple such responses from the
same server in the group as a reply to the same group request, until
the CoAP Token value associated with the group request is freed up I-
D.ietf-core-groupcomm-bis.
When replying to a group request with a non-notification response
(both successful and error), a server MUST include a Partial IV,
except for the first non-notification response where the Partial IV
MAY be omitted.  A server supporting Observe RFC7641 MUST NOT reply
to a group request with 2.xx responses of which some are
notifications and some are not.
When processing responses from a same server to an Observe
registration request, a client supporting Observe MUST accept either
only notifications or only non-notification responses.  The specific
way to achieve this is implementation specific.
In order to protect against replay, the client SHALL maintain for
each ongoing Non-Notification Group Exchange one Response Number for
each different server.  The Response Number is a non-negative integer
containing the largest Partial IV of the received non-notification
responses from that server within the Non-Notification Group
Exchange.
Then, separately for each server, the client uses the associated
Response Number to perform ordering and replay protection of the non-
notification responses to a group request received from that server,
by comparing their Partial IVs with one another and against the
Response Number.
For each server, the associated Response Number is initialized to the
Partial IV of the first successfully verified non-notification
response to a group request.  A client MUST only accept at most one
such response without Partial IV from each server in the group, and
treat it as the oldest non-notification response to the group request
received from that server.
A client receiving a non-notification response to a group request
containing a Partial IV SHALL compare the Partial IV with the
Response Number associated with the replying server within the
ongoing Non-Notification Group Exchange.  The client MUST stop
processing non-observation responses to a group request from a
server, if those have a Partial IV that has been previously received
before from that server within the Non-Notification Group Exchange.
Applications MAY decide that a client only processes non-notification
responses to a group request if those have a greater Partial IV than
the Response Number associated with the replying server within the
ongoing Non-Notification Group Exchange.
If the verification of the non-notification response succeeds, and
the received Partial IV was greater than the Response Number
associated with the replying server, then the client SHALL overwrite
that Response Number with the received Partial IV.
For each server, a client MUST consider the non-notification response
to a group request with the highest Partial IV as the freshest,
regardless of the order of arrival.  Given a group request,
implementations need to make sure that the corresponding non-
notification response from a server without Partial IV is considered
the oldest from that server.
What is defined in this section does not apply to non-notification
responses to non-group requests, since there is at most a single such
response and only from one, individually targeted server in the
group.
The group mode MUST be used to protect group requests intended for
multiple recipients or for the whole group.  This includes both
requests directly addressed to multiple recipients, e.g., sent by the
client over multicast, as well as requests sent by the client over
unicast to a proxy, that forwards them to the intended recipients
over multicast I-D.ietf-core-groupcomm-bis.  For encryption and
decryption operations, the Signature Encryption Algorithm from the
Common Context is used.
The group mode SHOULD be used to protect group requests intended for
multiple recipients or for the whole group.  For an example where
this is not fulfilled, see I-D.amsuess-core-cachable-oscore.  This
applies to both requests directly addressed to multiple recipients,
e.g., sent by the client over multicast, as well as requests sent by
the client over unicast to a proxy, that forwards them to the
intended recipients over multicast I-D.ietf-core-groupcomm-bis.  For
encryption and decryption operations, the Signature Encryption
Algorithm from the Common Context is used.
In addition, when sending a group request, the following applies for
the corresponding Non-Notification Group Exchange.
If the client intends to keep the Non-Notification Group Exchange
active beyond a possible change of Sender ID, the client MUST
store the value of the 'kid' parameter from the group request, and
retain it until the Non-Notification Group Exchange is terminated.
Even in case the client is individually rekeyed and receives a new
Sender ID from the Group Manager (see new-sender-id), the client
MUST NOT update the stored 'kid' parameter value associated with
the Non-Notification Group Exchange and the corresponding group
request.
If the client intends to keep the Non-Notification Group Exchange
active beyond a possible change of ID Context following a group
rekeying (see sec-group-key-management), then the following
applies.
The client MUST store the value of the 'kid context' parameter
from the group request, and retain it until the Non-
Notification Group Exchange is terminated.  Upon establishing a
new Security Context with a new Gid as ID Context (see new-sec-
context), the client MUST NOT update the stored 'kid context'
parameter value associated with the Non-Notification Group
Exchange and the corresponding group request.
After a group rekeying, such an invariant information makes it
simpler for the client to retrieve the current group keying
material from the Group Manager, in case the client has missed
both the rekeying messages and the first response protected
with the new Security Context (see ssec-protect-response).
Just like defined in ssec-protect-request, the client MUST
store an invariant identifier of the group, which is immutable
even in case the Security Context of the group is re-
established.
The server MUST store the value of the 'kid' parameter from the
group request, and retain it until the last non-notification
response has been sent.  The server MUST NOT update the stored
value of a 'kid' parameter associated with a particular group
request, even in case the client is individually rekeyed and
starts using a new Sender ID received from the Group Manager (see
new-sender-id).
The server MUST store the value of the 'kid context' parameter
from the group request, and retain it until the last non-
notification response has been sent, i.e., 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 of a 'kid context'
parameter associated with a particular group request.
In step 3, if the server is using a different Security Context for
the response compared to what was used to verify the request (see
sec-group-key-management), then 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.
The server MUST use the stored value of the 'kid' parameter
from the group request (see ssec-verify-request), 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 group request (see ssec-verify-request), as
value for the 'request_kid_context' parameter in the
external_aad structure (see sec-cose-object-ext-aad).
In step 3, if any of the following two conditions holds, 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.
The response is not the first response that the server sends to
the request, regardless whether it is an Observe notification
RFC7641 or a non-notification response to a group request (see
sec-replay-protection-non-notifications).
The server is using a different Security Context for the
response compared to what was used to verify the request (see
sec-group-key-management).
The server can obtain a new Sender ID from the Group Manager, when
individually rekeyed (see new-sender-id) or when re-joining the
group.  In such a case, the server can help the client to
synchronize, by including the 'kid' parameter in a response
protected in group mode, even when the request was protected in
pairwise mode (see sec-pairwise-protection-req).
That is, when responding to a request protected in pairwise mode,
the server SHOULD include the 'kid' parameter in a response
protected in group mode, if it is replying to that client for the
first time since the assignment of its new Sender ID.
In addition, the following applies.
If the server is using a different ID Context (Gid) for the
response compared to what was used to verify the request (see
sec-group-key-management) and this is the first response from
the server to that request, then the new ID Context MUST be
included in the 'kid context' parameter of the response.
The server may be replying to a request that was protected with
an old Security Context.  After completing the establishment of
a new Security Context, the server MUST protect all the
responses to that request with the Sender Context of the new
Security Context.
For each ongoing Non-Notification Group Exchange, the server
can help the client to synchronize, by including also the 'kid
context' parameter in non-notification responses 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 non-notification
response sent before the installation of the new Security
Context.
The server can obtain a new Sender ID from the Group Manager,
when individually rekeyed (see new-sender-id) or when re-
joining the group.  In such a case, the server can help the
client to synchronize, by including the 'kid' parameter in a
response protected in group mode, even when the request was
protected in pairwise mode (see sec-pairwise-protection-req).
That is, when responding to a request protected in pairwise
mode, the server SHOULD include the 'kid' parameter in a
response protected in group mode, if it is replying to that
client for the first time since the assignment of its new
Sender ID.
As per sec-replay-protection-non-notifications, the server MUST NOT
reply to a group request with 2.xx responses of which some are
notifications and some are not.  That is, if the server receives an
observation request and registers the observation, then any following
2.xx response from the server to that request MUST be a notification.
Also, if the server receives an observation request and registers the
observation, then any following 2.xx response from the server to that
request MUST be a notification.
The client MUST perform signature verification before
decrypting the COSE object, as defined below.  Implementations
that cannot perform the two steps in this order MUST ensure
that no access to the plaintext is possible before a successful
signature verification and MUST prevent any possible leak of
time-related information that can yield side-channel attacks.
In addition, the following applies if the client processes a
response to a group request.
The client MUST use the stored value of the 'kid' parameter
from the group request (see ssec-protect-request), 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 group request (see ssec-protect-request), as
value for the 'request_kid_context' parameter in the
external_aad structure (see sec-cose-object-ext-aad).
This ensures that, throughout a Non-Notification Group Exchange,
the client can correctly verify non-notification responses to a
group request, even in case the client 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).
The client MUST perform signature verification as defined
below, before decrypting the COSE object.  Implementations that
cannot perform the two steps in this order MUST ensure that no
access to the plaintext is possible before a successful
signature verification and MUST prevent any possible leak of
time-related information that can yield side-channel attacks.
If the verification of the countersignature fails, the server
SHALL stop processing the response, and SHALL NOT update the
Notification Number associated with the server if the response
is an Observe notification RFC7641.
After a successful verification of the countersignature, the
client performs also the following actions if the response is
not an Observe notification.
In case the request was protected in pairwise mode and the
'kid' parameter is present in the response, the client
checks whether this received 'kid' is equal to the expected
'kid', i.e., the known Recipient ID for the server to which
the request was intended for.
In case the request was protected in pairwise mode and the
'kid' parameter is not present in the response, the client
checks whether the server that has sent the response is the
same one to which the request was intended for.  This can be
done by checking that the public key used to verify the
countersignature of the response is equal to the public key
included in the authentication credential Recipient Auth
Cred, which was taken as input to derive the Pairwise Sender
Key used for protecting the request (see key-derivation-
pairwise).
In either case, if the client determines that the response has
come from a different server than the expected one, then the
client SHALL discard the response and SHALL NOT deliver it to
the application.  Otherwise, the client hereafter considers the
received 'kid' as the current Recipient ID for the server.
When decrypting the COSE object using the Recipient Key, the
Signature Encryption Algorithm from the Common Context MUST be
used.
Additionally, if the used Recipient Context was created upon
receiving this response and the message is not verified
successfully, the client MAY delete that Recipient Context.  Such
a configuration, which is specified by the application, mitigates
attacks that aim at overloading the client's storage.
If the verification of the countersignature fails, the server:
i) SHALL stop processing the response; ii) SHALL NOT update the
Response Number associated with the server, if the response is
a non-notification response to a group request; and iii) SHALL
NOT update the Notification Number associated with the server,
if the response is an Observe notification RFC7641.
After a successful verification of the countersignature, the
client performs also the following actions in case the request
was protected in pairwise mode (see sec-pairwise-protection-
req).
If the 'kid' parameter is present in the response, the
client checks whether this received 'kid' is equal to the
expected 'kid', i.e., the known Recipient ID for the server
to which the request was intended for.
If the 'kid' parameter is not present in the response, the
client checks whether the server that has sent the response
is the same one to which the request was intended for.  This
can be done by checking that the public key used to verify
the countersignature of the response is equal to the public
key included in the authentication credential Recipient Auth
Cred, which was taken as input to derive the Pairwise Sender
Key used for protecting the request (see key-derivation-
pairwise).
In either case, if the client determines that the response has
come from a different server than the expected one, then the
client: i) SHALL discard the response and SHALL NOT deliver it
to the application; ii) SHALL NOT update the Response Number
associated with the server, if the response is a non-
notification response to a group request; and iii) SHALL NOT
update the Notification Number associated with the server, if
the response is an Observe notification RFC7641.
Otherwise, the client hereafter considers the received 'kid' as
the current Recipient ID for the server.
In step 5, when decrypting the COSE object using the Recipient
Key, the Signature Encryption Algorithm from the Common Context
MUST be used.
In addition, the client performs the following actions for each
ongoing Non-Notification Group Exchange.
The ordering and the replay protection of non-notification
responses received from a server in reply to a group request
are performed as per sec-replay-protection-non-notifications of
this document, by using the Response Number associated with
that server for the Non-Notification Group Exchange in
question.  In case of unsuccessful decryption and verification
of a non-notification response, the client SHALL NOT update the
Response Number associated with the server.
When receiving the first valid non-notification response from a
server in reply to a group request, the client MUST store the
current kid "kid1" of that server for the Non-Notification
Group Exchange in question.  If the 'kid' field is included in
the OSCORE option of the response, its value specifies "kid1".
If the group request was protected in pairwise mode (see sec-
pairwise-protection-req), the 'kid' field may not be present in
the OSCORE option of the response (see sec-cose-object-kid).
In this case, the client assumes "kid1" to be the Recipient ID
for the server to which the group request was intended for.
When receiving another valid non-notification response to the
same group request from the same server - which can be
identified and recognized through the same public key used to
verify the countersignature and included in the server's
authentication credential - the client determines the current
kid "kid2" of the server as above for "kid1", and MUST check
whether "kid2" is equal to the stored "kid1".  If "kid1" and
"kid2" are different, the client: i) SHALL discard the response
and SHALL NOT deliver it to the application; and ii) SHALL NOT
update the Response Number associated with the server.
Note that, if "kid2" is different from "kid1" and the 'kid' field
is omitted from the response - which is possible if the group
request was protected in pairwise mode - then the client will
compute a wrong keystream to decrypt the countersignature (i.e.,
by using "kid1" rather than "kid2" in the 'id' field of the 'info'
array in sssec-encrypted-signature-keystream), thus subsequently
failing to verify the countersignature and discarding the
response.
This ensures that the client remains able to correctly perform the
ordering and replay protection of non-notification responses to
group requests, even in case a server legitimately starts using a
new Sender ID, as received from the Group Manager when
individually rekeyed (see new-sender-id) or when re-joining the
group.
In step 8, if the used Recipient Context was created upon
receiving this response and the message is not verified
successfully, the client MAY delete that Recipient Context.  Such
a configuration, which is specified by the application, mitigates
attacks that aim at overloading the client's storage.
When receiving another valid notification from the same server
- which can be identified and recognized through the same
public key used to verify the countersignature and included in
the server's authentication credential - the client determines
the current kid "kid2" of the server as above for "kid1", and
MUST check whether "kid2" is equal to the stored "kid1".  If
"kid1" and "kid2" are different, the client MUST cancel or re-
register the observation in question.
When receiving another valid notification from the same server
- which can be identified and recognized through the same
public key used to verify the countersignature and included in
the server's authentication credential - the client determines
the current kid "kid2" of the server as above for "kid1", and
MUST check whether "kid2" is equal to the stored "kid1".  If
"kid1" and "kid2" are different, the client: i) SHALL discard
the response and SHALL NOT deliver it to the application; ii)
SHALL NOT update the Notification Number associated with the
server; and iii) MUST cancel or re-register the observation in
question.
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.
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
differences also apply.
When sending a group request, what is specified in ssec-protect-
request of this document holds for the corresponding Non-
Notification Group Exchange, with respect to storing the value of
the 'kid' and 'kid context' parameters, and to storing an
invariant identifier of the group.
What is specified in ssec-verify-request of this document holds
with respect to the following points.
The possible, dynamic creation and configuration of a Recipient
Context upon receiving the request.
The possible deletion of a Recipient Context created upon
receiving the request, in case the request is not verified
successfully.
The rule about processing the request where the received
Recipient ID ('kid') is equal to the server's Sender ID.
The storing of the value of the 'kid' and 'kid context'
parameters from the group request, if the server intends to
reply with multiple non-notification responses to a group
request.
If the server is using a different Security Context for the
response compared to what was used to verify the request (see sec-
group-key-management), then 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.
The server can obtain a new Sender ID from the Group Manager, when
individually rekeyed (see new-sender-id) or when re-joining the
group.  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.
What is specified in ssec-protect-response of this document holds
with respect to the following points.
The protection of a response when using a different Security
Context than the one used to protect the corresponding request.
That is, the server always protects a response with the Sender
Context from its latest Security Context, and establishing a
new Security Context resets the Sender Sequence Number to 0
(see sec-group-key-management).
The use of the stored value of the 'kid' and 'kid context'
parameters, if the server intends to reply with multiple non-
notification responses to a group request.
The rules for the inclusion of the server's Sender Sequence
Number as Partial IV in a response, as used to build the AEAD
nonce to protect the response.
The rules for the inclusion of the ID Context (Gid) in the 'kid
context' parameter of a response, if the ID Context used for
the response differs from the one used to verify the request
(see sec-group-key-management), also for helping the client to
synchronize.
The rules for the inclusion of the Sender ID in the 'kid'
parameter of a response to a request that was protected in
pairwise mode, if the server has obtained a new Sender ID from
the Group Manager when individually rekeyed (see new-sender-
id), thus helping the client to synchronize.
What is specified in ssec-verify-response of this document holds
with respect to the following points.
The possible, dynamic creation and configuration of a Recipient
Context upon receiving the response.
The use of the stored value of the 'kid' and 'kid context'
parameters, when processing a response to a group request.
The performing of ordering and replay protection for non-
notification responses to a group request.
The possible deletion of a Recipient Context created upon
receiving the response, in case the response is not verified
successfully.
Endpoints that implement the ECDSA signature algorithm MAY use
"deterministic ECDSA" as specified in RFC6979.  Pure deterministic
elliptic-curve signature algorithms such as deterministic ECDSA
and EdDSA have the advantage of not requiring access to a source
of high-quality randomness.  However, these signature algorithms
have been shown vulnerable to some side-channel and fault
injection attacks due to their determinism, which can result in
extracting a device's private key.  As suggested in Section 2.1.1
of RFC9053, this can be addressed by combining both randomness and
determinism I-D.mattsson-cfrg-det-sigs-with-noise.
Endpoints that implement the ECDSA signature algorithm MAY use
"deterministic ECDSA" as specified in RFC6979.  Pure deterministic
elliptic-curve signature algorithms such as deterministic ECDSA
and EdDSA have the advantage of not requiring access to a source
of high-quality randomness.  However, these signature algorithms
have been shown vulnerable to some side-channel and fault
injection attacks due to their determinism, which can result in
extracting a device's private key.  As suggested in Section 2.1.1
of RFC9053, this can be addressed by combining both randomness and
determinism I-D.irtf-cfrg-det-sigs-with-noise.
The same threat model discussed for OSCORE in Appendix D.1 of RFC8613
holds for Group OSCORE.  In addition, when using the group mode,
source authentication of messages is explicitly ensured by means of
countersignatures, as discussed in ssec-group-mode-security.
The same threat model discussed for OSCORE in Section D.1 of RFC8613
holds for Group OSCORE.  In addition, when using the group mode,
source authentication of messages is explicitly ensured by means of
countersignatures, as discussed in ssec-group-mode-security.
The same considerations on supporting Proxy operations discussed for
OSCORE in Appendix D.2 of RFC8613 hold for Group OSCORE.
The same considerations on protected message fields for OSCORE
discussed in Appendix D.3 of RFC8613 hold for Group OSCORE.
The same considerations on uniqueness of (key, nonce) pairs for
OSCORE discussed in Appendix D.4 of RFC8613 hold for Group OSCORE.
This is further discussed in ssec-key-nonce-uniqueness 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 countersignature 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.
The same considerations on supporting Proxy operations discussed for
OSCORE in Section D.2 of RFC8613 hold for Group OSCORE.
The same considerations on protected message fields for OSCORE
discussed in Section D.3 of RFC8613 hold for Group OSCORE.
The same considerations on uniqueness of (key, nonce) pairs for
OSCORE discussed in Section D.4 of RFC8613 hold for Group OSCORE.
This is further discussed in ssec-key-nonce-uniqueness of this
document.
The same considerations on unprotected message fields for OSCORE
discussed in Section 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 Non-Notification Group Exchanges and observations active beyond
a possible change of ID Context (Gid), following a group rekeying
(see sec-cose-object-ext-aad).  Second, the countersignature 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.
The case A in Appendix D.4 of RFC8613 concerns all group requests
and responses including a Partial IV (e.g., Observe
notifications).  In this case, same considerations from RFC8613
apply here as well.
The case B in Appendix D.4 of RFC8613 concerns responses not
including a Partial IV (e.g., single response to a group request).
In this case, same considerations from RFC8613 apply here as well.
The case A in Section D.4 of RFC8613 concerns all group requests
and responses including a Partial IV (e.g., Observe notifications
and non-notification responses to group requests).  In this case,
same considerations from RFC8613 apply here as well.
The case B in Section D.4 of RFC8613 concerns responses not
including a Partial IV (e.g., single response to a non-group
request).  In this case, same considerations from RFC8613 apply
here as well.
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 RFC9175, as a variant of the
approach defined in Appendix B.1.2 of RFC8613 applicable to Group
OSCORE.
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 RFC9175, as a variant of the
approach defined in Section B.1.2 of RFC8613 applicable to Group
OSCORE.