Draft: draft-ietf-core-oscore-groupcomm

Commentary: and application dependent 
 for when signature verification fails on server . Should be 4.00 . ( Section 6 . Note that it is not RECOMMENDED to send error messages back ) .
Object Security for Constrained RESTful Environments (OSCORE)I-
D.ietf-core-object-security describes a security protocol based on
the exchange of protected CoAP messages.  OSCORE builds on CBOR
Object Signing and Encryption (COSE) RFC8152 and provides end-to-end
encryption, integrity, replay protection and binding of response to
request between a sender and a receipient, also in the presence of
intermediaries.  To this end, a CoAP message is protected by
including its payload (if any), certain options, and header fields in
a COSE object, which replaces the authenticated and encrypted fields
in the protected message.
Object Security for Constrained RESTful Environments (OSCORE) RFC8613
describes a security protocol based on the exchange of protected CoAP
messages.  OSCORE builds on CBOR Object Signing and Encryption (COSE)
RFC8152 and provides end-to-end encryption, integrity, replay
protection and binding of response to request between a sender and a
receipient, also in the presence of intermediaries.  To this end, a
CoAP message is protected by including its payload (if any), certain
options, and header fields in a COSE object, which replaces the
authenticated and encrypted fields in the protected message.
Readers are also expected to be familiar with the terms and concepts
for protection and processing of CoAP messages through OSCORE, such
as "Security Context" and "Master Secret", defined in I-D.ietf-core-
object-security.
Readers are also expected to be familiar with the terms and concepts
for protection and processing of CoAP messages through OSCORE, such
as "Security Context" and "Master Secret", defined in RFC8613.
Group Identifier (Gid): identifier assigned to the group.  Group
Identifiers should be unique within the set of groups of a given
Group Manager, in order to avoid collisions.  In case they are
not, the considerations in ssec-gid-collision apply.
Group Identifier (Gid): identifier assigned to the group.  Group
Identifiers must be unique within the set of groups of a given
Group Manager.
one Sender Context, unless the endpoint is configured exclusively
as silent server.  The Sender Context is used to secure outgoing
messages and is initialized according to Section 3 of I-D.ietf-
core-object-security, once the endpoint has joined the group.  The
Sender Context of a given endpoint matches the corresponding
Recipient Context in all the endpoints receiving a protected
message from that endpoint.  Besides, in addition to what is
defined in I-D.ietf-core-object-security, the Sender Context
stores also the endpoint's private key.
one Recipient Context for each distinct endpoint from which
messages are received, used to process incoming messages.  The
recipient may generate the Recipient Context upon receiving an
incoming message from another endpoint in the group for the first
time (see ssec-verify-request and ssec-verify-response).  Each
Recipient Context matches the Sender Context of the endpoint from
which protected messages are received.  Besides, in addition to
what is defined in I-D.ietf-core-object-security, each Recipient
Context stores also the public key of the associated other
endpoint from which messages are received.  Note that each
Recipient Context includes a Replay Window, unless the recipient
acts only as client and hence processes only responses as incoming
messages.
The table in fig-additional-context-information overviews the new
information included in the OSCORE Security Context, with respect to
what defined in Section 3 of I-D.ietf-core-object-security.
one Sender Context, unless the endpoint is configured exclusively
as silent server.  The Sender Context is used to secure outgoing
messages and is initialized according to Section 3 of RFC8613,
once the endpoint has joined the group.  The Sender Context of a
given endpoint matches the corresponding Recipient Context in all
the endpoints receiving a protected message from that endpoint.
Besides, in addition to what is defined in RFC8613, the Sender
Context stores also the endpoint's private key.
one Recipient Context for each distinct endpoint from which
messages are received, used to process incoming messages.  The
recipient may generate a Recipient Context whenever in possession
of all the required pieces of information on the corresponding
endpoint, e.g. they may be provided to the recipient upon joining
the group.  Alternatively, the recipient may generate a Recipient
Context upon receiving an incoming message from another endpoint
in the group for the first time (see ssec-verify-request and ssec-
verify-response).  Each Recipient Context matches the Sender
Context of the endpoint from which protected messages are
received.  Besides, in addition to what is defined in RFC8613,
each Recipient Context stores also the public key of the
associated other endpoint from which messages are received.  Note
that each Recipient Context includes a Replay Window, unless the
recipient acts only as client and hence processes only responses
as incoming messages.
The table in fig-additional-context-information overviews the new
information included in the OSCORE Security Context, with respect to
what defined in Section 3 of RFC8613.
For very constrained devices, it may be not feasible to
simultaneously handle the ongoing processing of a just received
message and the parallel retrieval of the sender's public key.  Such
devices can be configured to drop that received message altogether,
switch to the retrieval of the sender's public key, and thus have it
available to verify following messages from that sender.
An endpoint receives its own Sender ID from the Group Manager upon
joining the group.  That Sender ID is valid only within that group,
and is unique within the group.  An endpoint uses its own Sender ID
(together with other data) to generate unique AEAD nonces for
outgoing messages, as in I-D.ietf-core-object-security.  Endpoints
which are configured only as silent servers do not have a Sender ID.
The Sender/Recipient Keys and the Common IV are derived according to
the same scheme defined in Section 3.2 of I-D.ietf-core-object-
security.  The mandatory-to-implement HKDF and AEAD algorithms for
Group OSCORE are the same as in I-D.ietf-core-object-security.
In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed.  An example of Gid format supporting
this operation is provided in gid-ex.  Then, each group member re-
derives the keying material stored in its own Sender Context and
Recipient Contexts as described in sec-context, using the updated
Gid.
An endpoint receives its own Sender ID from the Group Manager upon
joining the group.  That Sender ID is valid only within that group,
and is unique within the group.  An endpoint uses its own Sender ID
(together with other data) to generate unique AEAD nonces for
outgoing messages, as in RFC8613.  Endpoints which are configured
only as silent servers do not have a Sender ID.
The Sender/Recipient Keys and the Common IV are derived according to
the same scheme defined in Section 3.2 of RFC8613.  The mandatory-to-
implement HKDF and AEAD algorithms for Group OSCORE are the same as
in RFC8613.
In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed.  When doing so, a new value for the
Master Salt parameter MAY also be distributed, and the Group Manager
SHOULD preserve the current value of the Sender ID of each group
member.  An example of Gid format supporting this operation is
provided in gid-ex.  Then, each group member re-derives the keying
material stored in its own Sender Context and Recipient Contexts as
described in sec-context, using the updated Gid.
The Group Manager provides a new Sender ID value to the endpoint
that has experienced the wrap-around.  Then, the endpoint derives
a new Sender Context using the new Sender ID, as described in
Section 3.2 of I-D.ietf-core-object-security.
Building on Section 5 of I-D.ietf-core-object-security, this section
defines how to use COSE RFC8152 to wrap and protect data in the
original message.  OSCORE uses the untagged COSE_Encrypt0 structure
with an Authenticated Encryption with Additional Data (AEAD)
algorithm.  For Group OSCORE, the following modifications apply.
The external_aad in the Additional Authenticated Data (AAD) is
extended as follows.  In particular, it has one structure used for
the encryption process producing the ciphertext, and one structure
used for the signing process producing the counter signature.
The Group Manager provides a new Sender ID value to the endpoint
that has experienced the wrap-around.  Then, the endpoint derives
a new Sender Context using the new Sender ID, as described in
Section 3.2 of RFC8613.
Building on Section 5 of RFC8613, this section defines how to use
COSE RFC8152 to wrap and protect data in the original message.
OSCORE uses the untagged COSE_Encrypt0 structure with an
Authenticated Encryption with Associated Data (AEAD) algorithm.  For
Group OSCORE, the following modifications apply.
The external_aad of the Additional Authenticated Data (AAD) is
extended as follows.  In particular, it has one structure used for
the encryption process producing the ciphertext, and one structure
used for the signing process producing the counter signature.
'par_countersign', which contains the Counter Signature Parameters
from the Common Context (see sec-context).  This parameter
contains the counter signature parameters encoded as specified in
the "Parameters" field of the Counter Signature Parameters
Registry (see iana-cons-cs-params), for the used counter signature
algorithm.  Note that if the Counter Signature Parameters in the
Common Context is empty, 'par_countersign' is not present.
'par_countersign_key', which contains the Counter Signature Key
Parameters from the Common Context (see sec-context).  This
parameter contains the counter signature key parameters encoded as
specified in the "Parameters" field of the Counter Signature Key
Parameters Registry (see iana-cons-cs-key-params), for the used
counter signature algorithm.  Note that if the Counter Signature
Key Parameters in the Common Context is empty,
'par_countersign_key' is not present.
'par_countersign', which contains the Counter Signature Parameters
from the Common Context (see sec-context).  This parameter
contains the counter signature parameters encoded as specified in
the "Parameters" field of the Counter Signature Parameters
Registry (see iana-cons-cs-params), for the used counter signature
algorithm.  If the Counter Signature Parameters in the Common
Context is empty, 'par_countersign' MUST be encoding the CBOR
simple value Null.
'par_countersign_key', which contains the Counter Signature Key
Parameters from the Common Context (see sec-context).  This
parameter contains the counter signature key parameters encoded as
specified in the "Parameters" field of the Counter Signature Key
Parameters Registry (see iana-cons-cs-key-params), for the used
counter signature algorithm.  If the Counter Signature Key
Parameters in the Common Context is empty, 'par_countersign_key'
MUST be encoding the CBOR simple value Null.
The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint
transmitting the message.  That is, unlike in I-D.ietf-core-object-
security, the 'kid' parameter is always present in all messages, i.e.
both requests and responses.
The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint
transmitting the message.  That is, unlike in RFC8613, the 'kid'
parameter is always present in all messages, i.e. both requests and
responses.
The OSCORE compression defined in Section 6 of I-D.ietf-core-object-
security is used, with the following additions for the encoding of
the OSCORE Option and the OSCORE Payload.
The fourth least significant bit MUST be set to 1 in every
message, to indicate the presence of the 'kid' parameter for
all group requests and responses.  That is, unlike in I-D.ietf-
core-object-security, the 'kid' parameter is always present in
all messages.
The OSCORE compression defined in Section 6 of RFC8613 is used, with
the following additions for the encoding of the OSCORE Option and the
OSCORE Payload.
The fourth least significant bit MUST be set to 1 in every
message, to indicate the presence of the 'kid' parameter for
all group requests and responses.  That is, unlike in RFC8613,
the 'kid' parameter is always present in all messages.
The flag bits are registered in the OSCORE Flag Bits registry
specified in Section 13.7 of I-D.ietf-core-object-security.
The flag bits are registered in the OSCORE Flag Bits registry
specified in Section 13.7 of RFC8613.
The examples assume that the label for the new kid context defined in
I-D.ietf-core-object-security has value 10.  COUNTERSIGN is the
CounterSignature0 byte string as described in sec-cose-object and is
64 bytes long.
The examples assume that the label for the new kid context defined in
RFC8613 has value 10.  COUNTERSIGN is the CounterSignature0 byte
string as described in sec-cose-object and is 64 bytes long.
The requirements and properties described in Section 7 of I-D.ietf-
core-object-security also apply to OSCORE used in group
communication.  In particular, group OSCORE provides message binding
of responses to requests, which provides relative freshness of
responses, and replay protection of requests.
Besides, group OSCORE provides additional assurances on the client
side, upon receiving responses bound to a same request.  That is, as
long as the client retains the CoAP Token used in a request (see
Section 2.5 of RFC7390), group OSCORE ensures that: any possible
response sent to that request is not a replay; and at most one
response to that request from a given server is accepted, if required
by the application.
More details about error processing for replay detection in group
OSCORE are specified in mess-processing of this specification.  The
mechanisms describing replay protection and freshness of Observe
notifications do not apply to group OSCORE, as Observe is not defined
for group settings.
The requirements and properties described in Section 7 of RFC8613
also apply to OSCORE used in group communication.  In particular,
group OSCORE provides message binding of responses to requests, which
provides relative freshness of responses, and replay protection of
requests.
Each request message and response message is protected and processed
as specified in I-D.ietf-core-object-security, with the modifications
described in the following sections.  The following security
objectives are fulfilled, as further discussed in ssec-sec-
objectives: data replay protection, group-level data confidentiality,
source authentication, message integrity.
Each request message and response message is protected and processed
as specified in RFC8613, with the modifications described in the
following sections.  The following security objectives are fulfilled,
as further discussed in ssec-sec-objectives: data replay protection,
group-level data confidentiality, source authentication and message
integrity.
Furthermore, endpoints in the group locally perform error handling
and processing of invalid messages according to the same principles
adopted in I-D.ietf-core-object-security.  However, a recipient MUST
stop processing and silently reject any message which is malformed
and does not follow the format specified in sec-cose-object, or which
is not cryptographically validated in a successful way.  Either case,
it is RECOMMENDED that the recipient does not send back any error
message.  This prevents servers from replying with multiple error
messages to a client sending a group request, so avoiding the risk of
flooding and possibly congesting the group.
A client transmits a secure group request as described in Section 8.1
of I-D.ietf-core-object-security, with the following modifications.
Upon receiving a secure group request, a server proceeds as described
in Section 8.2 of I-D.ietf-core-object-security, with the following
modifications.
In step 2, the decoding of the compressed COSE object follows
compression.  If the received Recipient ID ('kid') does not match
with any Recipient Context for the retrieved Gid ('kid context'),
then the server creates a new Recipient Context, initializes it
according to Section 3 of I-D.ietf-core-object-security, also
retrieving the client's public key.
In step 4, the 'algorithms' array in the Additional Authenticated
Data is modified as described in sec-cose-object.
In step 6, the server also verifies the counter signature using
the public key of the client from the associated Recipient
Context.
Furthermore, endpoints in the group locally perform error handling
and processing of invalid messages according to the same principles
adopted in RFC8613.  However, a recipient MUST stop processing and
silently reject any message which is malformed and does not follow
the format specified in sec-cose-object, or which is not
cryptographically validated in a successful way.  Either case, it is
RECOMMENDED that the recipient does not send back any error message.
This prevents servers from replying with multiple error messages to a
client sending a group request, so avoiding the risk of flooding and
possibly congesting the group.
A client transmits a secure group request as described in Section 8.1
of RFC8613, with the following modifications.
Upon receiving a secure group request, a server proceeds as described
in Section 8.2 of RFC8613, with the following modifications.
In step 2, the decoding of the compressed COSE object follows
compression of this specification.  If the received Recipient ID
('kid') does not match with any Recipient Context for the
retrieved Gid ('kid context'), then the server MAY create a new
Recipient Context and initializes it according to Section 3 of
RFC8613, also retrieving the client's public key.  Such a
configuration is application specific.  If the application does
not specify dynamic derivation of new Recipient Contexts, then the
server SHALL stop processing the request.
In step 4, the 'algorithms' array in the Additional Authenticated
Data is modified as described in sec-cose-object of this
specification.
In step 6, the server also verifies the counter signature using
the public key of the client from the associated Recipient
Context.  If the signature verification fails, the server MAY
reply with a 4.00 (Bad Request) response.
A server that has received a secure group request may reply with a
secure response, which is protected as described in Section 8.3 of I-
D.ietf-core-object-security, with the following modifications.
Upon receiving a secure response message, the client proceeds as
described in Section 8.4 of I-D.ietf-core-object-security, with the
following modifications.
In step 2, the decoding of the compressed COSE object is modified
as described in sec-cose-object.  The client also checks whether
it previously received a secure response to this request, such
that it was successfully verified and it included the same
Recipient ID ('kid') of the just received response.  If the check
yields a positive match and the response is not an Observe
notification RFC7641 (i.e., it does not include an Observe
Option), the client SHALL stop processing the response.  If the
received Recipient ID ('kid') does not match with any Recipient
Context for the retrieved Gid ('kid context'), then the client
creates a new Recipient Context, initializes it according to
Section 3 of I-D.ietf-core-object-security, also retrieving the
server's public key.
In step 3, the 'algorithms' array in the Additional Authenticated
Data is modified as described in sec-cose-object.
In step 5, the client also verifies the counter signature using
the public key of the server from the associated Recipient
Context.  In case of success, the client also records the received
Recipient ID ('kid') as included in a successfully verified
response to the request.
A server that has received a secure group request may reply with a
secure response, which is protected as described in Section 8.3 of
RFC8613, with the following modifications.
Upon receiving a secure response message, the client proceeds as
described in Section 8.4 of RFC8613, with the following
modifications.
In step 2, the decoding of the compressed COSE object is modified
as described in sec-cose-object of this specification.  If the
received Recipient ID ('kid') does not match with any Recipient
Context for the retrieved Gid ('kid context'), then the client MAY
create a new Recipient Context and initializes it according to
Section 3 of RFC8613, also retrieving the server's public key.  If
the application does not specify dynamic derivation of new
Recipient Contexts, then the client SHALL stop processing the
response.
In step 3, the 'algorithms' array in the Additional Authenticated
Data is modified as described in sec-cose-object of this
specification.
In step 5, the client also verifies the counter signature using
the public key of the server from the associated Recipient
Context.
Upon freeing up the Token value of a secure group request for
possible reuse I-D.dijk-core-groupcomm-bis, the client MUST delete
the list of recorded Recipient IDs associated to that request (see
step 5 above).
Defining policies for authorizing the joining of its OSCORE
groups.  Such policies can be enforced locally by the Group
Manager, or by a third party in a trust relation with the Group
Manager and entrusted to enforce join policies on behalf of the
Group Manager.
Driving the join process to add new endpoints as group members.
Establishing Security Common Contexts and providing them to
authorized group members during the join process, together with a
corresponding Security Sender Context.
Defining policies for authorizing the joining of its OSCORE
groups.
Handling the join process to add new endpoints as group members.
Establishing the Common Context part of the Security Context, and
providing it to authorized group members during the join process,
together with the corresponding Sender Context.
The same threat model discussed for OSCORE in Appendix D.1 of I-
D.ietf-core-object-security holds for Group OSCORE.  In addition,
source authentication of messages is explicitly ensured by means of
counter signatures, as further discussed in ssec-group-level-
security.
The same considerations on supporting Proxy operations discussed for
OSCORE in Appendix D.2 of I-D.ietf-core-object-security hold for
Group OSCORE.
The same considerations on protected message fields for OSCORE
discussed in Appendix D.3 of I-D.ietf-core-object-security hold for
Group OSCORE.
The same considerations on uniqueness of (key, nonce) pairs for
OSCORE discussed in Appendix D.4 of I-D.ietf-core-object-security
hold for Group OSCORE.  This is further discussed in ssec-key-nonce-
uniqueness.
The same considerations on unprotected message fields for OSCORE
discussed in Appendix D.5 of I-D.ietf-core-object-security hold for
Group OSCORE, with the following difference.  The countersignature
included in a Group OSCORE message is computed also over the value of
the OSCORE option, which is part of the Additional Authenticated Data
used in the signing process.  This is further discussed in ssec-
cross-group-injection.
Validating that the format and parameters of public keys of group
members are consistent with the countersignature algorithm and
related parameters used in the respective OSCORE group.
The same threat model discussed for OSCORE in Appendix D.1 of RFC8613
holds for Group OSCORE.  In addition, source authentication of
messages is explicitly ensured by means of counter signatures, as
further discussed in ssec-group-level-security.
The same considerations on supporting Proxy operations discussed for
OSCORE in Appendix D.2 of RFC8613 hold for Group OSCORE.
The same considerations on protected message fields for OSCORE
discussed in Appendix D.3 of RFC8613 hold for Group OSCORE.
The same considerations on uniqueness of (key, nonce) pairs for
OSCORE discussed in Appendix D.4 of RFC8613 hold for Group OSCORE.
This is further discussed in ssec-key-nonce-uniqueness.
The same considerations on unprotected message fields for OSCORE
discussed in Appendix D.5 of RFC8613 hold for Group OSCORE, with the
following difference.  The countersignature included in a Group
OSCORE message is computed also over the value of the OSCORE option,
which is part of the Additional Authenticated Data used in the
signing process.  This is further discussed in ssec-cross-group-
injection.
The rest of this section first discusses security aspects to be taken
into account when using Group OSCORE.  Then it goes through aspects
covered in the security considerations of OSCORE (Section 12 of I-
D.ietf-core-object-security), and discusses how they hold when Group
OSCORE is used.
The rest of this section first discusses security aspects to be taken
into account when using Group OSCORE.  Then it goes through aspects
covered in the security considerations of OSCORE (Section 12 of
RFC8613), and discusses how they hold when Group OSCORE is used.
The case A in Appendix D.4 of I-D.ietf-core-object-security
concerns all group requests and responses including a Partial IV
(e.g.  Observe notifications).  In this case, same considerations
from I-D.ietf-core-object-security apply here as well.
The case B in Appendix D.4 of I-D.ietf-core-object-security
concerns responses not including a Partial IV (e.g. single
response to a group request).  In this case, same considerations
from I-D.ietf-core-object-security apply here as well.
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.
In the first case, the sender protects a message using the old
Security Context, i.e. before having installed the new Security
Context.  However, the recipient receives the message after having
installed the new Security Context, hence not being able to correctly
process it.  A possible way to ameliorate this issue is to preserve
the old, recent, Security Context for a maximum amount of time
defined by the application.  By doing so, the recipient can still try
to process the received message using the old retained Security
Context as second attempt.  Note that a former (compromised) group
member can take advantage of this by sending messages protected with
the old retained Security Context.  Therefore, a conservative
application policy should not admit the storage of old Security
Contexts.
In the first case, the sender protects a message using the old
Security Context, i.e. before having installed the new Security
Context.  However, the recipient receives the message after having
installed the new Security Context, hence not being able to correctly
process it.  A possible way to ameliorate this issue is to preserve
the old, recent, Security Context for a maximum amount of time
defined by the application.  By doing so, the recipient can still try
to process the received message using the old retained Security
Context as second attempt.  This tolerance preserves the processing
of secure messages throughout a long-lasting key rotation, as group
rekeying processes may likely take a long time to complete,
especially in large scale groups.  On the other hand, a former
(compromised) group member can abusively take advantage of this, and
send messages protected with the old retained Security Context.
Therefore, a conservative application policy should not admit the
retention of old Security Contexts.
In case endpoints are deployed in multiple groups managed by
different non-synchronized Group Managers, it is possible for Group
Identifiers of different groups to coincide.  That can also happen if
the application can not guarantee unique Group Identifiers within a
given Group Manager.  However, this does not impair the security of
the AEAD algorithm.
In fact, as long as the Master Secret is different for different
groups and this condition holds over time, and as long as the Sender
IDs within a group are unique, AEAD keys are different among
different groups.
In case endpoints are deployed in multiple groups managed by
different non-synchronized Group Managers, it is possible for Group
Identifiers of different groups to coincide.
However, this does not impair the security of the AEAD algorithm.  In
fact, as long as the Master Secret is different for different groups
and this condition holds over time, AEAD keys are different among
different groups.
The same considerations from Section 12.1 of I-D.ietf-core-object-
security hold for Group OSCORE.
The same considerations from Section 12.1 of RFC8613 hold for Group
OSCORE.
That is, upon joining the group, the endpoint securely receives from
the Group Manager the necessary input parameters, which are used to
derive the Common Security Context and the Sender Context (see sec-
context).  The Group Manager ensures uniqueness of Sender IDs in the
same group.
That is, upon joining the group, the endpoint securely receives from
the Group Manager the necessary input parameters, which are used to
derive the Common Context and the Sender Context (see sec-context).
The Group Manager ensures uniqueness of Sender IDs in the same group.
Group OSCORE derives the Security Context using the same construction
of OSCORE, and by using the Group Identifier of a group as the
related ID Context.  Hence, the same required properties of the
Security Context parameters discussed in Section 3.3 of I-D.ietf-
core-object-security hold for this document.
Group OSCORE derives the Security Context using the same construction
as OSCORE, and by using the Group Identifier of a group as the
related ID Context.  Hence, the same required properties of the
Security Context parameters discussed in Section 3.3 of RFC8613 hold
for this document.
Unless exchanges in a group rely only on unicast messages, Group
OSCORE cannot be used with reliable transport.  Thus, other that in
such unlikely case, it cannot be defined that only messages with
sequence number which are equal to previous sequence number + 1 are
accepted.
Unless exchanges in a group rely only on unicast messages, Group
OSCORE cannot be used with reliable transport.  Thus, unless only
unicast messages are sent in the group, it cannot be defined that
only messages with sequence numbers that are equal to the previous
sequence number + 1 are accepted.
As discussed in Section 12.5 of I-D.ietf-core-object-security, a
server may use the Echo option I-D.ietf-core-echo-request-tag to
verify the aliveness of the client that originated a received
request.  This would also allow the server to (re-)synchronize with
the client's sequence number, as well as to ensure that the request
is fresh and has not been replayed or (purposely) delayed, if it is
the first one received from that client after having joined the group
or rebooted (see ssec-synch-challenge-response).
The same considerations from Section 12.6 of I-D.ietf-core-object-
security about the maximum Sender Sequence Number hold for Group
OSCORE.
As discussed in Section 12.5 of RFC8613, a server may use the Echo
option I-D.ietf-core-echo-request-tag to verify the aliveness of the
client that originated a received request.  This would also allow the
server to (re-)synchronize with the client's sequence number, as well
as to ensure that the request is fresh and has not been replayed or
(purposely) delayed, if it is the first one received from that client
after having joined the group or rebooted (see ssec-synch-challenge-
response).
The same considerations from Section 12.6 of RFC8613 about the
maximum Sender Sequence Number hold for Group OSCORE.
In order to renew its own Sender Context, the endpoint SHOULD inform
the Group Manager, which can either renew the whole OSCORE Security
Context by means of group rekeying, or provide only that endpoint
with a new Sender ID value.  Either case, the endpoint derives a new
Sender Context, and in particular a new Sender Key.
Additionally, the same considerations from Section 12.6 of I-D.ietf-
core-object-security hold for Group OSCORE, about building the AEAD
nonce and the secrecy of the Security Context parameters.
The same considerations from Section 12.7 of I-D.ietf-core-object-
security hold for Group OSCORE.
In order to renew its own Sender Context, the endpoint SHOULD inform
the Group Manager, which can either renew the whole Security Context
by means of group rekeying, or provide only that endpoint with a new
Sender ID value.  Either case, the endpoint derives a new Sender
Context, and in particular a new Sender Key.
Additionally, the same considerations from Section 12.6 of RFC8613
hold for Group OSCORE, about building the AEAD nonce and the secrecy
of the Security Context parameters.
The same considerations from Section 12.7 of RFC8613 hold for Group
OSCORE.
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 I-D.ietf-core-object-
security hold for Group OSCORE.
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 'kid context' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, reveals information
about the sender endpoint.  In particular, it reveals that the
sender endpoint is a member of a particular OSCORE group, whose
current Group ID is indicated in the 'kid context' parameter.
Moreover, this parameter explicitly relate two or more
communicating endpoints, as members of the same OSCORE group.
The 'kid context' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, reveals information
about the sender endpoint.  In particular, it reveals that the
sender endpoint is a member of a particular OSCORE group, whose
current Group ID is indicated in the 'kid context' parameter.
Moreover, this parameter explicitly relates two or more
communicating endpoints, as members of the same OSCORE group.
This registry specifies the parameters of each admitted
countersignature algorithm, as well as the possible structure they
are organized into.  This information is used to populate the
parameter Counter Signature Parameters of the Common Context (see
sec-context).
This registry specifies the parameters of countersignature keys for
each admitted countersignature algorithm, as well as the possible
structure they are organized into.  This information is used to
populate the parameter Counter Signature Key Parameters of the Common
Context (see sec-context).
The IANA Registry established in this document is defined as "Expert
Review".  This section gives some general guidelines for what the
experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
The IANA Registries established in this document are defined as
"Expert Review".  This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.