Draft: draft-ietf-ace-key-groupcomm-oscore

Commentary: This may result in removing the alternative techniques to compute the signature challenge for joining requests following the first one after token posting , e.g. using a TLS exporter . 
 It 's not needed if the token authorizes the client to be only monitor in all the groups covered in the token . Is it worth addressing and implementing this optimization ? Or rather to just return a kdcnonce even in such a case , even thoug that joining node is not going to use the received kdcnonce to build a signature challenge ? 
 I do n't know if it is worth it or not , that is a question that could be left to the implementer if it the field is optional rather than required .
As described in I-D.ietf-core-oscore-groupcomm, Group OSCORE is used
to protect CoAP group communication over IP multicast I-D.dijk-core-
groupcomm-bis.  This relies on a Group Manager, which is responsible
for managing an OSCORE group, where members exchange CoAP messages
secured with Group OSCORE.  The Group Manager can be responsible for
multiple groups, coordinates the joining process of new group
members, and is entrusted with the distribution and renewal of group
keying material.
As described in I-D.ietf-core-oscore-groupcomm, Group OSCORE is used
to protect CoAP group communication over IP multicast I-D.ietf-core-
groupcomm-bis.  This relies on a Group Manager, which is responsible
for managing an OSCORE group and enables the group members to
exchange CoAP messages secured with Group OSCORE.  The Group Manager
can be responsible for multiple groups, coordinates the joining
process of new group members, and is entrusted with the distribution
and renewal of group keying material.
The terms and concepts related to the CoAP protocol described in
I-D.dijk-core-groupcomm-bis.  Unless otherwise indicated, the term
"endpoint" is used here following its OAuth definition, aimed at
denoting resources such as /token and /introspect at the AS and
/authz-info at the RS.  This document does not use the CoAP
definition of "endpoint", which is "An entity participating in the
CoAP protocol".
The terms and concepts related to the CoAP protocol described in
I-D.ietf-core-groupcomm-bis.  Unless otherwise indicated, the term
"endpoint" is used here following its OAuth definition, aimed at
denoting resources such as /token and /introspect at the AS and
/authz-info at the RS.  This document does not use the CoAP
definition of "endpoint", which is "An entity participating in the
CoAP protocol".
Group communication for CoAP over IP multicast has been enabled in I-
D.dijk-core-groupcomm-bis and can be secured with Group Object
Security for Constrained RESTful Environments (OSCORE) RFC8613 as
described in I-D.ietf-core-oscore-groupcomm.  A network node joins an
OSCORE group by interacting with the responsible Group Manager.  Once
registered in the group, the new node can securely exchange messages
with other group members.
Signature verifier: entity external to the OSCORE group and
intended to verify the countersignature of messages exchanged in
the group.  An authorized signature verifier does not join the
OSCORE group as an actual member, yet it can retrieve the public
keys of the current group members from the Group Manager.
Group communication for CoAP over IP multicast has been enabled in I-
D.ietf-core-groupcomm-bis and can be secured with Group Object
Security for Constrained RESTful Environments (OSCORE) RFC8613 as
described in I-D.ietf-core-oscore-groupcomm.  A network node joins an
OSCORE group by interacting with the responsible Group Manager.  Once
registered in the group, the new node can securely exchange messages
with other group members.
All communications between the involved entities rely on the CoAP
protocol and MUST be secured.
All communications between the involved entities MUST be secured.
The keying material distributed through a group rekeying MUST include
a new Group Identifier (Gid) for the group and a new value for the
Master Secret parameter of the OSCORE Common Security Context of that
group (see Section 2 of I-D.ietf-core-oscore-groupcomm).  Also, it
MAY include a new value for the Master Salt parameter of the OSCORE
Common Security Context of that group.
a new Group Identifier (Gid) for the group, used as ID Context
parameter of the OSCORE Common Security Context of that group (see
Section 2 of I-D.ietf-core-oscore-groupcomm).  Note that the Gid
differs from the plain group name introduced in ssec-terminology,
which is a plain, stable and invariant identifier, with no
cryptographic relevance and meaning.
a new value for the Master Secret parameter of the OSCORE Common
Security Context of that group (see Section 2 of I-D.ietf-core-
oscore-groupcomm).
Also, the distributed keying material MAY include a new value for the
Master Salt parameter of the OSCORE Common Security Context of that
group.
The group name of the OSCORE group to join under the Group
Manager is encoded as a CBOR text string (REQ1).
Accepted values for role identifiers in the OSCORE group to
join are: "requester", "responder", and "monitor" (REQ2).
Possible combinations are: ["requester" , "responder"];
["requester" , "monitor"].  Each role identifier MUST be
encoded as a CBOR integer (REQ2), by using for abbreviation the
values specified in fig-role-cbor-values (OPT7).
The 'audience' parameter MUST be present.
The Authorization Request message is as defined in Section 3.1 of I-
D.ietf-ace-key-groupcomm, with the following additions.
The group name of each OSCORE group to join under the Group
Manager is encoded as a CBOR text string (REQ1).
Accepted values for role identifiers in the OSCORE group to
join are: "requester", "responder", and "monitor" (REQ2).
Possible combinations are: ["requester" , "responder"].  An
additional role identifier is "verifier", denoting an external
signature verifier that does not join the OSCORE group.  Each
role identifier MUST be encoded as a CBOR integer (REQ2), by
using for abbreviation the values specified in fig-role-cbor-
values (OPT7).
The handler verifies that the group identifier of the /group-
manager/GROUPNAME/active path is a subset of the 'scope' stored in
the Access Token associated to the requesting client.  If
verification fails, the Group Manager MUST respond with a 4.01
(Unauthorized) error message.
The handler verifies that the group identifier of the /group-
oscore/GROUPNAME/active path is a subset of the 'scope' stored in the
Access Token associated to the requesting client.  If verification
fails, the Group Manager MUST respond with a 4.01 (Unauthorized)
error message.
A signature verifier provides the Group Manager with an Access Token,
as described in ssec-token-post, just as any another joining node
does.  However, unlike candidate group members, it does not join any
OSCORE group, i.e. it does not perform the joining process defined in
ssec-join-req-sending.  After a successful token posting, a signature
verifier is authorized to perform only the operations specified in
sec-pub-keys, to retrieve the public keys of group members, and only
for the OSCORE groups specified in the validated Access Token.  The
Group Manager MUST respond with a 4.01 (Unauthorized) error message,
in case a signature verifier attempts to access any other endpoint
than /group-oscore/GROUPNAME/pub-key at the Group Manager.
The 'rsnonce' parameter contains a dedicated nonce N_S generated
by the Group Manager.  For the N_S value, it is RECOMMENDED to use
a 8-byte long random nonce.  The joining node may use this nonce
in order to prove the possession of its own private key, upon
joining the group (see ssec-join-req-sending).
TODO: have 'sign_info' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
'sign_alg' takes value from Tables 5 and 6 of RFC8152.
'sign_parameters' takes values from the "Counter Signature
Parameters" Registry (see Section 11.1 of I-D.ietf-core-oscore-
groupcomm).  Its structure depends on the value of 'sign_alg'.
If no parameters of the counter signature algorithm are
specified, 'sign_parameters' MUST be encoding the CBOR simple
value Null.
'sign_key_parameters' takes values from the "Counter Signature
Key Parameters" Registry (see Section 11.2 of I-D.ietf-core-
oscore-groupcomm).  Its structure depends on the value of
'sign_alg'.  If no parameters of the key used with the counter
signature algorithm are specified, 'sign_key_parameters' MUST
be encoding the CBOR simple value Null.
TODO: have 'pub_key_enc' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
If 'pub_key_enc' is present in the response, it takes value 1
("COSE_Key") from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in I-D.ietf-ace-cwt-proof-
of-possession, so indicating that public keys in the OSCORE group
are encoded as COSE Keys RFC8152.  Future specifications may
define additional values for this parameter.
The 'kdcchallenge' parameter contains a dedicated nonce N_S
generated by the Group Manager.  For the N_S value, it is
RECOMMENDED to use a 8-byte long random nonce.  The joining node
may use this nonce in order to prove the possession of its own
private key, upon joining the group (see ssec-join-req-sending).
The 'kdcchallenge' parameter MAY be omitted from the 2.01
(Created) response, if the 'scope' of the Access Token includes
only the role "monitor" or only the role "verifier", for each of
the specified groups.
If the 'sign_info' parameter is present in the response, the
following applies for each element 'sign_info_entry'.
In the 'id' element, every group name is encoded as a CBOR text
string (REQ1).
'sign_alg' takes value from Tables 5 and 6 of RFC8152, if not
encoding the CBOR simple value Null.
'sign_parameters' takes values from the "Counter Signature
Parameters" Registry (see Section 11.1 of I-D.ietf-core-oscore-
groupcomm).  Its structure depends on the value of 'sign_alg'.
If no parameters of the counter signature algorithm are
specified or if 'sign_alg' encodes the CBOR simple value Null,
'sign_parameters' MUST be encoding the CBOR simple value Null.
'sign_key_parameters' takes values from the "Counter Signature
Key Parameters" Registry (see Section 11.2 of I-D.ietf-core-
oscore-groupcomm).  Its structure depends on the value of
'sign_alg'.  If no parameters of the key used with the counter
signature algorithm are specified or if 'sign_alg' encodes the
CBOR simple value Null, 'sign_key_parameters' MUST be encoding
the CBOR simple value Null.
If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key")
from the 'Confirmation Key' column of the "CWT Confirmation
Method" Registry defined in RFC8747, so indicating that public
keys in the OSCORE group are encoded as COSE Keys RFC8152.
Future specifications may define additional values for this
parameter.
The N_S challenge takes one of the following values.
If the joining node has posted the Access Token to the /authz-info
endpoint of the Group Manager as in ssec-token-post, N_S takes the
same value of the 'rsnonce' parameter in the 2.01 (Created)
response to the Token POST.
If the Token posting has relied on the DTLS profile of ACE I-
D.ietf-ace-dtls-authorize and the joining node included the Access
Token as content of the "psk_identity" field of the
ClientKeyExchange message RFC6347, N_S is an exporter value
computed as defined in Section 7.5 of RFC8446.  Specifically, N_S
is exported from the DTLS session between the joining node and the
Group Manager, using an empty 'context_value', 32 bytes as
'key_length', and the exporter label "EXPORTER-ACE-Sign-Challenge-
coap-group-oscore-app" defined in ssec-iana-tls-esporter-label-
registry of this specification.
If the joining node and the Group Manager communicates using
DTLS, N_S is an exporter value, computed as described in point
(2) above.
If the joining node and the Group Manager communicates using
OSCORE RFC8613, the N_S is the output PRK of a HKDF-Extract
step RFC5869, i.e. PRK = HMAC-Hash(salt, IKM).  In particular,
'salt' takes (x1 | x2), where x1 is the ID Context of the
OSCORE Security Context between the joining node and the Group
Manager, x2 is the Sender ID of the joining node in that
Context, and | denotes byte string concatenation.  Also, 'IKM'
is the OSCORE Master Secret of the OSCORE Security Context
between the joining node and the Group Manager.  The HKDF MUST
be one of the HMAC-based HKDF RFC5869 algorithms defined for
COSE RFC8152.  HKDF SHA-256 is mandatory to implement.
The value of the N_S challenge is determined as follows.
If the joining node has posted the Access Token to the /authz-info
endpoint of the Group Manager as in ssec-token-post, N_S takes the
same value of the most recent 'kdcchallenge' parameter received by
the joining node from the Group Manager.  This can be either the
one specified in the 2.01 (Created) response to the Token POST, or
the one possibly specified in a 4.00 (Bad Request) response to a
following Joining Request (see ssec-join-req-processing).
If the Token posting has relied on the DTLS profile of ACE I-
D.ietf-ace-dtls-authorize with the Access Token as content of the
"psk_identity" field of the ClientKeyExchange message RFC6347, N_S
is an exporter value computed as defined in Section 7.5 of
RFC8446.  Specifically, N_S is exported from the DTLS session
between the joining node and the Group Manager, using an empty
'context_value', 32 bytes as 'key_length', and the exporter label
"EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app" defined in
ssec-iana-tls-esporter-label-registry of this specification.
ssec-security-considerations-reusage-nonces provides security
considerations on the reusage of the N_S challenge.
A 4.00 Bad Request response from the Group Manager to the joining
node MUST have content format application/ace-group+cbor.  The
response payload is a CBOR map which MUST contain the 'sign_info'
and 'pub_key_enc' parameters.  The CBOR map SHOULD additionally
contain the 'rsnonce' parameter, specifying a new dedicated 8-byte
nonce generated by the Group Manager (see ssec-token-post).
A 4.00 Bad Request response from the Group Manager to the joining
node MUST have content format application/ace+cbor.  The response
payload is a CBOR map which MUST contain the 'sign_info'
parameter, including a single element 'sign_info_entry' pertaining
the OSCORE group that the joining node tried to join with the
Joining Request.
The 'client_cred_verify' parameter MUST include a signature
computed as described in ssec-join-req-sending, by using the
public key indicated in the current 'client_cred' parameter,
with the countersignature algorithm and possible associated
parameters indicated by the Group Manager.  If the error
response from the Group Manager included the 'rsnonce'
parameter, the joining node MUST use its content as new N_S
challenge to compute the signature.
The 'client_cred_verify' parameter MUST include a signature
computed as described in ssec-join-req-sending, by using the
public key indicated in the current 'client_cred' parameter,
with the countersignature algorithm and possible associated
parameters indicated by the Group Manager.  If the error
response from the Group Manager included the 'kdcchallenge'
parameter, the joining node MUST use its content as new N_S
challenge to compute the signature.
The 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the group.  This
parameter takes values from Tables 5 and 6 of RFC8152.
The 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the group.  This
parameter takes values from the "COSE Algorithms" Registry,
defined in Section 16.4 of RFC8152.
The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members.  This
parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in I-D.ietf-ace-cwt-
proof-of-possession, so indicating that public keys in the
OSCORE group are encoded as COSE Keys RFC8152.  Future
specifications may define additional values for this parameter.
If this parameter is not present, 1 ("COSE_Key") MUST be
assumed as default value.
The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members.  This
parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in RFC8747, so indicating
that public keys in the OSCORE group are encoded as COSE Keys
RFC8152.  Future specifications may define additional values
for this parameter.  If this parameter is not present, 1
("COSE_Key") MUST be assumed as default value.
The 'group_policies' parameter SHOULD be present, and SHOULD
include the elements "Sequence Number Synchronization Method" and
"Key Update Check Interval" defined in Section 4.1.2. of I-D.ietf-
ace-key-groupcomm.
The 'group_policies' parameter SHOULD be present, and SHOULD
include the elements "Sequence Number Synchronization Method" and
"Key Update Check Interval" defined in Section 4.1.2 of I-D.ietf-
ace-key-groupcomm, as well as the element "Group OSCORE Pairwise
Mode Support" defined in ssec-pairwise-mode-policy of this
specification.
This specifications defines the group policy "Group OSCORE Pairwise
Mode Support", for which it registers an entry in the "ACE Groupcomm
Policy" IANA Registry defined in Section 8.7 of I-D.ietf-ace-key-
groupcomm.
The corresponding element in the 'group_policies' parameter of the
Joining Response (see ssec-join-resp) encodes the CBOR simple value
True, if the OSCORE group supports the pairwise mode of Group OSCORE
I-D.ietf-core-oscore-groupcomm, or the CBOR simple value False
otherwise (REQ14).
The joining node is going to join the group exclusively as
monitor.  That is, it is not going to send messages to the group,
and hence to produce signatures with its own private key.  In this
case, the joining node is not required to provide its own public
key to the Group Manager, which thus does not have to perform any
check related to the public key encoding, or to a countersignature
algorithm and possible associated parameters for that joining
node.
The joining node is going to join the group exclusively as
monitor.  That is, it is not going to send messages to the group,
and hence to produce signatures with its own private key.  In this
case, the joining node is not required to provide its own public
key to the Group Manager, which thus does not have to perform any
check related to the public key encoding, or to a countersignature
algorithm and possible associated parameters for that joining
node.  In case that joining node still provides a public key in
the 'client_cred' parameter of the Joining Request (see ssec-join-
req-sending), the Group Manager silently ignores that parameter,
as well as related the parameters 'cnonce' and
'client_cred_verify'.
b.  Or the Group Manager generates a new Sender ID for that group
member and replies with a Key Renewal Response, formatted as
defined in Section 4.1.6.1 of I-D.ietf-ace-key-groupcomm.  In
particular, the CBOR Map in the response payload includes a single
parameter 'clientId' defined in ssec-iana-ace-groupcomm-
parameters-registry of this document, specifying the new Sender ID
of the group member encoded as a CBOR byte string.
Otherwise, depending on the configured policies (OPT8), the Group
Manager takes one of the following actions.
a.  The Group Manager rekeys the OSCORE group.  That is, the Group
Manager generates new group keying material for that group (see
sec-group-rekeying-process), and replies to the group member with
a group rekeying message as defined in sec-group-rekeying-process,
providing the new group keying material.  Then, the Group Manager
rekeys the rest of the OSCORE group, as discussed in sec-group-
rekeying-process.
b.  The Group Manager generates a new Sender ID for that group
member and replies with a Key Renewal Response, formatted as
defined in Section 4.1.6.1 of I-D.ietf-ace-key-groupcomm.  In
particular, the CBOR Map in the response payload includes a single
parameter 'clientId' defined in ssec-iana-ace-groupcomm-
parameters-registry of this document, specifying the new Sender ID
of the group member encoded as a CBOR byte string.
A group member may need to retrieve the public keys of other group
members.  To this end, the group member sends a Public Key Request
message to the Group Manager, as per Section 4.5 of I-D.ietf-ace-key-
groupcomm.  In particular, it sends the request to the endpoint
/group-oscore/GROUPNAME/pub-key at the Group Manager.
A group member or a signature verifier may need to retrieve the
public keys of (other) group members.  To this end, the group member
or signature verifier sends a Public Key Request message to the Group
Manager, as per Section 4.5 of I-D.ietf-ace-key-groupcomm.  In
particular, it sends the request to the endpoint /group-
oscore/GROUPNAME/pub-key at the Group Manager.
In either case, if the leaving node is not configured exclusively as
monitor, the Group Manager performs the following actions.
If, upon joining the group (see ssec-join-req-sending), the leaving
node specified a URI in the 'control_path' parameter defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm, the Group Manager MUST
inform the leaving node of its eviction, by sending a DELETE request
targeting the URI specified in the 'control_path' parameter (OPT9).
If the leaving node is not configured exclusively as monitor, the
Group Manager performs the following actions.
Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member
used during the joining process.  In particular, each rekeying
message can target the 'control_path' URI path defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm, if provided by the
intended recipient upon joining the group (see ssec-join-req-
sending).
Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member
used during the joining process.  In particular, each rekeying
message can target the 'control_path' URI path defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm (OPT9), if provided by
the intended recipient upon joining the group (see ssec-join-req-
sending).
For the N_C value, it is RECOMMENDED to use a 8-byte long random
nonce.  Furthermore, N_C is always conveyed in the 'cnonce' parameter
of the Joining Request, which is always sent over the secure
communication channel between the joining node and the Group Manager.
As defined in sssec-challenge-value, the way the N_S value is
computed depends on the particular interaction between the joining
node and the Group Manager.
If the Access Token is not explicitly posted to the /authz-info
endpoint of the Group Manager, or if the joining node re-joins
without re-posting the same still valid Access Token, then N_S is
computed as a 32-byte long nonce (see points (2) and (3) of sssec-
challenge-value).
If the Access Token has been explicitly posted to the /authz-info
endpoint of the Group Manager, N_S takes the value conveyed in the
'rsnonce' parameter of the 2.01 response to the Token Post (see
ssec-token-post).  Similarly, if a Joining Request is not
successfully processed by the Group Manager, the returned error
response should also include the 'rsnonce' parameter specifying a
new nonce N_S (see ssec-join-req-processing).  In either case, it
is RECOMMENDED to use a 8-byte long random nonce as value for N_S.
If we consider both N_C and N_S to be 8-byte long nonces, the
following considerations hold.
If both N_C and N_S are random nonces, the average collision for
each nonce will happen after 2^32 messages, as per the birthday
paradox and as also discussed in Section 7 of I-D.ietf-ace-oscore-
profile.  This amounts to considerably more token provisionings
than the expected new joinings of OSCORE groups under a same Group
Manager.
If N_C and N_S are not generated randomly, e.g. by using a
counter, the joining node and the Group Manager need to guarantee
that reboot and loss of state on either node does not provoke re-
use.  If that is not guaranteed, a joining node may repeatedly
post a valid Access Token to the /authz-info endpoint of the Group
Manager, until it gets back an exact, re-used value N_S* to use as
nonce.  Then, the joining node can send a Joining Request,
conveying a reused N_C* nonce in 'cnonce' and an old stored
signature in 'client_cred_verify', computed over N_C* | N_S*. By
verifying the signature, the Group Manager would falsely believe
that the joining node possesses its own private key at that point
in time.
Since N_C is always conveyed in a secured Joining Request, it is
practically infeasible for an on-path attacker to replay Joining
Requests from a joining node to the Group Manager, in order to
cause that joining node to use an arbitrary nonce N_S.
Section 7 of I-D.ietf-ace-oscore-profile as well Appendix B.2 of
RFC8613 recommend the use of 8-byte random nonces as well.  Unlike
in those cases, the nonces N_C and N_S considered in this
specification are not used for as sensitive operations as the
derivation of a Security Context, with possible implications in
the security of AEAD ciphers.
For the N_C challenge share, it is RECOMMENDED to use a 8-byte long
random nonce.  Furthermore, N_C is always conveyed in the 'cnonce'
parameter of the Joining Request, which is always sent over the
secure communication channel between the joining node and the Group
Manager.
As defined in sssec-challenge-value, the way the N_S value is
computed depends on the particular way the joining node provides the
Group Manager with the Access Token, as well as on following
interactions between the two.
If the Access Token is not explicitly posted to the /authz-info
endpoint of the Group Manager, then N_S is computed as a 32-byte
long challenge share (see points 2 of sssec-challenge-value).
If the Access Token has been explicitly posted to the /authz-info
endpoint of the Group Manager, N_S takes the most recent value
specified to the client by the Group Manager in the 'kdcchallenge'
parameter (see point 1 of sssec-challenge-value).  This is
specified either in the 2.01 response to the Token Post (see ssec-
token-post), or in a 4.00 response to a following Joining Request
(see ssec-join-req-processing).  In either case, it is RECOMMENDED
to use a 8-byte long random challenge as value for N_S.
If we consider both N_C and N_S to take 8-byte long values, the
following considerations hold.
Let us consider both N_C and N_S as taking random values, and the
Group Manager to never change the value of the N_S provided to a
Client during the lifetime of an Access Token.  Then, as per the
birthday paradox, the average collision for N_S will happen after
2^32 new posted Access Tokens, while the average collision for N_C
will happen after 2^32 new Joining Requests.  This amounts to
considerably more token provisionings than the expected new
joinings of OSCORE groups under a same Group Manager, as well as
to considerably more requests to join OSCORE groups from a same
Client using a same Access Token under a same Group Manager.
Section 7 of I-D.ietf-ace-oscore-profile as well Appendix B.2 of
RFC8613 recommend the use of 8-byte random values as well.  Unlike
in those cases, the values of N_C and N_S considered in this
specification are not used for as sensitive operations as the
derivation of a Security Context, with possible implications in
the security of AEAD ciphers.
As long as the Group Manager preserves the same N_S value currently
associated to an Access Token, i.e. the latest value provided to a
Client in a 'kdcchallenge' parameter, the Client is able to
successfully reuse the same signature challenge for multiple Joining
Requests to that Group Manager.
In particular, the client can reuse the same N_C value for every
Joining Request to the Group Manager, and combine it with the same
unchanged N_S value.  This results in reusing the same signature
challenge for producing the signature to include in the
'client_cred_verify' parameter of the Joining Requests.
Unless the Group Manager maintains a list of N_C values already used
by that Client since the latest update to the N_S value associated to
the Access Token, the Group Manager can be forced to falsely believe
that the Client possesses its own private key at that point in time,
upon verifying the signature in the 'client_cred_verify' parameter.
IANA is asked to register the following entry in the "ACE Groupcomm
Policy" Registry defined in Section 8.7 of I-D.ietf-ace-key-
groupcomm.
Description: True if the OSCORE group supports the pairwise mode
of Group OSCORE I-D.ietf-core-oscore-groupcomm, False otherwise.