Draft: draft-ietf-core-oscore-groupcomm

Commentary: The current -11 design allows an attacker to link messages from different groups as long as the public key is the same ( which it likely will be ) . I think group oscore should probably fulfill something like Group privacy ( an attacker that is not a member of both groups should not be able to link messages between groups ) I think that can be done by signing a HMAC that is not sent on the wire ( at least that stops the trivial attack ) , or by encrypting the signature . ( a signature verifying proxy would have to be a limited group member that can verify but not decrypt ) 
 As discussed , now addressed by encrypting the counter signature , see 
 COSE has discussed and are are planning to standardize new encryption algorithms for the AEAD interface after a request from FIDO . The new algorithms would not provide any integrity protection . The current version of the Group OSCORE draft would not be secure at all with these new algorithms due to the unusual design choice to let the sender countersign it 's own AEAD . This could easily be addressed by using a traditional MAC - then - Sign approach . 
 See As discussed , now a recipient endpoint owning the latest group keying material does not store the public keys of sender endpoints that are not current group members . This builds on the Group Manager informing of former group members when rekeying the group . As a result , proof of group - membership is always achieved , also for messages protected in group mode when using an encryption algorithm that does not provide integrity protection ( i.e. , there is no tag providing group authentication ) . 
 The current design where the sender " countersign " it 's own AEAD creates 80 - byte source authentication when everything except  is used . E.g. AES - CCM , AES - GCM , and ChaCha20 - Poly1305 . This make Group OSCORE impossible to use in many situations such as the 75 bytes in some cellular network broadcast ( even with CCM8 ) . It would be very strange to force people wanting to use AES - CCM , AES - GCM , or ChaCha20 - Poly1305 or other 16 - bit tag algorithms in pair - wise to use 80 - byte source authentication , when it can trivially by done with 64 bytes . While the TLS conclusions regarding CCM_8 is misleading , I think there will be a trend toward 128 bit tags . Many deployments for government and financial institutions always use 128 bit tags . Another big disadvantage with the current design is that the user to chose between more useless in the signature mode and less security in pair - wise . In the signature mode , the tag provides no security and you want as small as possible . For pair - wise many application would definitly want to use 16 bytes tags , e.g. application aligning with the CSNA suite . 8 - 16 additional bytes overhead for the signature mode makes a big difference . Group OSCORE without the useless AEAD tag could be used , but Group OSCORE with the tag can not . 
 I agree with the reasoning above , but have a question anyway : Is the AEAD authenticator actually " useless " ? Does n't it protect against DoSing the signature verifier ? 
 This issue was also addressed in version -12 , by admitting that the group mode could also use an encryption algorithm without integrity tag as Signature Encryption Algorithm . If an encryption algorithm with integrity tag is used anyway , the tag does not help against a DoS based on inducing the message recipient to verify a bad signature . As also clarified in version -12 [ 1][2 ] , the signature verification must happen and be successfully completed before proceeding with the decryption of the COSE object . [ 1 ] [ 2 ] 
 The verifier could check the AEAD tag on the encrypted part first . The text says that " The server MUST perform signature verification before decrypting the COSE object " ( with exceptions only for those that ca n't ) , but that 's not ruling out verification of the tag . ( Granted , many cryptographic APIs do n't support doing these things separately ) . ( Obtaining a valid tag on an encrypted signature is probably as easy or hard as obtaining a valid tag on the encrypted payload -- once an attacker has that , and either can be used to pester the server until the client 's request on that seqno gets through and the obtained tag is burned ) . 
 As per the follow - up side discussion , no further text is needed . 
 The common definition of countersignature in the litterature is : " add a signature to ( a document already signed by another person ) . " 
 " When either COSEEncrypt and COSEMac is used and more than two parties share the key , data origin authentication is not provided . Any party that knows the message - authentication key can compute a valid authentication tag ; therefore , the contents could originate from any one of the parties that share the key . Countersignatures of COSEEncrypt and COSEMac with short authentication tags do not provide the security properties associated with the same algorithm used in COSESign . To provide 128 - bit security against collision attacks , the tag length MUST be at least 256 - bits . A countersignature of a COSEMac with AES - MAC 256/128 provides at most 64 bits of integrity protection . Similarly , a countersignature of a COSE_Encrypt with AES - CCM-16 - 64 - 128 provides at most 32 bits bits of integrity protection . " 
 Addressed in
This document defines Group Object Security for Constrained RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g. sent over IP
multicast.  In particular, the described approach defines how OSCORE
is used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
This document defines Group Object Security for Constrained RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g., sent over IP
multicast.  In particular, the described approach defines how OSCORE
is used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
Group OSCORE also defines a pairwise mode where each member of the
group can efficiently derive a symmetric pairwise key with any other
member of the group for pairwise OSCORE communication.
The Constrained Application Protocol (CoAP) RFC7252 is a web transfer
protocol specifically designed for constrained devices and networks
RFC7228.  Group communication for CoAP I-D.ietf-core-groupcomm-bis
addresses use cases where deployed devices benefit from a group
communication model, for example to reduce latencies, improve
performance and reduce bandwidth utilization.  Use cases include
lighting control, integrated building control, software and firmware
updates, parameter and configuration updates, commissioning of
constrained networks, and emergency multicast (see sec-use-cases).
This specification defines the security protocol for Group
communication for CoAP I-D.ietf-core-groupcomm-bis.
The Constrained Application Protocol (CoAP) RFC7252 is a web transfer
protocol specifically designed for constrained devices and networks
RFC7228.  Group communication for CoAP I-D.ietf-core-groupcomm-bis
addresses use cases where deployed devices benefit from a group
communication model, for example to reduce latencies, improve
performance, and reduce bandwidth utilization.  Use cases include
lighting control, integrated building control, software and firmware
updates, parameter and configuration updates, commissioning of
constrained networks, and emergency multicast (see sec-use-cases).
Group communication for CoAP I-D.ietf-core-groupcomm-bis mainly uses
UDP/IP multicast as the underlying data transport.
This document defines Group OSCORE, providing the same end-to-end
security properties as OSCORE in the case where CoAP requests have
multiple recipients.  In particular, the described approach defines
how OSCORE is used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
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.
This document defines Group OSCORE, a security protocol for Group
communication for CoAP I-D.ietf-core-groupcomm-bis, providing the
same end-to-end security properties as OSCORE in the case where CoAP
requests have multiple recipients.  In particular, the described
approach defines how OSCORE is used in a group communication setting
to provide source authentication for CoAP group requests, sent by a
client to multiple servers, and for protection of the corresponding
CoAP responses.  Group OSCORE also defines a pairwise mode where each
member of the group can efficiently derive a symmetric pairwise key
with any other member of the group for pairwise OSCORE communication.
Just like OSCORE, Group OSCORE is independent of the transport layer
and works wherever CoAP does.
In the group mode, Group OSCORE requests and responses are
digitally signed with the private key of the sender and the
signature is embedded in the protected CoAP message.  The group
mode supports all COSE algorithms as well as signature
verification by intermediaries.  This mode is defined in mess-
processing and MUST be supported.
In the pairwise mode, two group members exchange Group OSCORE
requests and responses over unicast, and the messages are
protected with symmetric keys.  These symmetric keys are derived
from Diffie-Hellman shared secrets, calculated with the asymmetric
keys of the sender and recipient, allowing for shorter integrity
tags and therefore lower message overhead.  This mode is defined
in sec-pairwise-protection and is OPTIONAL to support.
In the group mode, Group OSCORE requests and responses are
digitally signed with the private key of the sender and the
signature is embedded in the protected CoAP message.  The group
mode supports all COSE signature algorithms as well as signature
verification by intermediaries.  This mode is defined in mess-
processing.
In the pairwise mode, two group members exchange OSCORE requests
and responses over unicast, and the messages are protected with
symmetric keys.  These symmetric keys are derived from Diffie-
Hellman shared secrets, calculated with the asymmetric keys of the
sender and recipient, allowing for shorter integrity tags and
therefore lower message overhead.  This mode is defined in sec-
pairwise-protection.
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.
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 countersignatures I-D.ietf-cose-countersign.
Silent server: member of a group that never sends protected
responses in reply to requests.  For CoAP group communications,
requests are normally sent without necessarily expecting a
response.  A silent server may send unprotected responses, as
error responses reporting an OSCORE error.  Note that an endpoint
can implement both a silent server and a client, i.e. the two
roles are independent.  An endpoint acting only as a silent server
performs only Group OSCORE processing on incoming requests.
Silent servers maintain less keying material and in particular do
not have a Sender Context for the group.  Since silent servers do
not have a Sender ID, they cannot support the pairwise mode.
Silent server: member of a group that never sends protected
responses in reply to requests.  For CoAP group communications,
requests are normally sent without necessarily expecting a
response.  A silent server may send unprotected responses, as
error responses reporting an OSCORE error.  Note that an endpoint
can implement both a silent server and a client, i.e., the two
roles are independent.  An endpoint acting only as a silent server
performs only Group OSCORE processing on incoming requests.
Silent servers maintain less keying material and in particular do
not have a Sender Context for the group.  Since silent servers do
not have a Sender ID, they cannot support the pairwise mode.
Birth Gid: with respect to a group member, the Gid obtained by
that group member upon (re-)joining the group.
Key Generation Number: an integer value identifying the current
version of the keying material used in a group.
One Common Context, shared by all the endpoints in the group.  Two
new parameters are included in the Common Context, namely Counter
Signature Algorithm and Counter Signature Parameters.  These
relate to the computation of counter signatures, when messages are
protected using the group mode (see mess-processing).
If the pairwise mode is supported, the Common Context is further
extended with two new parameters, namely Secret Derivation
Algorithm and Secret Derivation Parameters.  These relate to the
derivation of a static-static Diffie-Hellman shared secret, from
which pairwise keys are derived (see key-derivation-pairwise) to
protect messages with the pairwise mode (see sec-pairwise-
protection).
One Sender Context, extended with the endpoint's private key.  The
private key is used to sign the message in group mode, and for
deriving the pairwise keys in pairwise mode (see sec-derivation-
pairwise).  If the pairwise mode is supported, the Sender Context
is also extended with the Pairwise Sender Keys associated to the
other endpoints (see sec-derivation-pairwise).  The Sender Context
is omitted if the endpoint is configured exclusively as silent
server.
This specification refers to a group as a set of endpoints sharing
keying material and security parameters for executing the Group
OSCORE protocol (see terminology).  Regardless of what it actually
supports, each endpoint of a group is aware of whether the group uses
the group mode, or the pairwise mode, or both.
All members of a group maintain a Security Context as defined in
Section 3 of RFC8613 and extended as defined in this section.  How
the Security Context is established by the group members is out of
scope for this specification, but if there is more than one Security
Context applicable to a message, then the endpoints MUST be able to
tell which Security Context was latest established.
The default setting for how to manage information about the group,
including the Security Context, is described in terms of a Group
Manager (see group-manager).  In particular, the Group Manager
indicates whether the group uses the group mode, the pairwise mode,
or both of them, as part of the group data provided to candidate
group members when joining the group.
The remainder of this section provides further details about the
Security Context of Group OSCORE.  In particular, each endpoint which
is member of a group maintains a Security Context as defined in
Section 3 of RFC8613, extended as follows (see fig-additional-
context-information).
One Common Context, shared by all the endpoints in the group.
Several new parameters are included in the Common Context.
If a Group Manager is used for maintaining the group, the Common
Context is extended with the public key of the Group Manager.
When processing a message, the public key of the Group Manager is
included in the external additional authenticated data.
If the group uses the group mode, the Common context is extended
with the following new parameters.
Signature Encryption Algorithm and Signature Algorithm.  These
relate to the encryption/decryption operations and to the
computation/verification of countersignatures, respectively,
when a message is protected with the group mode (see mess-
processing).
Group Encryption Key, used to perform encryption/decryption of
countersignatures, when a message is protected with the group
mode (see mess-processing).
If the group uses the pairwise mode, the Common Context is
extended with a Pairwise Key Agreement Algorithm used for
agreement on a static-static Diffie-Hellman shared secret, from
which pairwise keys are derived (see key-derivation-pairwise) to
protect messages with the pairwise mode (see sec-pairwise-
protection).
One Sender Context, extended with the endpoint's public and
private key pair.  The private key is used to sign messages in
group mode, or for deriving pairwise keys in pairwise mode (see
sec-derivation-pairwise).  When processing a message, the public
key is included in the external additional authenticated data.
If the endpoint supports the pairwise mode, the Sender Context is
also extended with the Pairwise Sender Keys associated to the
other endpoints (see sec-derivation-pairwise).
The Sender Context is omitted if the endpoint is configured
exclusively as silent server.
One Recipient Context for each endpoint from which messages are
received.  It is not necessary to maintain Recipient Contexts
associated to endpoints from which messages are not (expected to
be) received.  The Recipient Context is extended with the public
key of the associated endpoint, used to verify the signature in
group mode and for deriving the pairwise keys in pairwise mode
(see sec-derivation-pairwise).  If the pairwise mode is supported,
then the Recipient Context is also extended with the Pairwise
Recipient Key associated to the other endpoint (see sec-
derivation-pairwise).
Further details about the Security Context of Group OSCORE are
provided in the remainder of this section.  How the Security Context
is established by the group members is out of scope for this
specification, but if there is more than one Security Context
applicable to a message, then the endpoints MUST be able to tell
which Security Context was latest established.
The default setting for how to manage information about the group is
described in terms of a Group Manager (see group-manager).
One Recipient Context for each endpoint from which messages are
received.  It is not necessary to maintain Recipient Contexts
associated to endpoints from which messages are not (expected to
be) received.  The Recipient Context is extended with the public
key of the associated endpoint, used to verify the signature in
group mode and for deriving the pairwise keys in pairwise mode
(see sec-derivation-pairwise).  If the endpoint supports the
pairwise mode, then the Recipient Context is also extended with
the Pairwise Recipient Key associated to the other endpoint (see
sec-derivation-pairwise).
The ID Context parameter (see Sections 3.3 and 5.1 of RFC8613) in the
Common Context SHALL contain the Group Identifier (Gid) of the group.
The choice of the Gid format is application specific.  An example of
specific formatting of the Gid is given in gid-ex.  The application
needs to specify how to handle potential collisions between Gids (see
ssec-gid-collision).
Counter Signature Algorithm identifies the digital signature
algorithm used to compute a counter signature on the COSE object (see
Sections 3.2 and 3.3 of I-D.ietf-cose-countersign), when messages are
protected using the group mode (see mess-processing).
This parameter is immutable once the Common Context is established.
Counter Signature Algorithm MUST take value from the "Value" column
of the "COSE Algorithms" Registry COSE.Algorithms.  The value is
associated to a COSE key type, as specified in the "Capabilities"
column of the "COSE Algorithms" Registry COSE.Algorithms.  COSE
capabilities for algorithms are defined in Section 8 of I-D.ietf-
cose-rfc8152bis-algs.
The EdDSA signature algorithm and the elliptic curve Ed25519 RFC8032
are mandatory to implement.  If elliptic curve signatures are used,
it is RECOMMENDED to implement deterministic signatures with
additional randomness as specified in I-D.mattsson-cfrg-det-sigs-
with-noise.
Counter Signature Parameters identifies the parameters associated to
the digital signature algorithm specified in Counter Signature
Algorithm.  This parameter is immutable once the Common Context is
established.
The first element is the array of COSE capabilities for Counter
Signature Algorithm, as specified for that algorithm in the
"Capabilities" column of the "COSE Algorithms" Registry
COSE.Algorithms (see Section 8.1 of I-D.ietf-cose-rfc8152bis-
algs).
The second element is the array of COSE capabilities for the COSE
key type associated to Counter Signature Algorithm, as specified
for that key type in the "Capabilities" column of the "COSE Key
Types" Registry COSE.Key.Types (see Section 8.2 of I-D.ietf-cose-
rfc8152bis-algs).
Examples of Counter Signature Parameters are in sec-cs-params-ex.
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.
Secret Derivation Algorithm identifies the elliptic curve Diffie-
Hellman algorithm used to derive a static-static Diffie-Hellman
shared secret, from which pairwise keys are derived (see key-
derivation-pairwise) to protect messages with the pairwise mode (see
sec-pairwise-protection).
This parameter is immutable once the Common Context is established.
Secret Derivation Algorithm MUST take value from the "Value" column
of the "COSE Algorithms" Registry COSE.Algorithms.  The value is
associated to a COSE key type, as specified in the "Capabilities"
column of the "COSE Algorithms" Registry COSE.Algorithms.  COSE
capabilities for algorithms are defined in Section 8 of I-D.ietf-
cose-rfc8152bis-algs.
Secret Derivation Parameters identifies the parameters associated to
the elliptic curve Diffie-Hellman algorithm specified in Secret
Derivation Algorithm.  This parameter is immutable once the Common
Context is established.
The first element is the array of COSE capabilities for Secret
Derivation Algorithm, as specified for that algorithm in the
"Capabilities" column of the "COSE Algorithms" Registry
COSE.Algorithms (see Section 8.1 of I-D.ietf-cose-rfc8152bis-
algs).
The second element is the array of COSE capabilities for the COSE
key type associated to Secret Derivation Algorithm, as specified
for that key type in the "Capabilities" column of the "COSE Key
Types" Registry COSE.Key.Types (see Section 8.2 of I-D.ietf-cose-
rfc8152bis-algs).
Examples of Secret Derivation Parameters are in sec-cs-params-ex.
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.
OSCORE specifies the derivation of Sender Context and Recipient
Context, specifically of Sender/Recipient Keys and Common IV, from a
set of input parameters (see Section 3.2 of RFC8613).  This
derivation applies also to Group OSCORE, and the mandatory-to-
implement HKDF and AEAD algorithms are the same as in RFC8613.  The
Sender ID SHALL be unique for each endpoint in a group with a fixed
Master Secret, Master Salt and Group Identifier (see Section 3.3 of
RFC8613).
AEAD Algorithm identifies the COSE AEAD algorithm to use for
encryption, when messages are protected using the pairwise mode (see
sec-pairwise-protection).  This algorithm MUST provide integrity
protection.  This parameter is immutable once the Common Context is
established, and it is not relevant if the group uses only the group
mode.
For endpoints that support the pairwise mode, the AEAD algorithm AES-
CCM-16-64-128 defined in Section 4.2 of I-D.ietf-cose-rfc8152bis-algs
is mandatory to implement.
The ID Context parameter (see Sections 3.1 and 3.3 of RFC8613) in the
Common Context SHALL contain the Group Identifier (Gid) of the group.
The choice of the Gid format is application specific.  An example of
specific formatting of the Gid is given in gid-ex.  The application
needs to specify how to handle potential collisions between Gids (see
ssec-gid-collision).
Group Manager Public Key specifies the public key of the Group
Manager.  This is included in the external additional authenticated
data (see sec-cose-object-ext-aad).
Each group member MUST obtain the public key of the Group Manager
with a valid proof-of-possession of the corresponding private key,
for instance from the Group Manager itself when joining the group.
Further details on the provisioning of the Group Manager's public key
to the group members are out of the scope of this document.
Signature Encryption Algorithm identifies the algorithm to use for
enryption, when messages are protected using the group mode (see
mess-processing).  This algorithm MAY provide integrity protection.
This parameter is immutable once the Common Context is established.
For endpoints that support the group mode and uses authenticated
encryption, the AEAD algorithm AES-CCM-16-64-128 defined in
Section 4.2 of I-D.ietf-cose-rfc8152bis-algs is mandatory to
implement.
Signature Algorithm identifies the digital signature algorithm used
to compute a countersignature on the COSE object (see Sections 3.2
and 3.3 of I-D.ietf-cose-countersign), when messages are protected
using the group mode (see mess-processing).  This parameter is
immutable once the Common Context is established.
For endpoints that support the group mode, the EdDSA signature
algorithm and the elliptic curve Ed25519 RFC8032 are mandatory to
implement.  If elliptic curve signatures are used, it is RECOMMENDED
to implement deterministic signatures with additional randomness as
specified in I-D.mattsson-cfrg-det-sigs-with-noise.
Group Encryption Key specifies the encryption key for deriving a
keystream to encrypt/decrypt a countersignature, when a message is
protected with the group mode (see mess-processing).
The Group Encryption Key is derived as defined for Sender/Recipient
Keys in Section 3.2.1 of RFC8613, with the following differences.
The 'alg_aead' element of the 'info' array takes the value of
Signature Encryption Algorithm from the Common Context (see ssec-
common-context-cs-alg).
The 'type' element of the 'info' array is "Group Encryption Key".
The label is an ASCII string and does not include a trailing NUL
byte.
L and the 'L' element of the 'info' array are the size of the
output of the HKDF Algorithm from the Common Context (see
Section 3.2 of RFC8613), in bytes.
Pairwise Key Agreement Algorithm identifies the elliptic curve
Diffie-Hellman algorithm used to derive a static-static Diffie-
Hellman shared secret, from which pairwise keys are derived (see key-
derivation-pairwise) to protect messages with the pairwise mode (see
sec-pairwise-protection).  This parameter is immutable once the
Common Context is established.
OSCORE specifies the derivation of Sender Context and Recipient
Context, specifically of Sender/Recipient Keys and Common IV, from a
set of input parameters (see Section 3.2 of RFC8613).  Like in
RFC8613, HKDF SHA-256 is the mandatory to implement HKDF.
The derivation of Sender/Recipient Keys and Common IV defined in
OSCORE applies also to Group OSCORE, with the following extensions
compared to Section 3.2.1 of RFC8613.
If the group uses (also) the group mode, the 'alg_aead' element of
the 'info' array takes the value of Signature Encryption Algorithm
from the Common Context (see ssec-common-context-cs-alg).
If the group uses only the pairwise mode, the 'alg_aead' element
of the 'info' array takes the value of AEAD Algorithm from the
Common Context (see ssec-common-context-aead-alg).
The Sender ID SHALL be unique for each endpoint in a group with a
certain tuple (Master Secret, Master Salt, Group Identifier), see
Section 3.3 of RFC8613.
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).
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 public and private key pair of each endpoint in the group as well
as the public key of the Group Manager for that group MUST have the
same format used in the group and MUST specify the public key
algorithm used in the group.
If CWTs RFC8392 or CWT claim sets I-D.ietf-rats-uccs are used as
credential format, the public key algorithm is described by a COSE
key type and related Key Type Parameters.  If X.509 certificates
RFC7925 or C509 I-D.ietf-cose-cbor-encoded-cert certificates are used
as credential format, the public key algorithm is described by the
SubjectPublicKeyInfoAlgorithm structure.
Public keys are also used to derive pairwise keys (see key-
derivation-pairwise) and are included in the external additional
authenticated data (see sec-cose-object-ext-aad).  For both such
cases, an endpoint MUST treat every involved public key as opaque
data, without any re-coding of the binary representation made
available to other endpoints, possibly through a designated trusted
source (e.g., a Group Manager).
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.  Group OSCORE keys used for both
signature and encryption MUST NOT be used for any other purposes than
Group OSCORE.
HKDF is the HKDF algorithm specified by Secret Derivation
Algorithm from the Common Context (see ssec-common-context-dh-
alg).
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.
If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
Section 5 of RFC7748.
HKDF is the OSCORE HKDF algorithm RFC8613 from the Common Context.
The Sender Key from the Sender Context is used as salt in the
HKDF, when deriving the Pairwise Sender Key.
The Recipient Key from the Recipient Context associated to
endpoint X is used as salt in the HKDF, when deriving the Pairwise
Recipient Key.
IKM-Sender is the Input Keying Material (IKM) used in the HKDF for
the derivation of the Pairwise Sender Key. IKM-Sender is the byte
string concatenation of the endpoint's own signature public key,
the endpoint X's signature public key from the Recipient Context,
and the Shared Secret.  The two signature public keys are binary
encoded as defined below.
IKM-Recipient is the Input Keying Material (IKM) used in the HKDF
for the derivation of the Recipient Sender Key. IKM-Recipient is
the byte string concatenation of the endpoint X's signature public
key from the Recipient Context, the endpoint's own signature
public key, and the Shared Secret.  The two signature public keys
are binary encoded as defined below.
The Shared Secret is computed as a cofactor Diffie-Hellman shared
secret, see Section 5.7.1.2 of NIST-800-56A, using the Pairwise
Key Agreement Algorithm.  The endpoint uses its private key from
the Sender Context and the public key of the other endpoint X from
the associated Recipient Context.  Note the requirement of
validation of public keys in ssec-crypto-considerations.  For
X25519 and X448, the procedure is described in Section 5 of
RFC7748 using public keys mapped to Montgomery coordinates, see
montgomery.
The 'alg_aead' element of the 'info' array takes the value of
AEAD Algorithm from the Common Context (see ssec-common-
context-aead-alg).
L and the 'L' element of the 'info' array are the size of the
key for the AEAD Algorithm from the Common Context (see ssec-
common-context-aead-alg), in bytes.
If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
Section 5 of RFC7748.  For further details, see montgomery.  ECC
assymetric keys in Montgomery or Weirstrass form are used directly in
the key agreement algorithm without coordinate mapping.
The y-coordinate of the other endpoint's Ed25519 public key is
decoded as specified in Section 5.1.3 of RFC8032.  The Curve25519
u-coordinate is recovered as u = (1 + y) / (1 - y) (mod p) following
the map in Section 4.1 of RFC7748.  Note that the mapping is not
defined for y = 1, and that y = -1 maps to u = 0 which corresponds to
the neutral group element and thus will result in a degenerate shared
secret.  Therefore implementations MUST abort if the y-coordinate of
the other endpoint's Ed25519 public key is 1 or -1 (mod p).
The private signing key byte strings (= the lower 32 bytes used for
generating the public key, see step 1 of Section 5.1.5 of RFC8032)
are decoded the same way for signing in Ed25519 and scalar
multiplication in X25519.  Hence, to compute the shared secret the
endpoint applies the X25519 function to the Ed25519 private signing
key byte string and the encoded u-coordinate byte string as specified
in Section 5 of RFC7748.
The y-coordinate of the other endpoint's Ed448 public key is decoded
as specified in Section 5.2.3. of RFC8032.  The Curve448 u-coordinate
is recovered as u = y^2 * (d * y^2 - 1) / (y^2 - 1) (mod p) following
the map from "edwards448" in Section 4.2 of RFC7748, and also using
the relation x^2 = (y^2 - 1)/(d * y^2 - 1) from the curve equation.
Note that the mapping is not defined for y = 1 or -1.  Therefore
implementations MUST abort if the y-coordinate of the peer endpoint's
Ed448 public key is 1 or -1 (mod p).
The private signing key byte strings (= the lower 57 bytes used for
generating the public key, see step 1 of Section 5.2.5 of RFC8032)
are decoded the same way for signing in Ed448 and scalar
multiplication in X448.  Hence, to compute the shared secret the
endpoint applies the X448 function to the Ed448 private signing key
byte string and the encoded u-coordinate byte string as specified in
Section 5 of RFC7748.
If the pairwise mode is supported, the Security Context additionally
includes Secret Derivation Algorithm, Secret Derivation Parameters
and the pairwise keys, as described at the beginning of sec-context.
If the pairwise mode is supported, the Security Context additionally
includes Pairwise Key Agreement Algorithm and the pairwise keys, as
described at the beginning of sec-context.
In the pairwise mode, the Sender Context includes the Pairwise Sender
Keys to use with the other endpoints (see fig-additional-context-
information).  In order to identify the right key to use, the
Pairwise Sender Key for endpoint X may be associated to the Recipient
ID of endpoint X, as defined in the Recipient Context (i.e. the
Sender ID from the point of view of endpoint X).  In this way, the
Recipient ID can be used to lookup for the right Pairwise Sender Key.
This association may be implemented in different ways, e.g. by
storing the pair (Recipient ID, Pairwise Sender Key) or linking a
Pairwise Sender Key to a Recipient Context.
It is RECOMMENDED that the immutable part of the Security Context is
stored in non-volatile memory, or that it can otherwise be reliably
accessed throughout the operation of the group, e.g. after a device
reboots.  However, also immutable parts of the Security Context may
need to be updated, for example due to scheduled key renewal, new or
re-joining members in the group, or the fact that the endpoint
changes Sender ID (see sec-group-re-join).
In the pairwise mode, the Sender Context includes the Pairwise Sender
Keys to use with the other endpoints (see fig-additional-context-
information).  In order to identify the right key to use, the
Pairwise Sender Key for endpoint X may be associated to the Recipient
ID of endpoint X, as defined in the Recipient Context (i.e., the
Sender ID from the point of view of endpoint X).  In this way, the
Recipient ID can be used to lookup for the right Pairwise Sender Key.
This association may be implemented in different ways, e.g., by
storing the pair (Recipient ID, Pairwise Sender Key) or linking a
Pairwise Sender Key to a Recipient Context.
It is RECOMMENDED that the immutable part of the Security Context is
stored in non-volatile memory, or that it can otherwise be reliably
accessed throughout the operation of the group, e.g., after a device
reboots.  However, also immutable parts of the Security Context may
need to be updated, for example due to scheduled key renewal, new or
re-joining members in the group, or the fact that the endpoint
changes Sender ID (see sec-group-re-join).
On the other hand, the mutable parts of the Security Context are
updated by the endpoint when executing the security protocol, but may
nevertheless become outdated, e.g. due to loss of the mutable
Security Context (see ssec-loss-mutable-context) or exhaustion of
Sender Sequence Numbers (see ssec-wrap-around-partial-iv).
On the other hand, the mutable parts of the Security Context are
updated by the endpoint when executing the security protocol, but may
nevertheless become outdated, e.g., due to loss of the mutable
Security Context (see ssec-loss-mutable-context) or exhaustion of
Sender Sequence Numbers (see ssec-wrap-around-partial-iv).
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 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.
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 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.
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.
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.
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.
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 not been used in the group since the latest time when the current
Gid value was assigned to the group (see sec-group-key-management).
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 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.
It resets to 0 the sequence number of each ongoing observation
where it is an observer client and that it wants to keep
active.
For each ongoing observation where it is an observer client and
that it wants to keep active, it resets to 0 the Notification
Number of each associated server (see sec-long-term-
observations).
As with OSCORE, endpoints communicating with Group OSCORE need to
establish the relevant Security Context.  Group OSCORE endpoints need
to acquire OSCORE input parameters, information about the group(s)
and about other endpoints in the group(s).  This specification is
based on the existence of an entity called Group Manager which is
responsible for the group, but does not mandate how the Group Manager
interacts with the group members.  The responsibilities of the Group
Manager are compiled in sec-group-manager.
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 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 MAY serve additional entities acting as signature
checkers, e.g. intermediary gateways.  These entities do not join a
group as members, but can retrieve public keys of group members from
the Group Manager, in order to verify counter signatures of group
messages.  A signature checker MUST be authorized for retrieving
public keys of members in a specific group from the Group Manager.
To this end, the same method mentioned above based on the ACE
framework I-D.ietf-ace-oauth-authz can be used.
In order to establish a new Security Context for a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be generated.  When distributing the new Gid and
Master Secret, the Group Manager MAY distribute also a new value for
the Master Salt parameter, and should preserve the current value of
the Sender ID of each group member.
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.
As with OSCORE, endpoints communicating with Group OSCORE need to
establish the relevant Security Context.  Group OSCORE endpoints need
to acquire OSCORE input parameters, information about the group(s)
and about other endpoints in the group(s).  This specification is
based on the existence of an entity called Group Manager and
responsible for the group, but it does not mandate how the Group
Manager interacts with the group members.  The responsibilities of
the Group Manager are compiled together in sec-group-manager.
The Group Manager assigns an integer Key Generation Number to each of
its groups, identifying the current version of the keying material
used in that group.  The first Key Generation Number assigned to
every group MUST be 0.  Separately for each group, the value of the
Key Generation Number increases strictly monotonically, each time the
Group Manager distributes new keying material to that group (see sec-
group-key-management).  That is, if the current Key Generation Number
for a group is X, then X+1 will denote the keying material
distributed and used in that group immediately after the current one.
The Group Manager assigns unique Group Identifiers (Gids) to the
groups under its control.  Also, for each group, the Group Manager
assigns unique Sender IDs (and thus Recipient IDs) to the respective
group members.  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.
When a node (re-)joins a group, it is provided also with the current
Gid to use in the group, namely the Birth Gid of that node for that
group.  For each group member, the Group Manager MUST store the
latest corresponding Birth Gid until that member leaves the group.
In case the node has in fact re-joined the group, the newly
determined Birth Gid overwrites the one currently stored.
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 to external principals with selected roles
(see sec-additional-principals).  Upon nodes' joining, the Group
Manager collects such public keys and MUST verify proof-of-possession
of the respective private key.
Furthermore, when joining the group or later on as a group member, an
endpoint can retrieve from the Group Manager the public key of the
Group Manager as well as the public key and other information
associated to other members of the group, with which it can derive
the corresponding Recipient Context.  Together with the requested
public keys, the Group Manager MUST provide the Sender ID of the
associated group members and the current Key Generation Number in the
group.  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 MAY serve additional principals acting as signature
checkers, e.g., intermediary gateways.  These principals do not join
a group as members, but can retrieve public keys of group members and
other selected group data from the Group Manager, in order to solely
verify countersignatures of messages protected in group mode (see
sec-processing-signature-checker).
In order to verify countersignatures of messages in a group, a
signature checker needs to retrieve the following information about
that group from the Group Manager.
The current ID Context (Gid) used in the group.
The public keys of the group members and the public key of the
Group Manager.
The current Group Encryption Key (see ssec-common-context-group-
enc-key).
The identifiers of the algorithms used in the group (see sec-
context), i.e.: i) Signature Encryption Algorithm and Signature
Algorithm; and ii) AEAD Algorithm and Pairwise Key Agreement
Algorithm, if the group uses also the pairwise mode.
A signature checker MUST be authorized before it can retrieve such
information.  To this end, the same method mentioned above based on
the ACE framework I-D.ietf-ace-oauth-authz can be used.
In order to establish a new Security Context for a group, the Group
Manager MUST generate and assign to the group a new Group Identifier
(Gid) and a new value for the Master Secret parameter.  When doing
so, a new value for the Master Salt parameter MAY also be generated
and assigned to the group.  When establishing the new Security
Context, the Group Manager should preserve the current value of the
Sender ID of each group member.
The specific group key management scheme used to distribute new
keying material, is out of the scope of this document.  However, it
is RECOMMENDED that the Group Manager supports the Group Rekeying
Process described in I-D.ietf-ace-key-groupcomm-oscore.  When
possible, the delivery of rekeying messages should use a reliable
transport, in order to reduce chances of group members missing a
rekeying instance.
The set of group members should not be assumed as fixed, i.e., the
group membership is subject to changes, possibly on a frequent basis.
The Group Manager MUST rekey the group when one or more currently
present endpoints leave the group, or in order to evict them as
compromised or suspected so.  In either case, this excludes such
nodes from future communications in the group, and thus preserves
forward security.  If required by the application, the Group Manager
MUST rekey the group also before one or more new joining endpoints
are added to the group, thus preserving backward security.
The establishment of the new Security Context for the group takes the
following steps.
The Group Manager MUST increment by 1 the Key Generation Number
for the group.
The Group Manager MUST evict the elder members from the group.
That is, the Group Manager MUST terminate their membership and
MUST rekey the group in such a way that the new keying material
is not provided to those evicted elder members.  This ensures
that an Observe notification RFC7641 can never successfully
match against the Observe requests of two different
observations.
Until a further following group rekeying, the Group Manager
MUST store the list of those latest-evicted elder members.  If
any of those endpoints re-joins the group before a further
following group rekeying occurs, the Group Manager MUST NOT
rekey the group upon their re-joining.  When one of those
endpoints re-joins the group, the Group Manager can rely, e.g.,
on the ongoing secure communication association to recognize
the endpoint as included in the stored list.
The Sender IDs that, during the current Gid, were both assigned
to an endpoint and subsequently relinquished (see new-sender-
id).
The current Sender IDs of the group members that the upcoming
group rekeying aims to exclude from future group
communications, if any.
The new keying material, i.e., the new Master Secret, the new
Gid and (optionally) the new Master Salt.
The new Key Generation Number from step 1.
The set of stale Sender IDs from step 3.
Further information may be distributed, depending on the specific
group key management scheme used in the group.
When receiving the new group keying materal, a group member MUST
delete all its Recipient Contexts whose corresponding Recipient ID is
included in the received set of stale Sender IDs.  After that, the
group member installs the new keying material and derives the
corresponding new Security Context.
A group member might miss one group rekeying or more consecutive
instances.  As a result, the group member will retain old group
keying material with Key Generation Number GEN_OLD.  Eventually, the
group member can notice the discrepancy, e.g., by repeatedly failing
to verify incoming messages, or by explicitly querying the Group
Manager for the current Key Generation Number.  Once the group member
has knowledge to have missed a group rekeying, it proceed as follows.
The group member retrieves from the Group Manager the current
group keying material, together the current with Key Generation
Number GEN_NEW.  The group member MUST NOT install the obtained
group keying material yet.
The group member asks the Group Manager which Recipient Contexts
it should delete, as related to endpoints that are not current
group members.  Following the indications from the Group Manager,
the group member MUST delete such Recipient Contexts.  If no exact
indication can be obtained from the Group Manager, the group
member MUST delete all its Recipient Contexts.
The group member installs the current group keying material, and
derives the corresponding new Security Context.
Alternatively, the group member can more simply re-join the group.
In such a case, the group member MUST take one of the following two
actions.
Before re-joining, the group member asks the Group Manager which
Recipient Contexts it should delete, as related to endpoints that
are not current group members.  Then, the group member deletes
such Recipient Contexts, or all its Recipient Contexts if no exact
indication can be obtained from the Group Manager.
Upon re-joining, the group member asks the Group Manager for the
public keys of all the group members.  Then, it deletes each of
its Recipient Contexts that does not include any of the public
keys received from the Group Manager.
By deleting stale Recipient Contexts and public keys associated to
former group members, it is ensured that a recipient endpoint owning
the latest group keying material does not store the public keys of
sender endpoints that are not current group members.  This in turn
allows group members to rely on owned public keys to confidently
assert the group membership of sender endpoints, when receiving
incoming messages protected in group mode (see mess-processing).
Although the Gid value changes every time a group is rekeyed, the
Group Manager can reassign a Gid to the same group over that group's
lifetime.  This would happen, for instance, once the whole space of
Gid values has been used for the group in question.
From the moment when a Gid is assigned to a group until the moment a
new Gid is assigned to that same group, the Group Manager MUST NOT
reassign a Sender ID within the group.  This prevents to reuse a
Sender ID ('kid') with the same Gid, Master Secret and Master Salt.
Within this restriction, the Group Manager can assign a Sender ID
used under an old Gid value (including under a same, recycled 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.
If required by the application (see ssec-sec-assumptions), it is
RECOMMENDED to adopt a group key management scheme, and securely
distribute a new value for the Gid and for the Master Secret
parameter of the group's Security Context, before a new joining
endpoint is added to the group or after a currently present endpoint
leaves the group.  This is necessary to preserve backward security
and forward security in the group, if the application requires it.
The specific approach used to distribute new group data is out of the
scope of this document.  However, it is RECOMMENDED that the Group
Manager supports the distribution of the new Gid and Master Secret
parameter to the group according to the Group Rekeying Process
described in I-D.ietf-ace-key-groupcomm-oscore.
Creating and managing OSCORE groups.  This includes the assignment
of a Gid to every newly created group, as well as ensuring
uniqueness of Gids within the set of its OSCORE groups.
Creating and managing OSCORE groups.  This includes the assignment
of a Gid to every newly created group, ensuring uniqueness of Gids
within the set of its OSCORE groups, and tracking the Birth Gids
of current group members in each group.
Updating the Gid of its OSCORE groups, upon renewing the
respective Security Context.  This includes ensuring that the same
Gid value is not reassigned to the same group.
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.
Updating the Key Generation Number and the Gid of its OSCORE
groups, upon renewing the respective Security Context.
Each Sender ID is not reassigned within the same group since
the latest time when the current Gid value was assigned to the
group.  That is, the Sender ID is not reassigned even to a
current group member re-joining the same group, without a
rekeying happening first.
Assisting a group member that has missed a group rekeying instance
to understand which Recipient Contexts to delete, as associated to
former group members.
COSE_CounterSignature0: its value is set to the counter signature
of the COSE object, computed by the sender as described in
Sections 3.2 and 3.3 of I-D.ietf-cose-countersign, by using its
private key and according to the Counter Signature Algorithm and
Counter Signature Parameters in the Security Context.
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 countersignature of the COSE object, namely SIGNATURE, is
computed by the sender as described in Sections 3.2 and 3.3 of
I-D.ietf-cose-countersign, by using its private key and
according to the Signature Algorithm in the Security Context.
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 following defines how an endpoint derives the keystream
KEYSTREAM, used to encrypt/decrypt the countersignature of an
outgoing/incoming message M protected in group mode.
The keystream SHALL be derived as follows, by using the HKDF
Algorithm from the Common Context (see Section 3.2 of RFC8613), which
consists of composing the HKDF-Extract and HKDF-Expand steps RFC5869.
The input parameters of HKDF are as follows.
salt takes as value the Partial IV (PIV) used to protect M.  Note
that, if M is a response, salt takes as value either: i) the fresh
Partial IV generated by the server and included in the response;
or ii) the same Partial IV of the request generated by the client
and not included in the response.
IKM is the Group Encryption Key from the Common Context (see ssec-
common-context-group-enc-key).
id is the Sender ID of the endpoint that generated PIV.
id_context is the ID Context (Gid) used when protecting M.
Note that, in case of group rekeying, a server might use a
different Gid when protecting a response, compared to the Gid that
it used to verify (that the client used to protect) the request,
see ssec-protect-response.
type is the CBOR simple value True (0xf5) if M is a request, or
the CBOR simple value False (0xf4) otherwise.
L is the size of the countersignature, as per Signature Algorithm
from the Common Context (see ssec-common-context-cs-alg), in
bytes.
Note that the literature commonly refers to a countersignature as a
signature computed by a principal A over a document already protected
by a different principal B.
However, the COSE_Countersignature0 structure belongs to the set of
abbreviated countersignatures defined in Sections 3.2 and 3.3 of I-
D.ietf-cose-countersign, which were designed primarily to deal with
the problem of encrypted group messaging, but where it is required to
know who originated the message.
Since the parameters for computing or verifying the abbreviated
countersignature generated by A are provided by the same context used
to describe the security processing performed by B and to be
countersigned, these structures are applicable also when the two
principals A and B are actually the same one, like the sender of a
Group OSCORE message protected in group mode.
The value of the 'kid context' parameter in the 'unprotected' field
of requests messages MUST be set to the ID Context, i.e. the Group
Identifier value (Gid) of the group.  That is, unlike in RFC8613, the
'kid context' parameter is always present in requests.
The value of the 'kid context' parameter in the 'unprotected' field
of requests messages MUST be set to the ID Context, i.e., the Group
Identifier value (Gid) of the group.  That is, unlike in RFC8613, the
'kid context' parameter is always present in requests.
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.
'alg_countersign', which specifies Counter Signature Algorithm
from the Common Context (see ssec-common-context-cs-alg).  This
parameter MUST encode the value of Counter Signature Algorithm
as a CBOR integer or text string, consistently with the "Value"
field in the "COSE Algorithms" Registry for this counter
signature algorithm.
'countersign_alg_capab' is the array of COSE capabilities
for the countersignature algorithm indicated in
'alg_countersign'.  This is the first element of the CBOR
array Counter Signature Parameters from the Common Context.
'countersign_key_type_capab' is the array of COSE
capabilities for the COSE key type used by the
countersignature algorithm indicated in 'alg_countersign'.
This is the second element of the CBOR array Counter
Signature Parameters from the Common Context.
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.
In particular, the external_aad includes also the signature
algorithm, the signature encryption algorithm, the pairwise key
agreement algorithm, the value of the 'kid context' in the COSE
object of the request, the OSCORE option of the protected message,
and the sender's public key.
The 'algorithms' array is extended as follows.
The parameter 'alg_aead' MUST be set to the CBOR simple value Null
if the group does not use the pairwise mode, regardless whether
the endpoint supports the pairwise mode.  Otherwise, this
parameter MUST encode the value of AEAD Algorithm from the Common
Context (see ssec-common-context-aead-alg), as per Section 5.4 of
RFC8613.
'alg_signature_enc', which specifies Signature Encryption
Algorithm from the Common Context (see ssec-common-context-cs-
alg).  This parameter MUST be set to the CBOR simple value Null
if the group does not use the group mode, regardless whether
the endpoint supports the group mode.  Otherwise, this
parameter MUST encode the value of Signature Encryption
Algorithm as a CBOR integer or text string, consistently with
the "Value" field in the "COSE Algorithms" Registry for this
AEAD algorithm.
'alg_signature', which specifies Signature Algorithm from the
Common Context (see ssec-common-context-cs-alg).  This
parameter MUST be set to the CBOR simple value Null if the
group does not use the group mode, regardless whether the
endpoint supports the group mode.  Otherwise, this parameter
MUST encode the value of Signature Algorithm as a CBOR integer
or text string, consistently with the "Value" field in the
"COSE Algorithms" Registry for this signature algorithm.
'alg_pairwise_key_agreement', which specifies Pairwise Key
Agreement Algorithm from the Common Context (see ssec-common-
context-cs-alg).  This parameter MUST be set to the CBOR simple
value Null if the group does not use the pairwise mode,
regardless whether the endpoint supports the pairwise mode.
Otherwise, this parameter MUST encode the value of Pairwise Key
Agreement Algorithm as a CBOR integer or text string,
consistently with the "Value" field in the "COSE Algorithms"
Registry for this KDF algorithm.
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.
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.
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
countersignature (when using the group mode).  Also, the aad_array
needs to be large enough to contain the largest possible OSCORE
option.
The new element 'sender_public_key', containing the sender's
public key.  An X.509 certificate is encoded as a CBOR byte
string.  A C509 certificate, a CWT, or a CWT claim set is encoded
as a CBOR array, and might be tagged.
The new element 'gm_public_key', containing the Group Manager's
public key.  An X.509 certificate is encoded as a CBOR byte
string.  A C509 certificate, a CWT, or a CWT claim set is encoded
as a CBOR array, and might be tagged.  If no Group Manager is used
for maintaining the group, this parameter MUST encode the CBOR
simple value Null.
The examples assume that the COSE_Encrypt0 object is set (which means
the CoAP message and cryptographic material is known).  Note that the
examples do not include the full CoAP unprotected message or the full
Security Context, but only the input necessary to the compression
mechanism, i.e. the COSE_Encrypt0 object.  The output is the
compressed COSE object as defined in compression and divided into two
parts, since the object is transported in two CoAP fields: OSCORE
option and payload.
The examples assume that the COSE_Encrypt0 object is set (which means
the CoAP message and cryptographic material is known).  Note that the
examples do not include the full CoAP unprotected message or the full
Security Context, but only the input necessary to the compression
mechanism, i.e., the COSE_Encrypt0 object.  The output is the
compressed COSE object as defined in compression and divided into two
parts, since the object is transported in two CoAP fields: OSCORE
option and payload.
When Observe RFC7641 is used, a client maintains for each ongoing
observation one Notification Number for each different server.  Then,
separately for each server, the client uses the associated
Notification Number to perform ordering and replay protection of
notifications received from that server (see ssec-verify-response-
observe).
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.
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.
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.
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.
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.
To this end, an endpoint can take into account the different
structure of the Security Context defined in sec-context, for example
based on the presence of Counter Signature Algorithm in the Common
Context.  Alternatively implementations can use an additional
parameter in the Security Context, to explicitly signal that it is
intended for processing Group OSCORE messages.
To this end, an endpoint can take into account the different
structure of the Security Context defined in sec-context, for example
based on the presence of Countersignature Algorithm in the Common
Context.  Alternatively implementations can use an additional
parameter in the Security Context, to explicitly signal that it is
intended for processing Group OSCORE messages.
When using the group mode, messages are protected and processed as
specified in RFC8613, with the modifications described in this
section.  The security objectives of the group mode are discussed in
ssec-sec-objectives.  The group mode MUST be supported.
When using the group mode, messages are protected and processed as
specified in RFC8613, with the modifications described in this
section.  The security objectives of the group mode are discussed in
ssec-sec-objectives.
The Group Manager indicates that the group uses (also) the group
mode, as part of the group data provided to candidate group members
when joining 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.
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.
In step 4, the encryption of the COSE object is modified as
described in sec-cose-object of this document.  The encoding of
the compressed COSE object is modified as described in compression
of this document.  In particular, the Group Flag MUST be set to 1.
In step 5, the counter signature is computed and the format of the
OSCORE message is modified as described in sec-cose-object and
compression of this document.  In particular, the payload of the
OSCORE message includes also the counter signature.
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.
The server MUST perform signature verification 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 signature verification fails, the server SHALL stop
processing the request, SHALL NOT update the Replay Window, 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.
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.
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 Sections 7.2.1 and 7.2.4
of I-D.ietf-core-observe-multicast-notifications.
In step 4, the encryption of the COSE object is modified as
described in sec-cose-object of this document.  The encoding of
the compressed COSE object is modified as described in compression
of this document.  In particular, the Group Flag MUST be set to 1.
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), then the new ID Context MUST be included in
the 'kid context' parameter of the response.
In step 5, the counter signature is computed and the format of the
OSCORE message is modified as described in compression of this
document.  In particular, the payload of the OSCORE message
includes also the counter signature.
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), then the new ID Context MUST be included in
the 'kid context' parameter of the response.
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 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.
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 the Recipient ID for the server to which
the request protected in pairwise mode was intended for.
In step 5, the client also verifies the counter signature using
the public key of the server from the associated Recipient
Context.  If the verification fails, the same steps are taken as
if the decryption had failed.
The client MUST perform signature verification 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 to 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.
If this is not the case, 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 Recipient Public Key taken as
input to derive the Pairwise Sender Key used for protecting
the request (see key-derivation-pairwise).
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.
The ordering and the replay protection of notifications received
from a server are performed as per Sections 4.1.3.5.2 and 7.4.1 of
RFC8613, by using the Notification Number associated to that
server for the observation in question.  In addition, the client
performs the following actions for each ongoing observation.
When receiving the first valid notification from a server, the
client MUST store the current kid "kid1" of that server for the
observation in question.  If the 'kid' field is included in the
OSCORE option of the notification, its value specifies "kid1".
If the Observe request was protected in pairwise mode (see sec-
pairwise-protection-req), the 'kid' field may not be present in
the OSCORE option of the notification (see sec-cose-object-
kid).  In this case, the client assumes "kid1" to be the
Recipient ID for the server to which the Observe request was
intended for.
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 - 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.
Note that, if "kid2" is different from "kid1" and the 'kid'
field is omitted from the notification - which is possible if
the Observe request was protected in pairwise mode - then the
client will fail to decrypt and verify the notification, as
using the Pairwise Recipient Key for that server bound to the
Recipient ID "kid1".
This ensures that the client remains able to correctly perform the
ordering and replay protection of notifications, 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.
When receiving a message protected in group mode, a signature checker
(see sec-additional-principals) proceeds as follows.
The signature checker verifies the original countersignature
SIGNATURE, by using the public key of the sender endpoint.  The
signature checker determines the public key to use based on the ID
Context (Gid) and the Sender ID of the sender endpoint.
Note that the following applies when attempting to verify the
countersignature of a response message.
The response may not include a Partial IV and/or an ID Context.
In such a case, the signature checker considers the same values
from the corresponding request, i.e., the request matching with
the response by CoAP Token value.
The response may not include a Sender ID.  This can happen when
the response protected in group mode matches a request protected
in pairwise mode (see ssec-pre-conditions), with a case in point
provided by I-D.amsuess-core-cachable-oscore.  In such a case, the
signature checker needs to use other means (e.g., source
addressing information of the server endpoint) to identify the
correct public key to use for verifying the countersignature of
the response.
The particular actions following a successful or unsuccessful
verification of the countersignature are application specific and out
of the scope of this document.
The pairwise mode takes advantage of an existing Security Context for
the group mode to establish a Security Context shared exclusively
with any other member.  In order to use the pairwise mode, the
signature scheme of the group mode MUST support a combined signature
and encryption scheme.  This can be, for example, signature using
ECDSA, and encryption using AES-CCM with a key derived with ECDH.
The pairwise mode MAY be supported.  An endpoint implementing only a
silent server does not support the pairwise mode.
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.
The pairwise mode takes advantage of an existing Security Context for
the group mode to establish a Security Context shared exclusively
with any other member.  In order to use the pairwise mode, the
signature scheme of the group mode MUST support a combined signature
and encryption scheme.  This can be, for example, signature using
ECDSA, and encryption using AES-CCM with a key derived with ECDH.
For encryption and decryption operations, the AEAD Algorithm from the
Common Context is used (see ssec-common-context-aead-alg).
An endpoint implementing only a silent server does not support the
pairwise mode.
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.8 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.
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.
The Group Manager MAY indicate that the group uses also the pairwise
mode, as part of the group data provided to candidate group members
when joining the group.
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.
The Group Manager indicates that the group uses (also) the pairwise
mode, as part of the group data provided to candidate group members
when joining the group.
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.
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.
The same as described in ssec-verify-response holds with respect
to handling the 'kid' parameter of the response, when received as
a reply to a request protected in pairwise mode.  The client can
also in this case check whether the replying server is the
expected one, by relying on the server's public key.  However,
since the response is protected in pairwise mode, the public key
is not used for verifying a countersignature as in ssec-verify-
response, but rather as input to derive the Pairwise Recipient Key
used to decrypt and verify the response (see key-derivation-
pairwise).
If Observe RFC7641 is supported, what defined in ssec-verify-
response-observe of this document holds.
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
counter signatures, as discussed in ssec-group-level-security.
If Observe RFC7641 is supported, what defined in ssec-verify-
response-observe of this document holds.  The client can also in
this case identify a server to be the same one across a change of
Sender ID, by relying on the server's public key.  However, since
the notification is protected in pairwise mode, the public key is
not used for verifying a countersignature as in ssec-verify-
response, but rather as input to derive the Pairwise Recipient Key
used to decrypt and verify the notification (see key-derivation-
pairwise).
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 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.
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 group mode described in mess-processing relies on commonly shared
group keying material to protect communication within a group.  This
has the following implications.
Messages are encrypted at a group level (group-level data
confidentiality), i.e. they can be decrypted by any member of the
group, but not by an external adversary or other external
entities.
The AEAD algorithm provides only group authentication, i.e. it
ensures that a message sent to a group has been sent by a member
of that group, but not necessarily by the alleged sender.  This is
why source authentication of messages sent to a group is ensured
through a counter signature, which is computed by the sender using
its own private key and then appended to the message payload.
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.
The group mode defined in mess-processing relies on commonly shared
group keying material to protect communication within a group.  Using
the group mode has the implications discussed below.  The following
refers to group members as the endpoints in the group owning the
latest version of the group keying material.
Messages are encrypted at a group level (group-level data
confidentiality), i.e., they can be decrypted by any member of the
group, but not by an external adversary or other external
entities.
If the used encryption algorithm provides integrity protection,
then it also ensures group authentication and proof of group
membership, but not source authentication.  That is, it ensures
that a message sent to a group has been sent by a member of that
group, but not necessarily by the alleged sender.  In fact, any
group member is able to derive the Sender Key used by the actual
sender endpoint, and thus can compute a valid authentication tag.
Therefore, the message content could originate from any of the
current group members.
Furthermore, if the used encryption algorithm does not provide
integrity protection, then it does not ensure any level of message
authentication or proof of group membership.
On the other hand, proof of group membership is ensured by the
strict management of the group keying material (see sec-group-key-
management).  That is, the group is rekeyed in case of nodes'
leaving, and the current group members are informed of former
group members.  Thus, a current group member owning the latest
group keying material does not own the public key of any former
group member.
This allows a recipient endpoint to rely on the owned public keys
to confidently assert the group membership of a sender endpoint
when processing an incoming message, i.e., to assert that the
sender endpoint was a group member when it signed the message.  In
turn, this prevents a former group member to possibly re-sign and
inject in the group a stored message that was protected with old
keying material.
Source authentication of messages sent to a group is ensured
through a countersignature, which is computed by the sender using
its own private key and then appended to the message payload.
Also, the countersignature is encrypted by using a keystream
derived from the group keying material (see sec-cose-object-
unprotected-field).  This ensures group privacy, i.e., an attacker
cannot track an endpoint over two groups by linking messages
between the two groups, unless being also a member of those
groups.
The security properties of the group mode are summarized below.
Asymmetric source authentication, by means of a countersignature.
Symmetric group authentication, by means of an authentication tag
(only for encryption algorithms providing integrity protection).
Symmetric group confidentiality, by means of symmetric encryption.
Proof of group membership, by strictly managing the group keying
material, as well as by means of integrity tags when using an
encryption algorithm that provides also integrity protection.
Group privacy, by encrypting the countersignature.
The group mode fulfills the security properties above while also
displaying the following benefits.  First, the use of encryption
algorithm that does not provide integrity protection results in a
minimal communication overhead, by limiting the message payload to
the ciphertext and the encrypted countersignature.  Second, it is
possible to deploy semi-trusted principals such as signature checkers
(see sec-additional-principals), which can break property 5, but
cannot break properties 1, 2 and 3.
The pairwise mode defined 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).
The used encryption algorithm MUST provide integrity protection.
Therefore, the pairwise mode ensures both pairwise data-
confidentiality and source authentication of messages, without using
countersignatures.  Furthermore, the recipient endpoint achieves
proof of group membership for the sender endpoint, since only current
group members have the required keying material to derive a valid
Pairwise Sender/Recipient Key.
The long-term storing of the Diffie-Hellman shared secret is a
potential security issue.  In fact, if the shared secret of two group
members is leaked, a third group member can exploit it to impersonate
any of those two group members, by deriving and using their pairwise
key.  The possibility of such leakage should be contemplated, as more
likely to happen than the leakage of a private key, which could be
rather protected at a significantly higher level than generic memory,
e.g. by using a Trusted Platform Module.  Therefore, there is a
trade-off between the maximum amount of time a same shared secret is
stored and the frequency of its re-computing.
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.
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 long-term storing of the Diffie-Hellman shared secret is a
potential security issue.  In fact, if the shared secret of two group
members is leaked, a third group member can exploit it to impersonate
any of those two group members, by deriving and using their pairwise
key.  The possibility of such leakage should be contemplated, as more
likely to happen than the leakage of a private key, which could be
rather protected at a significantly higher level than generic memory,
e.g., by using a Trusted Platform Module.  Therefore, there is a
trade-off between the maximum amount of time a same shared secret is
stored and the frequency of its re-computing.
Uniqueness of Sender IDs within the group is enforced by the Group
Manager.  In fact, from the moment when a Gid is assigned to a
group until the moment a new Gid is assigned to that same group,
the Group Manager does not reassign a Sender ID within the group
(see sec-group-key-management).
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 approach described in this specification should take into account
the risk of compromise of group members.  In particular, this
document specifies that a key management scheme for secure revocation
and renewal of Security Contexts and group keying material should be
adopted.
The approach described in this specification should take into account
the risk of compromise of group members.  In particular, this
document specifies that a key management scheme for secure revocation
and renewal of Security Contexts and group keying material MUST be
adopted.
In case block-wise transfer RFC7959 is used, the same considerations
from Section 7.2 of I-D.ietf-ace-key-groupcomm hold.
In this case, the sender protects a message using the old Security
Context, i.e. before having installed the new Security Context.
However, the recipient receives the message after having installed
the new Security Context, and is thus unable to correctly process it.
In case block-wise transfer RFC7959 is used, the same considerations
from Section 9.2 of I-D.ietf-ace-key-groupcomm hold.
In this case, the sender protects a message using the old Security
Context, i.e., before having installed the new Security Context.
However, the recipient receives the message after having installed
the new Security Context, and is thus unable to correctly process it.
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).
Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and
Gid2, respectively.  Both G1 and G2 use the AEAD cipher AES-CCM-
16-64-128, i.e. the MAC of the ciphertext is 8 bytes in size.
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 countersignature also bound to the OSCORE option
through the Additional Authenticated Data used in the signing process
(see sec-cose-object-ext-aad).
Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and
Gid2, respectively.  Both G1 and G2 use the AEAD cipher AES-CCM-
16-64-128, i.e., the MAC of the ciphertext is 8 bytes in size.
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).
When a Group OSCORE message is protected with the group mode, the
countersignature 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).
If the client uses the group mode with its own Sender Key to protect
a unicast request to a group member, an on-path adversary can, right
then or later on, redirect that request to one/many different group
member(s) over unicast, or to the whole OSCORE group over multicast.
By doing so, the adversary can induce the target group member(s) to
perform actions intended for one group member only.  Note that the
adversary can be external, i.e. (s)he does not need to also be a
member of the OSCORE group.
If the client uses the group mode with its own Sender Key to protect
a unicast request to a group member, an on-path adversary can, right
then or later on, redirect that request to one/many different group
member(s) over unicast, or to the whole OSCORE group over multicast.
By doing so, the adversary can induce the target group member(s) to
perform actions intended for one group member only.  Note that the
adversary can be external, i.e., (s)he does not need to also be a
member of the OSCORE group.
The impact of such an attack depends especially on the REST method of
the request, i.e. the Inner CoAP Code of the OSCORE request message.
In particular, safe methods such as GET and FETCH would trigger
(several) unintended responses from the targeted server(s), while not
resulting in destructive behavior.  On the other hand, non safe
methods such as PUT, POST and PATCH/iPATCH would result in the target
server(s) taking active actions on their resources and possible
cyber-physical environment, with the risk of destructive consequences
and possible implications for safety.
The impact of such an attack depends especially on the REST method of
the request, i.e., the Inner CoAP Code of the OSCORE request message.
In particular, safe methods such as GET and FETCH would trigger
(several) unintended responses from the targeted server(s), while not
resulting in destructive behavior.  On the other hand, non safe
methods such as PUT, POST and PATCH/iPATCH would result in the target
server(s) taking active actions on their resources and possible
cyber-physical environment, with the risk of destructive consequences
and possible implications for safety.
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.
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
Sections 7.2.1 and 7.2.4 of I-D.ietf-core-observe-multicast-
notifications.
With particular reference to block-wise transfers RFC7959,
Section 3.8 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.
The EdDSA signature algorithm and the elliptic curve Ed25519 RFC8032
are mandatory to implement.  For endpoints that support the pairwise
mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of
I-D.ietf-cose-rfc8152bis-algs and the X25519 curve RFC7748 are also
mandatory to implement.
For endpoints that support the group mode, the EdDSA signature
algorithm Ed25519 RFC8032 is mandatory to implement.  The group mode
uses the "encrypt-then-sign" construction, i.e., the countersignature
is computed over the COSE_Encrypt0 object (see sec-cose-object-
unprotected-field).  This is motivated by enabling additional
principals acting as signature checkers (see sec-additional-
principals), which do not join a group as members but are allowed to
verify countersignatures of messages protected in group mode without
being able to decrypt them (see sec-processing-signature-checker).
If the encryption algorithm used in group mode provides integrity
protection, countersignatures of COSE_Encrypt0 with short
authentication tags do not provide the security properties associated
with the same algorithm used in COSE_Sign (see Section 6 of I-D.ietf-
cose-countersign).  To provide 128-bit security against collision
attacks, the tag length MUST be at least 256-bits.  A
countersignature of a COSE_Encrypt0 with AES-CCM-16-64-128 provides
at most 32 bits of integrity protection.
For endpoints that support the pairwise mode, the ECDH-SS + HKDF-256
algorithm specified in Section 6.3.1 of I-D.ietf-cose-rfc8152bis-algs
and the X25519 algorithm RFC7748 are also mandatory to implement.
The derivation of pairwise keys defined in key-derivation-pairwise is
compatible with ECDSA and EdDSA asymmetric keys, but is not
compatible with RSA asymmetric keys.  The security of using the same
key pair for Diffie-Hellman and for signing is demonstrated in
Degabriele.
Group OSCORE ensures end-to-end integrity protection and encryption
of the message payload and all options that are not used for proxy
operations.  In particular, options are processed according to the
same class U/I/E that they have for OSCORE.  Therefore, the same
privacy considerations from Section 12.8 of RFC8613 hold for Group
OSCORE.
The derivation of pairwise keys defined in key-derivation-pairwise is
compatible with ECDSA and EdDSA asymmetric keys, but is not
compatible with RSA asymmetric keys.
For the public key translation from Ed25519 (Ed448) to X25519 (X448)
specified in key-derivation-pairwise, variable time methods can be
used since the translation operates on public information.  Any byte
string of appropriate length is accepted as a public key for X25519
(X448) in RFC7748.  It is therefore not necessary for security to
validate the translated public key (assuming the translation was
successful).
The security of using the same key pair for Diffie-Hellman and for
signing (by considering the ECDH procedure in sec-derivation-pairwise
as a Key Encapsulation Mechanism (KEM)) is demonstrated in Degabriele
and Thormarker.
Applications using ECDH (except X25519 and X448) based KEM in sec-
derivation-pairwise are assumed to verify that a peer endpoint's
public key is on the expected curve and that the shared secret is not
the point at infinity.  The KEM in Degabriele checks that the shared
secret is different from the point at infinity, as does the procedure
in Section 5.7.1.2 of NIST-800-56A which is referenced in sec-
derivation-pairwise.
Extending Theorem 2 of Degabriele, Thormarker shows that the same key
pair can be used with X25519 and Ed25519 (X448 and Ed448) for the KEM
specified in sec-derivation-pairwise.  By symmetry in the KEM used in
this document, both endpoints can consider themselves to have the
recipient role in the KEM - as discussed in Section 7 of Thormarker -
and rely on the mentioned proofs for the security of their key pairs.
Theorem 3 in Degabriele shows that the same key pair can be used for
an ECDH based KEM and ECDSA.  The KEM uses a different KDF than in
sec-derivation-pairwise, but the proof only depends on that the KDF
has certain required properties, which are the typical assumptions
about HKDF, e.g., that output keys are pseudorandom.  In order to
comply with the assumptions of Theorem 3, received public keys MUST
be successfully validated, see Section 5.6.2.3.4 of NIST-800-56A.
The validation MAY be performed by a trusted Group Manager.  For
Degabriele to apply as it is written, public keys need to be in the
expected subgroup.  For this we rely on cofactor DH, Section 5.7.1.2
of NIST-800-56A which is referenced in sec-derivation-pairwise.
HashEdDSA variants of Ed25519 and Ed448 are not used by COSE, see
Section 2.2 of I-D.ietf-cose-rfc8152bis-algs, and are not covered by
the analysis in Thormarker, and hence MUST NOT be used with the
public keys used with pairwise keys as specified in this document.
Group OSCORE ensures end-to-end integrity protection and encryption
of the message payload and all options that are not used for proxy
operations.  In particular, options are processed according to the
same class U/I/E that they have for OSCORE.  Therefore, the same
privacy considerations from Section 12.8 of RFC8613 hold for Group
OSCORE, with the following addition.
When protecting a message in group mode, the countersignature is
encrypted by using a keystream derived from the group keying
material (see sec-cose-object-unprotected-field and sssec-
encrypted-signature-keystream).  This ensures group privacy.  That
is, an attacker cannot track an endpoint over two groups by
linking messages between the two groups, unless being also a
member of those groups.
Finally, the mechanism described in ssec-gid-collision to prevent
collisions of Group Identifiers from different Group Managers may
reveal information about events in the respective OSCORE groups.  In
particular, a Group Identifier changes when the corresponding group
is rekeyed.  Thus, Group Managers might use the shared list of Group
Identifiers to infer the rate and patterns of group membership
changes triggering a group rekeying, e.g. due to newly joined members
or evicted (compromised) members.  In order to alleviate this privacy
concern, it should be hidden from the Group Managers which exact
Group Manager has currently assigned which Group Identifiers in its
OSCORE groups.
Finally, the mechanism described in ssec-gid-collision to prevent
collisions of Group Identifiers from different Group Managers may
reveal information about events in the respective OSCORE groups.  In
particular, a Group Identifier changes when the corresponding group
is rekeyed.  Thus, Group Managers might use the shared list of Group
Identifiers to infer the rate and patterns of group membership
changes triggering a group rekeying, e.g., due to newly joined
members or evicted (compromised) members.  In order to alleviate this
privacy concern, it should be hidden from the Group Managers which
exact Group Manager has currently assigned which Group Identifiers in
its OSCORE groups.