Federation Trust Boundary Analysis

A security audit of the multi-server federation layer: trust boundaries, authorization gaps, risk areas, and concrete recommendations to bring federation access control in line with the single-server club model.

1. Executive Summary

The federation layer establishes an encrypted, mutually-authenticated channel between servers using sound cryptography (X25519 + Ed25519 + ChaCha20-Poly1305). Once a peer passes the handshake, however, it operates as a privileged super-user with broad read/write access to the local data store. There is no per-work, per-blob, or per-edition authorization on federation requests — the club-based access control that protects content in the single-server model is bypassed entirely on the federation data plane.

This document maps every trust boundary, catalogs the authorization gaps by severity, and provides concrete recommendations for aligning federation access control with the existing single-server club model.

2. Architecture Overview: Where the Boundaries Are

Seven trust boundaries in the federation stack. Green = cryptographically sound. Red = authorization gaps. Purple = consensus layer with gaps.

3. Boundary 1: Connection Admission

The mechanism

The /federation WebSocket route (build_federation_router, federation_handler.rs:184) accepts connections with no middleware, no CSRF guard, no rate limiter, and no IP allowlist. The handler handle_federation_socket performs the handshake inline.

Trust assumption

Anyone who can reach the port may open the socket; security rests entirely on the cryptographic handshake (Boundary 2).

Risks

4. Boundary 2: Peer Authentication (Handshake)

The mechanism

Three-step handshake producing an encrypted channel:

1. Hello: Exchange protocol version + X25519 ephemeral key + server_id
2. Signature: Each side signs (my_eph, peer_eph) with its Ed25519 identity key, sends verifying key + kex key
3. Ready: First encrypted frame; session keys derived via X25519 + HKDF with domain-separated labels

Then federation_is_peer_known (server.rs:11116) gates on the operator-configured known_peer_keys set.

Risks

5. Boundary 3: Read Access (Data Plane)

This is the most critical area. After the handshake, an authenticated peer can issue read frames with no authorization check beyond "you passed the handshake".

// In every federation read handler:
let work = self.works.get(&work_id).ok_or(...)?;
let read_club = work.work.current_edition().read_club()
    .unwrap_or(self.system_clubs.public_club);

// Option A: Only replicate public content
if read_club != self.system_clubs.public_club {
    return Err(FederationError::NotAuthorized);
}

// Option B: Check against a "federation read club" the peer belongs to
if !peer_clubs.contains(&read_club) {
    return Err(FederationError::NotAuthorized);
}

6. Boundary 4: Write Access (Data Plane)

Provenance injection (CRITICAL)

SpanProvenance on SyncWorkEntry and CrdtWorkUpdate is imported verbatim with no signature verification. A peer can attach fabricated provenance — claiming a span originated from any author or server — to locally-stored content. Since provenance is the integrity spine of the system, this undermines the trustworthiness of all federated content.

LWW "current edition" hijack

ReconcileState.current uses last-writer-wins by (timestamp, server_id). The timestamp is clamped to now + 3600s, but a peer that sets a near-future timestamp wins the "current" pointer for any work, effectively censoring other editions from the default view.

// Before importing span_provenance from a peer:
for sp in &update.span_provenance {
    let element_fingerprints = collect_fingerprints(&edition, sp.start, sp.end);
    if !verify_span_provenance(&sp.provenance, &element_fingerprints) {
        tracing::warn!("peer {} sent invalid provenance, rejecting", peer_server_id);
        continue; // skip this span's provenance
    }
    // Optionally: verify that provenance.author_public_key corresponds
    // to the origin server's known signing key
}

7. Boundary 5: Membership (Web-of-Trust Join)

The mechanism

MembershipState is an OR-set CRDT. Join requires ≥ min_endorsements valid endorsements from existing members. The default min_endorsements = 2.

Risks

8. Boundary 6: Governance (PBFT Consensus)

The mechanism

Lightweight PBFT: Proposal → Prepare → Commit → Sealed. Transactions: Admit, Expel, KeyRegister, RoyaltyRecord.

Risks

9. Boundary 7: Identity Binding

The problem

The authenticated principal is the Ed25519 verifying key (from the handshake), but authorization decisions throughout the frame handlers key off the self-declared server_id string from the Hello frame. There is no binding between the two.

Consequences

• A peer can claim any server_id — including one belonging to another server
• Imported works/blobs attribute origin_server_id from the push payload (attacker-controlled)
• MembershipLeave trusts the self-declared server_id to evict
• CrdtSyncPush/Pull "authorization" only checks the frame's server_id matches the declared hello ID — both are unverified

10. Single-Server vs Federation: The Access Model Gap

The single-server model has a coherent, layered access control system. The federation data plane bypasses every layer:

The end-user path enforces 6 layers of access control. The federation path enforces 1 (the handshake) and skips the rest.

11. The Gap Register (Prioritized)

12. Recommendations: Aligning Federation with the Club Model

The goal is to make federation access control at least as restrictive as end-user access control. Here's the roadmap:

Phase 1: Stop the Bleeding (quick fixes, 1-2 days)

Phase 2: Enforce Club Access Control (1-2 weeks)

struct FederationAuthorization {
    peer_server_id: String,
    peer_verifying_key: [u8; 32],
    resolved_clubs: HashSet<BeId>,  // clubs this peer belongs to
}

impl FederationAuthorization {
    fn can_read(&self, work: &WorkState, server: &Server) -> bool {
        let read_club = work.read_club()
            .unwrap_or(server.system_clubs.public_club);
        read_club == server.system_clubs.public_club
            || self.resolved_clubs.contains(&read_club)
    }

    fn can_edit(&self, work: &WorkState, server: &Server) -> bool {
        let edit_club = work.edit_club()
            .unwrap_or(server.system_clubs.empty_club);
        self.resolved_clubs.contains(&edit_club)
    }
}

Phase 3: Fix Identity and Governance (2-4 weeks)

Phase 4: Hardening (ongoing)

13. Safe Deployment Patterns (Until Gaps Are Fixed)

Until the gaps in Phase 1 and 2 are fixed, federation should be deployed with these constraints: