[core] Re: Review of draft-ietf-core-oscore-groupcomm-17

[Marco Tiloca <[e-mail]>]

Hi Christian,

Thanks! See our replies below. Please note that:

* All these points were addressed (with or without an action) in the 
versions following v -17. Last year we actually had the opportunity to 
discuss those points with you during a few side meetings.

* We will shortly reply with a separate mail to your follow-up comments 
on v -17 archived at 
https://mailarchive.ietf.org/arch/msg/core/zX5DsiXWXnDv3U2Hqs955M8uMCc/

* We will work on a separate reply to your comments on v -21 archived at 
https://mailarchive.ietf.org/arch/msg/core/tPPSsrFMPZId_7Q7OrmbgN1DCdw/

Best,
/Marco (for the authors team)

On 2024-07-01 22:02, Christian Amsüss wrote:
> Hello oscore-groupcomm authors,
>
> as part of having read the updated document, I'm going through the
> review that initiated many of the changes for open points.
>
> While there are points which I'm still reviewing in more detail, and
> some remarks based on the latest version, what I can start with is a
> list of items I found neither changed nor mentioned in a response (or I
> missed where that happened). Many of those may easily be fine, just want
> to make sure none of that is getting lost:
>
> * 2.1.6 "The label is an ASCII string": Given that the type element in
>    the info array is a CBOR item, it can only be a byte or a text string;
>    I assume that the latter is meant. (And these don't typically contain
>    trailing NUL bytes).

==>MT

Yes, it's a CBOR text string, per the CDDL definition of the 'info' 
array inherited from RFC 8613.

The quoted text uses the same formulation of Section 3.2.1 of RFC 8613, 
where the clarification "The label is an ASCII string and does not 
include a trailing NUL byte" is also given.

Therefore, the text was kept as is, for consistency with RFC 8613.

<==

>
> * 4., "OSCORE uses the untagged COSE_Encrypt0 structure with an
>    Authenticated Encryption with Associated Data (AEAD) algorithm":
>    After compression, it doesn't matter any more whether it's the tagged
>    or the untagged COSE_Encrypt0 structure.

==>MT

That is correct. However, it is the same formulation used in Section 5 
of RFC 8613, where exactly the same applies.

Therefore, the text was kept as is, for consistency with RFC 8613.

<==

>
> * In verifying that the now explicit arithmetic for the Ed25519 /
>    Curve25519 mapping is what I'm using, I found that libsodium (from
>    where I lifted my implementation) since very recently contains a note
>    on its ed25519_..._to_curve25519 functions that "An alternative is do
>    the ECDH operation over the Edwards curve, avoiding the conversion
>    altogether"[2].
>
>    Given that a lot of work has gone into making the Ed25519/X25519
>    conversion work, I hope that no easy alternatives to this moderately
>    cumbersome process (admittedly, it's the hardest in terms of spec
>    text, and probably easier on the target CPU than on the programmer)
>    have been missed, but I'd appreciate if someone who understood what's
>    actually going on here could verify that whatever they're proposing
>    doesn't apply here.

==>MT

The considered manual coordinate conversion has been proved secure by 
Erik Thormarker [THORMARKER], it is aligned with a specification, and it 
is simple.

In addition, we would like to keep one method to compute a 
Diffie-Hellman secret starting from EdDSA keys, and we do have that one 
already.

On this topic, we also got the following two inputs from Erik Thormarker:

**First input:**

 > Note that the private EdDSA key needs to be extracted if it is being 
used for DH, independent of curve.
 >
 >
 > In theory it is secure to do DH direcly on the peer’s EdDSA key. In 
practice EdDSA and DH can have different APIs which makes it complicated.
 >
 > Note also that there are different assumptions on the points which 
are operated on. X25519 needs to protect the static key with a constant 
time scalar multiplication on a variable attacker-chosen point on the 
curve [X].
 >
 > There may be problems in implementations doing DH on EdDSA keys. It 
happens to be supported in libsodium, but not clear how widely supported 
it is.
 >
 >  [X] 
https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures
 >

**Second input:**

 > Both parties need to agree on which curve coordinates they put in the 
hash function, so one party cannot silently choose to stay on the 
Edwards curve. If the party staying on the Edwards curve needs to map to 
Montgomery afterwards anyway (to agree on the hash function input), you 
could just as well map before the DH as in the current draft.
 >
 > If doing it on the Edwards curve, the parties would need to agree on 
the format of the DH result to put into the hash function (e.g., use 
both coordinates or only one).
 >
 > The current draft also says that parties must abort on some public 
keys for which the mapping to Montgomery coordinates is undefined.
 >
 > For edwards448 to curve448 I think the mapping used in the draft 
(from Section 4.2 of RFC 7748) induces a scalar multiplication by 4 (the 
mapping is “4-isogenous”), which is OK for the current draft since both 
sides do one mapping operation each.
 >
 > Taking the approach from libsodium can rely on computing the 
