Draft: draft-ietf-core-oscore-groupcomm

Commentary: Proposed text rewrite , please check
This document defines Group Object Security for Constrained RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g. using IP
multicast.  In particular, the described approach defines how OSCORE
should be used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and the corresponding CoAP responses.
This document defines Group Object Security for Constrained RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g. using IP
multicast.  In particular, the described approach defines how OSCORE
should be used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
This document defines Group OSCORE, providing the same end-to-end
security properties as OSCORE in the case where CoAP requests have
multiple recipients.  In particular, the described approach defines
how OSCORE should be used in a group communication setting to provide
source authentication for CoAP group requests, sent by a client to
multiple servers, and the corresponding CoAP responses.
Group OSCORE provides source authentication of CoAP messages, by
means of two possible methods.  The first method relies on a digital
signature produced with the private key of the sender and embedded in
the protected CoAP message.  The second method relies on a symmetric
key, which is derived from a pairwise shared secret computed from the
asymmetric keys of the message sender and recipient.
The second method is intended for one-to-one messages sent in the
group.  These include all responses, as individually sent by servers,
as well as requests addressed to an individual server.  For instance,
such requests are sent as part of an exchange using the CoAP Echo
Option I-D.ietf-core-echo-request-tag, or as part of a block-wise
transfer RFC7959 in the group, after the first block-wise request
possibly targeting all servers in the group and including the CoAP
Block2 option (see Section 2.3.6 of I-D.ietf-core-groupcomm-bis).
This document defines Group OSCORE, providing the same end-to-end
security properties as OSCORE in the case where CoAP requests have
multiple recipients.  In particular, the described approach defines
how OSCORE should be used in a group communication setting to provide
source authentication for CoAP group requests, sent by a client to
multiple servers, and for protection of the corresponding CoAP
responses.
In the group mode, Group OSCORE requests and responses are
digitally signed.  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, protected with symmetric
keys.  These symmetric keys are derived from Diffie-Hellman shared
secrets, calculated with the asymmetric keys of the two group
members.  This allows for shorter integrity tags and therefore
lower message overhead.  This mode is defined in sec-pairwise-
protection and MAY be supported.  However, it MUST be supported by
endpoints that support the Echo Option I-D.ietf-core-echo-request-
tag and/or block-wise transfers RFC7959.
It is up to the application to decide in which mode a message has to
be protected, possibly on a per-message basis.  Such decision can be
based, for instance, on pre-configured policies or dynamic assessing
of the target recipient and/or resource, among other things.  In
particular, different messages can be protected in different modes,
even within the same request-response exchange.
In the group mode, Group OSCORE requests and responses are
digitally signed with the private key of the sender and 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, protected with symmetric
keys.  These symmetric keys are derived from Diffie-Hellman shared
secrets, calculated with the asymmetric keys of the sender and
recipient.  This allows for shorter integrity tags and therefore
lower message overhead.  This mode is defined in sec-pairwise-
protection and MAY be supported.  However, it MUST be supported by
endpoints that support the 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 possibly targeting
all servers in the group and including the CoAP Block2 option (see
Section 2.3.6 of I-D.ietf-core-groupcomm-bis).
Both modes provide source authentication of CoAP messages.  It is up
to the application to decide in which mode a message has to be
protected, potentially on a per-message basis.  Such decision can be
based, for instance, on pre-configured policies or dynamic assessing
of the target recipient and/or resource, among other things.  One
important case is when requests are protected with group mode, and
responses with pairwise mode, since this significantly reduces the
overhead in case of many responses to one request.
Group Identifier (Gid): identifier assigned to the group.  Group
Identifiers must be unique within the set of groups of a given
Group Manager.
Group Identifier (Gid): identifier assigned to the group, unique
within the set of groups of a given Group Manager.
One Common Context, shared by all the endpoints in the group.
Three new parameters are included in the Common Context: Counter
Signature Algorithm, Counter Signature Parameters and Counter
Signature Key Parameters.
One Sender Context, extended with the endpoint's private key.  The
Sender Context is omitted if the endpoint is configured
exclusively as silent server.
One Recipient Context for each endpoint from which messages are
received.  No Recipient Contexts are maintained as 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.
One Common Context, shared by all the endpoints in the group.
Three new parameters are included in the Common Context: Counter
Signature Algorithm, Counter Signature Parameters and Counter
Signature Key Parameters, which all relate to the signature of the
message included in group mode (see mess-processing).
One Sender Context, extended with the endpoint's private key.  The
private key is used to sign the message in group mode, and for
calculating the pairwise key in pairwise mode (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.  No Recipient Contexts are maintained as 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 calculating the pairwise key in pairwise mode.
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 members is out of scope for this specification,
but sufficient functionality to manage information about the group is
described in terms of a Group Manager, see group-manager.
The ID Context parameter (see Sections 3.3 and 5.1 of RFC8613) in the
Common Context SHALL contain the Group Identifier (Gid) of the group.
The choice of the Gid is application specific.  An example of
specific formatting of the Gid is given in gid-ex.  The application
needs to specify how to handle possible collisions between Gids, see
ssec-gid-collision.
The Counter Signature Algorithm identifies the digital signature
algorithm used to compute a counter signature on the COSE object (see
Section 4.5 of RFC8152).  Its value is immutable once the Common
Context is established.  The used Counter Signature Algorithm MUST be
selected among the signing ones defined in the COSE Algorithms
Registry (see section 16.4 of RFC8152).  The EdDSA signature
algorithm Ed25519 RFC8032 is mandatory to implement.  If Elliptic
Curve Digital Signature Algorithm (ECDSA) is used, it is RECOMMENDED
that implementations implement "deterministic ECDSA" as specified in
RFC6979.
The ID Context parameter (see Sections 3.3 and 5.1 of RFC8613) in the
Common Context SHALL contain the Group Identifier (Gid) of the group.
The choice of the Gid is application specific.  An example of
specific formatting of the Gid is given in gid-ex.  The application
needs to specify how to handle potential collisions between Gids, see
ssec-gid-collision.
The Counter Signature Algorithm identifies the digital signature
algorithm used to compute a counter signature on the COSE object (see
Section 4.5 of RFC8152).  Its value is immutable once the Common
Context is established.  The used Counter Signature Algorithm MUST be
selected among the signature algorithms defined in the COSE
Algorithms Registry (see section 16.4 of RFC8152).  The EdDSA
signature algorithm Ed25519 RFC8032 is mandatory to implement.  If
elliptic curve signatures are used, it is RECOMMENDED to implement
deterministic signatures with additional randomness as specified in
I-D.mattsson-cfrg-det-sigs-with-noise.
OSCORE specifies the derivation of Sender Context and Recipient
Context, specifically Sender/Recipient Keys and Common IV, from a set
of input parameters (see Section 3.2 of RFC8613).  This derivation
applies also to Group OSCORE, and the mandatory-to-implement HKDF and
AEAD algorithms are the same as in RFC8613.  However, for Group
OSCORE the Sender Context and Recipient Context additionally contain
asymmetric keys.
The Sender Context needs to be configured with the private key of the
endpoint.  The private key is used to generate a signature (see sec-
cose-object) included in the sent OSCORE message.  How the private
key is established is out of scope for this specification.
Each Recipient Context needs to be configured with the public key of
the associated endpoint.  The public key is used to verify a
signature (see sec-cose-object) included in the received OSCORE
message.
The input parameters for deriving the Recipient Context parameters
and the public key of the associated endpoint may be provided to the
recipient endpoint upon joining the group.  These parameters may
alternatively be acquired at a later time, for example the first time
a message is received from this particular endpoint in the group (see
ssec-verify-request and ssec-verify-response).  The received message
together with the Common Context contains the necessary information
to derive a security context for verifying a message, except for the
public key of the associated endpoint.
For severely constrained devices, it may be not feasible to
simultaneously handle the ongoing processing of a recently received
message in parallel with the retrieval of the associated endpoint's
public key.  Such devices can be configured to drop a received
message for which there is no Recipient Context, and retrieve the
public key in order to have it available to verify subsequent
messages from that endpoint.
Endpoints communicating with Group OSCORE need, in addition to the
OSCORE input parameters, also to be provisioned with information
about the group(s) and other endpoints in the group(s).
The Group Manager is an entity responsible for the group, including
the Group Identifier (Gid) used as ID Context, as well as the Sender
ID and Recipient ID of the group members (see sec-group-manager).
The Group Manager is exclusively in control of the Gid values
uniquely assigned to the different groups under its control, as well
as of the Sender ID and Recipient ID values uniquely assigned to the
members of each 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.  In addition, the Group Manager records the
public keys of endpoints joining a group, and provides information
about the group and its members to other members.
An endpoint receives the Group Identifier and OSCORE input
parameters, including its own Sender ID, from the Group Manager upon
joining the group.  That Sender ID is valid only within that group,
and is unique within the group.  Endpoints which are configured only
as silent servers do not have a Sender ID.
The Common Context may be acquired from the Group Manager (see group-
manager).
OSCORE specifies the derivation of Sender Context and Recipient
Context, specifically Sender/Recipient Keys and Common IV, from a set
of input parameters (see Section 3.2 of RFC8613).  This derivation
applies also to Group OSCORE, and the mandatory-to-implement HKDF and
AEAD algorithms are the same as in RFC8613.
For Group OSCORE the Sender Context and Recipient Context
additionally contain asymmetric keys, as described previously in sec-
context.  The private/public key pair of the sender may be generated
by the endpoint or provisioned during manufacturing.
A received Group OSCORE message together with the Common Context
contains the necessary information to derive a security context for
verifying the message, except for the public key of the associated
endpoint.  The public keys in the Recipient Contexts may be accessed
from the Group Manager (see group-manager) upon joining the group.  A
public key may alternatively be acquired from the Group Manager at a
later time, for example the first time a message is received from a
particular endpoint in the group (see ssec-verify-request and ssec-
verify-response).
For severely constrained devices, it may be not feasible to
simultaneously handle the ongoing processing of a recently received
message in parallel with the retrieval of the associated endpoint's
public key.  Such devices can be configured to drop a received
message for which there is no (complete) Recipient Context, and
retrieve the public key in order to have it available to verify
subsequent messages from that endpoint.
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 a Group Manager which is
responsible for the group, but does not mandate how the Group Manager
interacts with the 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.  In addition, the Group
Manager records the public keys of endpoints joining a group, and
provides information about the group and its members to other members
and selected roles.
An endpoint receives group data such as the Gid and OSCORE input
parameters, including its own Sender ID, from the Group Manager upon
joining the group.  Endpoints which are configured only as silent
servers do not have a Sender ID.
According to this specification, it is RECOMMENDED to use a Group
Manager as described in I-D.ietf-ace-key-groupcomm-oscore, where the
join process is based on the ACE framework for authentication and
authorization in constrained environments I-D.ietf-ace-oauth-authz.
Further details about how public keys can be handled and retrieved in
the group is out of the scope of this document.
According to this specification, it is RECOMMENDED to use a Group
Manager as described in I-D.ietf-ace-key-groupcomm-oscore, where the
join process is based on the ACE framework for authentication and
authorization in constrained environments I-D.ietf-ace-oauth-authz.
In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed.  An example of Gid format supporting
this operation is provided in gid-ex.  When distributing the new Gid
and Master Secret, the Group Manager MAY distribute also a new value
for the Master Salt parameter, and SHOULD preserve the current value
of the Sender ID of each group member.
Then, each group member re-derives the keying material stored in its
own Sender Context and Recipient Contexts as described in sec-
context, using the updated Gid and Master Secret parameter.  The
Master Salt used for the re-derivations is the updated Master Salt
parameter if provided by the Group Manager, or the empty byte string
otherwise.  Unless otherwise specified by the application, each group
member does not reset its own Sender Sequence Number in its Sender
Context, and does not reset its own replay windows in its Recipient
Contexts.  From then on, each group member MUST use its latest
installed Sender Context to protect outgoing messages.
After a new Gid has been distributed, a same Recipient ID ('kid')
should not be considered as a persistent and reliable indicator of
the same group member.  Such an indication can be actually achieved
only by using that members's public key.  This occurs when verifying
countersignatures of received messages (in group mode), or when
verifying messages integrity-protected with pairwise keying material
derived from asymmetric keys (in pairwise mode).  As a consequence,
group members may end up retaining stale Recipient Contexts, that are
no longer useful to verify incoming secure messages.
In order to alleviate this issue, the Group Manager SHOULD NOT
recycle 'kid' values within a same group, especially in the short
term.  Furthermore, applications may define policies to: i) delete
(long-)unused Recipient Contexts and reduce the impact on storage
space; as well as ii) check with the Group Manager that an owned
public key is currently the one associated to a 'kid' value, after a
number of consecutive failed verifications.
The distribution of a new Gid and Master Secret may result in
temporarily misaligned Security Contexts among group members.  In
particular, this may result in a group member not able to process
messages received right after a new Gid and Master Secret have been
distributed.  A discussion on practical consequences and possible
ways to address them is provided in ssec-key-rotation.
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.  An example of Gid format supporting
this operation is provided in gid-ex.  When distributing the new Gid
and Master Secret, the Group Manager MAY distribute also a new value
for the Master Salt parameter, and SHOULD preserve the current value
of the Sender ID of each group member.
Having acquired new group data as described above, each member can
re-derive the keying material stored in its Sender Context and
Recipient Contexts (see ssec-sender-recipient-context).  Unless
otherwise specified by the application, each group member does not
reset its own Sender Sequence Number in its Sender Context, and does
not reset its own replay windows in its Recipient Contexts.  From
then on, each group member MUST use its latest installed Sender
Context to protect outgoing messages.
The Recipient ID ('kid') SHOULD NOT be considered as a persistent and
reliable indicator of a group member.  Such an indication can be
achieved only by using that members's public key, when verifying
countersignatures of received messages (in group mode), or when
verifying messages integrity-protected with pairwise keying material
derived from asymmetric keys (in pairwise mode).  As a consequence,
group members may end up retaining stale Recipient Contexts, that are
no longer useful to verify incoming secure messages.
The Group Manager SHOULD NOT recycle 'kid' values within a same
group, especially in the short term.  Furthermore, applications may
define policies to: i) delete (long-)unused Recipient Contexts and
reduce the impact on storage space; as well as ii) check with the
Group Manager that a public key is currently the one associated to a
'kid' value, after a number of consecutive failed verifications.
The distribution of a new Gid and Master Secret may result in
temporarily misaligned Security Contexts among group members.  In
particular, this may result in a group member not being able to
process messages received right after a new Gid and Master Secret
have been distributed.  A discussion on practical consequences and
possible ways to address them is provided in ssec-key-rotation.
The specific approach used to distribute the new Gid and Master
Secret parameter to the group 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.
An endpoint can eventually exhaust its own Sender Sequence Number,
which is incremented after sending each new message including a
Partial IV.  This is the case for all group requests, all Observe
notifications RFC7641 and, optionally, any other response.
If an implementation's integers only support wrapping addition, the
implementation MUST detect a wrap-around of the Sender Sequence
Number value and treat that as exhausted instead.
Upon exhausting its own Sender Sequence Number, the endpoint MUST NOT
transmit further messages for that group until it has derived a new
Sender Context, in order to avoid reusing nonces with the same keys.
The 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.
An endpoint can eventually exhaust its own Sender Sequence Number,
which is incremented for each new message including a Partial IV.
This is the case for group requests, Observe notifications RFC7641
and, optionally, any other response.
If an implementation's integers supports wrapping addition, the
implementation MUST detect a wrap-around of the Sender Sequence
Number value and treat those as exhausted.
Upon exhausting its own Sender Sequence Number, the endpoint MUST NOT
transmit further messages for that group until it has derived a new
Sender Context, to avoid reusing nonces with the same keys.
The Group Manager provides a new Sender ID value to the endpoint
that has experienced the exhaustion.  Then, the endpoint derives a
new Sender Context using the new Sender ID, as described in
Section 3.2 of RFC8613.
In either case, same considerations from sec-group-key-management
hold about possible retaining of stale Recipient Contexts.
Certain signature schemes, such as EdDSA and ECDSA, support a secure
combined signature and encryption scheme.  This section specifies the
derivation of pairwise encryption keys, for use in the pairwise mode
of Group OSCORE defined in sec-pairwise-protection.
Two group members can derive a symmetric pairwise key, from their
Sender/Recipient Key and a static-static Diffe-Hellman shared secret
NIST-800-56A.  The key derivation is as follows, and uses the same
construction used in Section 3.2.1 of RFC8613.
The Sender/Recipient key is the Sender Key of the sender, i.e. the
Recipient Key that the recipient stores in its own Recipient
Context corresponding to the sender.
The Shared Secret is computed as a static-static Diffie-Hellman
shared secret NIST-800-56A, where the sender uses its own private
key and the recipient's public key, while the recipient uses its
own private key and the senders's public key.  The Shared Secret
may be stored in memory, rather than recomputed each time it is
needed.
The Group Manager provides a new unused Sender ID value to the
endpoint that has experienced the exhaustion.  Then, the endpoint
derives a new Sender Context using the new Sender ID (see ssec-
sender-recipient-context).
In either case, the same considerations from sec-group-key-management
holgit add d about stale Recipient Contexts.
Certain signature schemes, such as EdDSA and ECDSA, support a secure
combined signature and encryption scheme.  This section specifies the
derivation of "pairwise keys", for use in the pairwise mode of Group
OSCORE defined in sec-pairwise-protection.
The Shared Secret is computed as a static-static Diffie-Hellman
shared secret NIST-800-56A, where the endpoint uses its own
private key and the public key of the other endpoint X.
The Recipient Key and the public key are from the Recipient
Context of endpoint X.
The Sender Key and private key are from the Sender Context.
After completing the establishment of a new Security Context (see
sec-group-key-management), every group member MUST delete all its
pairwise keys.  Since new Sender/Recipient keys are derived from the
new group keying material (see ssec-sender-recipient-context), every
group member MUST use such new Sender/Recipient keys when possibly
deriving new pairwise keys.
After completing the establishment of a new Security Context for the
group (see sec-group-key-management), the old pairwise keys MUST be
deleted.  Since new Sender/Recipient Keys are derived from the new
group keying material (see ssec-sender-recipient-context), every
group member MUST use the new Sender/Recipient keys when deriving new
pairwise keys.
When using any of its pairwise keys, a sender endpoint MUST use the
current fresh value of its own Sender Sequence Number, from its own
Sender Context (see ssec-sender-recipient-context).  That is, the
same Sender Sequence Number space is used for all outgoing messages
sent to the group and protected with Group OSCORE, thus limiting both
storage and complexity.
On the other hand, when combining one-to-many and one-to-one
communication in the group, this may result in the Partial IV values
moving forward more often.  This can happen when a client engages in
frequent, long sequences of one-to-one exchanges with servers in the
group, by sending requests over unicast, which is NOT RECOMMENDED to
protect using the group mode (see ssec-unicast-requests).
In order to optimize performance, an endpoint A may derive a pairwise
key used with an endpoint B in the OSCORE group only once, and then
store it in its own Security Context for future retrieval.  This can
work as follows.
The Recipient ID of B for A, i.e. the Sender ID of B.
The Pairwise Key derived as defined in sec-derivation-pairwise,
with A acting as sender and B acting as recipient.
More generally, A has one of such Paiwise Sender Contexts within its
own Sender Context, for each different intended recipient.
Furthermore, A can additionally store in its own Recipient Context
associated to B the Pairwise Key to use for incoming traffic from B.
That is, this Pairwise Key is derived as defined in sec-derivation-
pairwise, with A acting as recipient and B acting as sender.
When using any of its Pairwise Sender Keys, the sender MUST use the
current fresh value of its Sender Sequence Number, from its Sender
Context (see ssec-sender-recipient-context).  That is, the same
Sender Sequence Number space is used for all outgoing messages sent
to the group and protected with Group OSCORE, thus limiting both
storage and complexity.
On the other hand, when combining one-to-many and one-to-one
communication in the group, this may result in the Partial IV values
moving forward more often.  This can happen when a client engages in
frequent, long sequences of one-to-one exchanges with servers in the
group, by sending requests over unicast.
The shared secrets used in the key derivation of the pairwise keys
(key-derivation-pairwise) may be stored in memory or recomputed each
time they are needed.  This applies also to the pairwise keys
themselves, with the difference that the shared secrets only change
if the asymmetric keys do.  In order to optimize performance, an
endpoint may store the derived pairwise keys in the Security Context
for future retrieval.  This can work as follows.
The endpoint stores in its Recipient Context the Pairwise
Recipient Key for endpoint X.
The Recipient ID of X, as defined in its Recipient Context
(i.e. the Sender ID according to endpoint X).
The Pairwise Sender Key derived as defined in key-derivation-
pairwise.
fig-pairwise-context-information shows the new information elements
in comparison with the OSCORE security context.
When using the group mode, messages are protected and processed as
specified in RFC8613, with the modifications described in the
following sections.
When using the group mode, messages are protected and processed as
specified in RFC8613, with the modifications described in this
section.
In particular, a server may first get a group request protected with
the old Security Context, then install the new Security Context, and
only after that produce a response to send back to the client.  In
such a case, as specified in ssec-protect-response, the server MUST
protect the possible response using the new Security Context.
Specifically, the server MUST use its own Sender Sequence Number as
Partial IV to protect that response, and not the Partial IV from the
request, in order to prevent reuse of AEAD nonces in the new Security
Context.
In particular, a server may first get a group request protected with
the old Security Context, then install the new Security Context, and
only after that produce a response to send back to the client.  In
such a case, as specified in ssec-protect-response, the server MUST
protect the potential response using the new Security Context.
Specifically, the server MUST use its own Sender Sequence Number as
Partial IV to protect that response, and not the Partial IV from the
request, in order to prevent reuse of AEAD nonces in the new Security
Context.