Skip to content

Commit

Permalink
Consistent mandatory use of 'cnonce' - close #69
Browse files Browse the repository at this point in the history
  • Loading branch information
marco-tiloca-sics committed Nov 16, 2024
1 parent bd2407b commit d6397c2
Showing 1 changed file with 5 additions and 3 deletions.
8 changes: 5 additions & 3 deletions draft-ietf-ace-key-groupcomm-oscore.md
Original file line number Diff line number Diff line change
Expand Up @@ -296,7 +296,7 @@ As also discussed in {{I-D.ietf-core-oscore-groupcomm}}, the Group Manager acts

In particular, the following applies when a node joins an OSCORE group.

* The joining node is going to join the group exclusively as monitor, i.e., it is not going to send messages to the group. In this case, the joining node is not required to provide its own authentication credential to the Group Manager, which thus does not have to perform any check related to the format of the authentication credential, to a signature or ECDH algorithm, and to possible parameters associated with the algorithm and the public key. In case the joining node still provides an authentication credential in the 'client_cred' parameter of the Join Request (see {{ssec-join-req-sending}}), the Group Manager silently ignores that parameter, as well as the related parameters 'cnonce' and 'client_cred_verify'.
* The joining node is going to join the group exclusively as monitor, i.e., it is not going to send messages to the group. In this case, the joining node is not required to provide its own authentication credential to the Group Manager, which thus does not have to perform any check related to the format of the authentication credential, to a signature or ECDH algorithm, and to possible parameters associated with the algorithm and the public key. In case the joining node still provides an authentication credential in the 'client_cred' parameter of the Join Request (see {{ssec-join-req-sending}}), the Group Manager silently ignores that parameter and the related parameter 'client_cred_verify'.

* The Group Manager already acquired the authentication credential of the joining node during a past joining process. In this case, the joining node MAY choose not to provide again its own authentication credential to the Group Manager, in order to limit the size of the Join Request. The joining node MUST provide its own authentication credential again if it has provided the Group Manager with multiple authentication credentials during past joining processes, intended for different OSCORE groups. If the joining node provides its own authentication credential, the Group Manager performs consistency checks as per {{ssec-join-req-processing}} and, in case of success, considers it as the authentication credential associated with the joining node in the OSCORE group.

Expand Down Expand Up @@ -700,7 +700,7 @@ Furthermore, the following applies.

* The 'kdc_nonce' parameter MUST be present, specifying the dedicated nonce N_KDC generated by the Group Manager. For N_KDC, it is RECOMMENDED to use an 8-byte long random nonce.

* The 'kdc_cred_verify' parameter MUST be present, specifying the proof-of-possession (PoP) evidence computed by the Group Manager. The PoP evidence is computed over the nonce N_KDC, which is specified in the 'kdc_nonce' parameter and taken as PoP input. The PoP evidence is computed as defined below (REQ21).
* The 'kdc_cred_verify' parameter MUST be present, specifying the proof-of-possession (PoP) evidence computed by the Group Manager. The PoP evidence is computed as defined below (REQ21).

- If the group is not a pairwise-only group, the PoP evidence MUST be a signature. The Group Manager computes the signature by using the signature algorithm used in the OSCORE group, as well as its own private key associated with the authentication credential specified in the 'kdc_cred' parameter.

Expand Down Expand Up @@ -1522,7 +1522,7 @@ The Group Manager is expected to support all the parameters above. Instead, a Cl

When the conditional parameters defined in {{Section 8 of RFC9594}} are used with this application profile, a Client must, should or may support them as specified below (REQ30).

* 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has an own authentication credential to use in a group MUST support these parameters.
* 'client_cred' and 'client_cred_verify'. A Client that has an own authentication credential to use in a group MUST support these parameters.

* 'kdcchallenge'. A Client that has an own authentication credential to use in a group and that provides the access token to the Group Manager through a Token Transfer Request (see {{ssec-token-post}}) MUST support this parameter.

Expand Down Expand Up @@ -2182,6 +2182,8 @@ sign_params = 11

* Clarified meaning of 'cred_fmt'.

* Consistent mandatory use of 'cnonce'.

* Relation between 'cred_fmt' and Authentication Credential Format.

* GET to ace-group/GROUPNAME/kdc-cred only for group members.
Expand Down

0 comments on commit d6397c2

Please sign in to comment.