Diffie-Hellman secret from Edwards coordinate first, and then do the 
coordinate mapping afterwards. However, such a mapping needs to be 
performed in constant time, which may be more difficult compared to 
performing the coordinate conversion as a first thing altogether, before 
computing the Diffie-Hellman secret over Montgomery coordinates.
 >
 > Furthermore, the computation of a Diffie-Hellman secret over 
Montgomery coordinates should be as per the standard X25519, so 
libsodium should support this method.


Therefore, we made no change about this in the document.

[THORMARKER] https://eprint.iacr.org/2021/509

<==

> * Now that authentication credentials are a thing in Group OSCORE, and
>    these can in particular be CWTs or ?509 certificates that can have
>    chains leading there: Does this mean that for deployments such as the
>    pairwise-only one sketched at the last paragraph above Section 1.1,
>    it's possible to run a group on more-or-less unchanged group key
>    material, and members join by means of learning the current key
>    material and obtaining a signed certificate to their key? (When they
>    then arrive in the group, they start communicating, and when their
>    peers need the credentials, those can be disseminated in a
>    self-contained way, eg. by the new node itself -- without involving
>    the GM).

==>MT

TL;DR: Something like the above might be engineered somehow, but it can 
rather be left out of the scope of this document.

At the moment we do not mean to imply that such a provisioning approach 
is possible, or to take any particular stance about that. At the same 
time, as things are described now:

* The Group Manager is the solely intended repository of authentication 
credentials of group members.

* Each group member uploads its authentication credential to the Group 
Manager and obtains the other group members' authentication credentials 
from the Group Manager.

Just for the sake of the argument, these are first thoughts.

The authentication credential of a joining node would also need to be 
countersigned by the Group Manager, as vouching for the current 
membership of that node in the group, building on having achieved 
proof-of-possession for the private key of that node (see Section 3.1 of 
v -21).

In most cases, the Group Manager can countersign the authentication 
credential by using the private key corresponding to the same Group 
Manager's authentication credential used in the group, and that the 
group members also obtain upon joining.

However, if the group uses only the pairwise mode of Group OSCORE, then 
the Group Manager's authentication credential includes a Diffie-Hellman 
public key, hence the group members would have to somehow acquire a 
separate Group Manager's public key for verifying the Group Manager's 
countersignature on each others' authentication credential.

That is, this seems to be in principle doable, with quite a few things 
that may require proper engineering.

* Upon joining the group:
   * The joining node must still provide its own authentication 
credential to the Group Manager, which still has to achieve 
proof-of-possession of the corresponding private key.
   * The joining node must obtain from the Group Manager a countersigned 
version of its own public authentication credential.
   * If the group uses only the pairwise mode, the joining node must 
obtain from the Group Manager a separate signing authentication 
credential of the Group Manager to be used for verifying such 
countersignature on the authentication credentials of other group members.

* When sending (the first? some? every?) message to the group, a node 
has to somehow embed also its countersigned public authentication 
credential.

   If no special care is taken, this will prove that the node was a 
group member at the point in time when the Group Manager computed the 
countersignature, but not necessarily when a recipient group member 
verifies that countersignature.

   This could be addressed by including together with the 
countersignature an information that binds the public authentication 
credential with the version of the group keying material (this concept 
is defined in this document already, not in 
draft-ietf-ace-key-groupcomm-oscore). That information has also to be 
input to the signing process.

Perhaps this can be material for a separate document focused on 
alternative distribution of authentication credentials.

<==

> * Is the attack described in 13.7 ("Cross-group Message Injection")
>    still possible now that request_kid_context and gm_cred are part of
>    the eAAD? My impression (but without thorough checking) is that it
>    wouldn't work any more because the gm_cred differ.
>
>    Having the OSCORE option in the signature is a bit convoluted in
>    implementations (not impossible, and can be optimized out, but
>    requires some mental gymnastics), and AIU 13.7 is the only reason to
>    have the OSCORE option in the eAAD in the first place.

==>MT

In short, the attack is not feasible to perform thanks to the current 
design as-is, i.e., with the external_aad also taking into account 
request_kid_context, gm_cred, and the OSCORE Option of the present message.

In general, gm_cred would not differ. The two groups might be operated 
by the same Group Manager. If those two groups rely on the same format 
of authentication credential for the same kind of algorithm/curve, then 
the Group Manager can use exactly the same authentication credential in 
both of them.

Besides, covering specifically the OSCORE Option in the external_aad 
allows to prevent the attack also if mounted on response messages. 
That's otherwise not possible, since the kid, kid_context, and piv in 
the external_aad refer to the corresponding values that the original 
request had in its OSCORE Option. Instead, the OSCORE Option in the 
external_aad is exactly as in the present message to process.

