Potential Identity Misbinding in RaptorCast Secondary Client Implementation

Summary

The RaptorCast secondary client trusts validator_id embedded inside PrepareGroup and ConfirmGroup messages instead of binding those values to the sender identity already recovered from the authenticated UDP packet.

That creates an identity-misbinding issue: a message can be signed by one node while claiming to be from another validator inside its payload.

Root Cause

The primary instance verifies the UDP message and learns the true sender, but the forwarding path to the secondary instance loses that authenticated identity. The secondary client then uses the embedded validator_id when:

• deciding where to send responses
• accepting group-confirmation data
• constructing the client-side group state

1
if accept {
2
    self.pending_confirms
3
        .entry(invite_msg.start_round)
4
        .or_default()
5
        .insert(invite_msg.validator_id, invite_msg.clone());
6
}

1
let maybe_entry = invites.get(&confirm_msg.prepare.validator_id);
2
let Some(old_invite) = maybe_entry else {
3
    return;
4
};
5

6
if old_invite != &confirm_msg.prepare {
7
    return;
8
}
9

10
let group = GroupAsClient::new_fullnode_group(
11
    confirm_msg.peers,
12
    &self.client_node_id,
13
    confirm_msg.prepare.validator_id,
14
    round_span,
15
);

Impact

An attacker can impersonate another validator in group-formation traffic and cause a full node to accept group membership that was not authorized by the real validator. That undermines the integrity of group formation and can misroute subsequent traffic.

Recommendation

Preserve the authenticated sender identity when handing messages to the secondary instance, then reject any message whose claimed validator does not match the verified sender. A stronger variant is to sign the group message payload itself and validate that signature against the claimed validator.