Skip verication of PoP evidence if PoP was already achieved - closes #89

draft-ietf-ace-key-groupcomm-oscore.md

@@ -524,7 +524,19 @@ The joining node requests to join the OSCORE group by sending a Join Request mes
 
 * 'cnonce' contains a dedicated nonce N_C generated by the joining node. For the N\_C value, it is RECOMMENDED to use an 8-byte long random nonce.
 
-* The proof-of-possession (PoP) evidence included in 'client_cred_verify' is computed as defined below (REQ14). In either case, the N_S used to build the PoP input is as defined in {{sssec-challenge-value}}.
+* The proof-of-possession (PoP) evidence included in 'client_cred_verify' is computed as defined below (REQ14). The N_S used to build the PoP input is as defined in {{sssec-challenge-value}}.
+
+   - Under specific circumstances, the Group Manager can already have achieved proof-of-possession of the joining node's private key associated with the joining node's authentication credential.
+
+     The following refers to AUTH_CRED_C as the authentication credential that is (meant to be) associated with the joining node, in the OSCORE group that the joining node is requesting to join. Note that AUTH_CRED_C can be specified in the 'client_cred' parameter of the Join Request, or be already stored by the Group Manager as acquired from previous interactions with the joining node (see {{sec-public-keys-of-joining-nodes}}).
+
+     The joining node MAY avoid providing the PoP evidence, and instead specify the empty CBOR byte string (0x40) as value of the 'client_cred_verify' parameter, if the following held upon completing the establishment of the secure communication association used to protect the Join Request:
+
+       * The Group Manager authenticated the joinining node by means of AUTH_CRED_C.
+
+       * The Group Manager achieved proof-of-possession of the joining node's private key associated with AUTH_CRED_C.
+
+     If the conditions above do not hold or the joining node prefers to specify the PoP evidence in the 'client_cred_verify' parameter, then the joining node computes the PoP evidence as specified below.
 
    - If the group is not a pairwise-only group, the PoP evidence MUST be a signature. The joining node computes the signature by using the same private key and signature algorithm it intends to use for signing messages in the OSCORE group.
 
@@ -568,15 +580,27 @@ It is up to applications to define how N_S is computed in further alternative se
 
 The Group Manager processes the Join Request as defined in {{Section 4.3.1 of RFC9594}}, with the following additions.
 
-The Group Manager verifies the PoP evidence contained in 'client_cred_verify' as follows:
+* If the 'client_cred_verify' parameter of the Join Request specifies the empty CBOR byte string (0x40), the Group Manager proceeds as below.
+
+  The following refers to AUTH_CRED_C as the authentication credential that is (meant to be) associated with the joining node, in the OSCORE group that the joining node is requesting to join. Note that AUTH_CRED_C can be specified in the 'client_cred' parameter of the Join Request, or be already stored by the Group Manager as acquired from previous interactions with the joining node (see {{sec-public-keys-of-joining-nodes}}).
 
-* As PoP input, the Group Manager uses the value of the 'scope' parameter from the Join Request as a CBOR byte string, concatenated with N_S encoded as a CBOR byte string, concatenated with N_C encoded as a CBOR byte string. The value of N_S is determined as described in {{sssec-challenge-value}}, while N_C is the nonce provided in the 'cnonce' parameter of the Join Request.
+  The Group Manager checks whether the following held upon completing the establishment of the secure communication association used to protect the Join Request:
 
-* As public key of the joining node, the Group Manager uses either the one included in the authentication credential retrieved from the 'client_cred' parameter of the Join Request, or the one from the already stored authentication credential as acquired from previous interactions with the joining node (see {{sec-public-keys-of-joining-nodes}}).
+  * The Group Manager authenticated the joinining node by means of AUTH_CRED_C.
 
-* If the group is not a pairwise-only group, the PoP evidence is a signature. The Group Manager verifies it by using the public key of the joining node, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
+  * The Group Manager achieved proof-of-possession of the joining node's private key associated with AUTH_CRED_C.
 