On taking the OSCORE Option as input to the signature process: yes, 
preventing this attack is the only reason. It was judged simpler than 
extending the external_aad separately with the different pieces of 
information this_message_kid, this_message_kid_context, 
this_message_piv, which would also be not flexible to possible further 
extensions of the OSCORE Option introduced in the future.

Therefore, we made no changes in the draft.

<==

> * A.1, forward and backward security: These look more like objectives
>    (A.2) than assumptions (A.1) to me.

==>MT

We intended them to be assumptions, since ensuring those is out of the 
scope of Group OSCORE itself, see the beginning of Appendix A.1:

 > The following points are assumed to be already addressed and are out 
of the scope of this document.

That is, Group OSCORE itself is not required/expected to ensure backward 
and forward security. That's up to the rekeying algorithm performed, 
e.g., by the Group Manager.

Consistently, we did rename the two bullet points as follows:

OLD:
 > Backward security

NEW:
 > Ensuring backward security

OLD:
 > Forward security

NEW:
 > Ensuring forward security

<==

>
> * 13.5.1, "the recipient can still try to process the received message
>    using the old retained Security Context as a second attempt": Why is
>    that a second attempt? This makes it sound like the server attempts
>    decryption, encounters a bad signature, and then retries with the old
>    context, whereas what actually happens is that the server sees the old
>    Gid, and still has that security context around.

==>MT

That was a good catch, and we did address it.

There is actually a case where it is indeed a second attempt, i.e., if 
the message in question is a response received at the client and not 
including the Gid (which, in responses, is optional and typically not 
included).

In Section 13.5.1, we expanded that paragraph as follows.

OLD:
 > By doing so, the recipient can still try to process the received 
message using the old retained Security Context as a second attempt. 
This makes particular sense when the recipient is a client, that would 
hence be able to process incoming responses protected with the old, 
recent, Security Context used to protect the associated group request. 
Instead, a recipient server would better and more simply discard an 
incoming group request which is not successfully processed with the new 
Security Context.

NEW:
 > By doing so, the recipient can still try to process the received 
message using the old retained Security Context.
 >
 > This makes particular sense when the recipient is a client, that 
would hence be able to process incoming responses protected with the old 
retained Security Context used to protect the associated request. If, as 
typically expected, the old Gid is not included in the response, then 
the client will first fail to process the response using the latest 
Security Context, and then use the old retained Security Context as a 
second attempt.
 >
 > Instead, a recipient server can immediately process an incoming 
request with the old retained Security Context, as signaled by the old 
Gid that is always included in requests. However, the server would 
better and more simply discard such an incoming request.

<==

>
> * 13.14: Does it make sense to show client aliveness? The server gets
>    client aliveness relative to the last rekeying, but an application
>    that requires aliveness exceeding that would cause a storm of Echo
>    options that could have better been handled by 1:1 communication (or
>    more frequent rekeying) in the first place.

==>MT

That was a good consideration, since some client aliveness is ensured 
here. Not to the extent of the current message exchange, but at least of 
the current epoch of group keying material.

We largely revised Section 13.14, now consisting of the text below:

 > As in OSCORE, Group OSCORE provides only the guarantee that the 
request is not older than the Group OSCORE Security Context used to 
protect it. Other aspects of freshness are discussed in Section 6.2.
 >
 > The challenge-response approach described in Section 10 provides an 
assurance of freshness of the request without depending on the honesty 
of the client. However, it can result in an impact on performance which 
is undesirable or unbearable, especially in large groups where many 
endpoints at the same time might join as new members or lose 
synchronization.
 >
 > Endpoints configured as silent servers are not able to perform the 
challenge-response described above, as they do not store a Sender 
Context to secure the 4.01 (Unauthorized) response to the client. Thus, 
silent servers should adopt alternative approaches to achieve and 
maintain synchronization with Sender Sequence Numbers of clients.
 >
 > Since requests including the Echo Option are sent over unicast, a 
server can be victim of the attack discussed in Section 13.9, in case 
such requests are protected in group mode. Instead, protecting those 
requests with the pairwise mode prevents the attack above. In fact, only 
the very server involved in the challenge-response exchange is able to 
derive the pairwise key used by the client to protect the request 
including the Echo Option.
 >
 > In either case, an internal on-path adversary would not be able to 
mix up the Echo Option value of two different unicast requests, sent by 
a same client to any two different servers in the group. In fact, even 
if the group mode was used, this would require the adversary to forge 
the countersignature of both requests. As a consequence, each of the two 
servers remains able to selectively accept a request with the Echo 
Option only if it is waiting for that exact integrity-protected Echo 
Option value, and is thus the intended recipient.

<==

>
> BR
> Christian
>
> [2]: https://github.com/jedisct1/libsodium-doc/commit/0732187608798b7b6d48d291ed1562fb28cf1e36 / https://doc.libsodium.org/advanced/ed25519-curve25519
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se