Group key support

[xisentian]

As discussed during IETF-123

[ekr]

This requirement seems quite incomplete. I don't know whether the requirement is real or not, but it's nowhere near enough to have a group key management protocol, you need a communications protocol which sensibly knows how to incorporate messages from >2 parties, and those protocols are typically quite different from two-party protocols.

Note that MLS (1) mostly just punts this to the messaging system to know what to do (2) uses signatures to avoid impersonation and (3) has still had challenges in this area.

[br-hale]

Space systems often work in enclaves, so yes - efficient multi-device security is necessary.

This document is talking about properties, not specific protocols, so the rest of the comment is off topic.

[ekr]

Space systems often work in enclaves, so yes - efficient multi-device security is necessary.

I'm not really seeing the connection between enclaves and multi-device security. Can you elaborate.

This document is talking about properties, not specific protocols, so the rest of the comment is off topic.

No, I don't think this is correct, for two reasons:

1. Because this is difficult, one needs to be really sure that it's needed.
2. If it is in fact needed, then this document actually needs to spell out what's required rather than just handwave about "group keying"

[wesley-eddy]

I think it could benefit from some discussion of the applications envisioned to need this and the protocol layers where it's needed (is it in QUIC or in IPsec?).

Group communication is an important application pattern to support. An easy case to explain is for human exploration, suit radios historically just broadcasted radio, to be picked up by any other suits, vehicles, repeaters, etc. on the channel. Those types of voice flows will probably move to IP and could use some type of group security in the future. There are other cases such as distributing space weather warnings (like incoming solar particles), etc. In the LunaNet specs, the AFS (Augmented Forward Signal) is defined, which is broadcast with some ability to send data messages. If protected, those messages would probably need to use some type of group keying because many of the message types are intended for multiple receivers.

[marcblanchet]

My take is that the current text is way too strong as a requirement. I suggest @xisentian to update the text more into informing that this technology exists and can be used in some contexts.

[gorryfair]

Echo'ing Wes: Could this group security be based on IPsec?

[br-hale]

Echo'ing Wes: Could this group security be based on IPsec?

The text does not describe specific protocols for handling groups / multiple devices sharing and acting on information. It only describes that it must be supportable within the environment (delay / bandwidth limited) variables. It would be narrow-signed to assume that 1:1 link planning will naturally work well for enclaves and groups in this domain when needed, as space is not like the terrestrial domain in terms of communication. So, it is key to define expected topologies and work from that. I.e., the point of this document being to plan for the use case and then see what matches it. So IPsec is not out of scope in that regard. It would depend on testing results and correct alignment to environment variables.

Objections on this thread to ensuring scalability to groups are necessarily limiting focus to single-device use cases, which should be obvious as far to narrow-focused. We know as a fact that 1) single-device-to-ground cases are not the only use (or even main use) in space communication and it would be ill-planned to test to only that and 2) the interactions among many devices is quite different in space networking than it is terrestrially, especially in deeper space. Since the WG vote and charter is explicitly beyond the moon, (2) has to be accounted for.

[ekr]

Objections on this thread to ensuring scalability to groups are necessarily limiting focus to single-device use cases, which should be obvious as far to narrow-focused.

This is not entirely correct. As I said above: #46 (comment)

1. It's not yet clear to me that this is required. And "space is different" is not really persuasive. Can you point to some specific written descriptions of cases that need group keying.
2. It's underspecified. Group messaging is a lot more complicated than just having a group key, so we need to know what's actually required, which brings us back to the need for some specific descriptions of cases.

[br-hale]

1. It's not yet clear to me that this is required. And "space is different" is not really persuasive. Can you point to some specific written descriptions of cases that need group keying.

See other comments above. LunaNet is a specific example. Basically every other proposed configuration by space agencies include further examples (see online).

2. It's underspecified. Group messaging is a lot more complicated than just having a group key, so we need to know what's actually required, which brings us back to the need for some specific descriptions of cases.

Your comments on the PR are the only point were "messaging" or specific protocols ("MLS") is being discussed. No one else has raised it and it is not part of the PR itself. These comments are creating issues to debate and unrelated to the text at hand, which is, specifically, about supporting groups of devices that need to communicate.

[ekr]

Your comments on the PR are the only point were "messaging" or specific protocols ("MLS") is being discussed.

You're misunderstanding me. I was citing MLS as an example of why one needs to say something more than "we need to support groups", not expressing an opinion on whether "messaging" is required here. I do believe this issue is related to the text at hand, which, as I said, is too underspecified to be treated as a requirement,

Thanks for the pointer to LunaNet. I'll take a look and see if it clarifies what's actually required here.

[marcblanchet]

I'm not sure which LunaNet documents we are talking about. I read few months ago the last version of the LunaNet Interoperability Specification (https://www.nasa.gov/wp-content/uploads/2025/02/lunanet-interoperability-specification-v5-baseline.pdf), and I don't recall anything about this topic. At least in that document, searching for the term "group" does not really bring anything.

[br-hale]

You will find it starting in the Introduction section of the article you linked, and carrying through out.
Sometimes the design spec is better than a keyword search.