-* If the group is a pairwise-only group, the PoP evidence is a MAC. The Group Manager recomputes the MAC through the same process taken by the joining node when preparing the value of the 'client_cred_verify' parameter for the Join Request (see {{ssec-join-req-sending}}), with the difference that the Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Request.
+  In case of successful verification of the conditions above, the Group Manager skips the verification of the PoP evidence. Otherwise, the Group Manager MUST reply with a 4.00 (Bad Request) error response.
+
+* If the 'client_cred_verify' parameter of the Join Request specifies a value different from the empty CBOR byte string (0x40), then the Group Manager verifies the PoP evidence contained in 'client_cred_verify' as follows:
+
+  * As PoP input, the Group Manager uses the value of the 'scope' parameter from the Join Request as a CBOR byte string, concatenated with N_S encoded as a CBOR byte string, concatenated with N_C encoded as a CBOR byte string. The value of N_S is determined as described in {{sssec-challenge-value}}, while N_C is the nonce provided in the 'cnonce' parameter of the Join Request.
+
+  * As public key of the joining node, the Group Manager uses either the one included in the authentication credential retrieved from the 'client_cred' parameter of the Join Request, or the one from the already stored authentication credential as acquired from previous interactions with the joining node (see {{sec-public-keys-of-joining-nodes}}).
+
+  * If the group is not a pairwise-only group, the PoP evidence is a signature. The Group Manager verifies it by using the public key of the joining node, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
+
+  * If the group is a pairwise-only group, the PoP evidence is a MAC. The Group Manager recomputes the MAC through the same process taken by the joining node when preparing the value of the 'client_cred_verify' parameter for the Join Request (see {{ssec-join-req-sending}}), with the difference that the Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Request.
 
 The Group Manager MUST reply with a 5.03 (Service Unavailable) error response in the following cases:
 
@@ -724,6 +748,18 @@ Furthermore, the following applies.
 
 * 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).
 
+   - Under specific circumstances, the joining node can already have achieved proof-of-possession of the Group Manager's private key associated with the Group manager's authentication credential.
+
+     The following refers to AUTH_CRED_GM as the authentication credential specified in the 'kdc_cred' parameter.
+
+     The Group Manager MAY avoid providing the PoP evidence, and instead specify the empty CBOR byte string (0x40) as value of the 'kdc_cred_verify' parameter, if the following held upon completing the establishment of the secure communication association used to protect the Join Response:
+
+     * The joining node authenticated the Group Manager by means of AUTH_CRED_GM.
+
+     * The joining node achieved proof-of-possession of the Group Manager's private key associated with AUTH_CRED_GM.
+
+     If the conditions above do not hold or the Group Manager prefers to specify the PoP evidence in the 'kdc_cred_verify' parameter, then the Group Manager computes the PoP evidence as specified below.
+
    - 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.
 
    - If the group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps {{RFC5869}}.
@@ -746,11 +782,23 @@ As a last action, if the Group Manager reassigns Gid values during the group's l
 
 ## Receive the Join Response {#ssec-join-resp-processing}
 
-Upon receiving the Join Response, the joining node retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter. The joining node MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter of the Join Response as defined below (REQ21).
+Upon receiving the Join Response, the joining node retrieves the Group Manager's authentication credential AUTH_CRED_GM from the 'kdc_cred' parameter.
+
+The joining node MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter of the Join Response as defined below (REQ21).
 
-* If the group is not a pairwise-only group, the PoP evidence is a signature. The joining node verifies it by using the public key of the Group Manager from the received authentication credential, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
+* If the 'kdc_cred_verify' parameter of the Join Response specifies the empty CBOR byte string (0x40), the joining node checks whether the following held upon completing the establishment of the secure communication association used to protect the Join Response:
 
-* If the group is a pairwise-only group, the PoP evidence is a MAC. The joining node recomputes the MAC through the same process taken by the Group Manager when computing the value of the 'kdc_cred_verify' parameter (see {{ssec-join-resp}}), with the difference that the joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager from the received authentication credential. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Response.
+  * The joining node authenticated the Group Manager by means of AUTH_CRED_GM.
+
+  * The joining node achieved proof-of-possession of the Group Manager's private key associated with AUTH_CRED_GM.
+
+  In case of successful verification of the conditions above, the joining node skips the verification of the PoP evidence. Otherwise, the joining node MUST stop processing the Join Response and MAY send a new Join Request to the Group Manager (see {{ssec-join-req-sending}}).
+
+* If the 'kdc_cred_verify' parameter of the Join Response specifies a value different from the empty CBOR byte string (0x40), then the joining node verifies the PoP evidence contained in 'kdc_cred_verify' as follows:
+
+  * If the group is not a pairwise-only group, the PoP evidence is a signature. The joining node verifies it by using the public key of the Group Manager from the received authentication credential, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
+
+  * If the group is a pairwise-only group, the PoP evidence is a MAC. The joining node recomputes the MAC through the same process taken by the Group Manager when computing the value of the 'kdc_cred_verify' parameter (see {{ssec-join-resp}}), with the difference that the joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager from the received authentication credential. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Response.
 
 In case of failed verification of the PoP evidence, the joining node MUST stop processing the Join Response and MAY send a new Join Request to the Group Manager (see {{ssec-join-req-sending}}).
 
@@ -2291,6 +2339,8 @@ sign_params = 11
 
 * Relation between 'cred_fmt' and Authentication Credential Format.
 
+* Skip verication of PoP evidence if PoP was already achieved.
+
 * GET to ace-group/GROUPNAME/kdc-cred only for group members.
 
 * Added FETCH handler for /ace-group/GROUPNAME/kdc-cred.