11. Rekeying and Epoch Transitions (Normative)

PALISADE uses epoch-based rekeying to provide forward secrecy, limit AEAD nonce usage, and support long-lived sessions.

Rekeying results in the creation of a new epoch with fresh traffic keys while preserving session continuity.

11.1 Rekey Triggers

A rekey operation MUST be initiated when any of the following conditions are met:

Sequence exhaustion

The sender's sequence counter for the current epoch reaches or exceeds 2^40 − 2^30.

Explicit rekey request

Receipt of a valid CTRL_REKEY control frame.

Policy-based triggers

Time-based or data-volume-based thresholds configured by local policy.

Rekeying MAY be initiated earlier than required but MUST NOT be delayed beyond the sequence exhaustion threshold.

11.2 Rekey Authority

The server is authoritative for rekeying decisions.

The server initiates rekeying by transmitting a CTRL_REKEY control frame.

Clients MUST NOT unilaterally increment epoch identifiers.

Upon successful authentication of CTRL_REKEY, both endpoints MUST update their receive epoch processing state such that packets in epoch N+1 are accepted according to the overlap rules. This includes updating both encryption and decryption epoch state.

Implementation Note: Implementations MUST NOT update encryptor epoch without also updating decryptor epoch acceptance. One-sided epoch commits cause desync.

11.3 Epoch Key Derivation

Let epoch_n_secret denote the secret associated with epoch n.

The secret for epoch n+1 is derived as:

epoch_{n+1}_secret =
    HKDF-Expand(epoch_n_secret, label("epoch step"), 32)

From epoch_{n+1}_secret, new traffic keys and IVs are derived according to the key schedule defined in Section 6.

Key derivation for epoch n+1 MUST be completed before any packet is transmitted using the new epoch.

11.4 Epoch Transition Rules

When transitioning from epoch n to epoch n+1:

The sender MUST:

• Increment epoch_id by exactly 1.
• Reset the sequence counter to 0.
• Transmit all subsequent packets using epoch n+1 keys only.

The receiver MUST:

• Accept packets from epoch n+1 immediately.
• Accept packets from epoch n only during the negotiated overlap window (Section 11.5).

Epoch increments and sequence resets MUST be treated as an atomic transition. Packets MUST NOT be transmitted or accepted with mixed epoch/sequence state.

11.5 Epoch Overlap Window

To tolerate packet reordering during rekeying, endpoints MAY temporarily accept packets from both the old and new epochs.

During overlap, receivers MUST attempt decryption using keys for all permitted epochs {current, current-1 if overlap active, current+1 if armed} without changing global epoch state. Epoch installation MUST occur only at the authenticated commit point.

Permitted Epochs

• current: Always permitted
• current-1: Permitted only during overlap window for backward compatibility
• current+1: Permitted only after receiver has armed the next epoch (e.g., after CTRL_REKEY)

Principle: Try broadly; commit narrowly. Attempting decryption with multiple keys is safe. Committing epoch state changes must be tightly gated.

Rules

• The overlap window duration and out-of-order limits are negotiated during the handshake.
• During overlap:
  • Packets from epoch n and n+1 MAY be accepted.
  • Packets from epochs earlier than n MUST be rejected.
• After the overlap window expires:
  • Packets from epoch n MUST be rejected.
  • All secrets and keys associated with epoch n MUST be securely erased.
• Epoch overlap MUST NOT extend the allowable number of packets encrypted under a single epoch's traffic keys.

11.6 Replay Protection During Rekeying

Replay protection remains fully enforced during epoch transitions.

• Sequence numbers MUST be validated independently per epoch.
• Packets outside the negotiated out-of-order window MUST be rejected.
• Packets with duplicate (epoch_id, seq) values MUST be rejected.
• Epoch overlap does not relax replay protection guarantees.

11.7 Key Erasure Requirements

Implementations MUST securely erase key material as follows:

epoch_n_secret MUST be erased immediately after:

• The overlap window expires, or
• It is no longer required for decryption.

Traffic keys and IVs associated with epoch n MUST be erased at the same time.

Failure to erase obsolete keys constitutes a violation of forward secrecy requirements.

11.8 Epoch Exhaustion

If epoch_id reaches 2^32 − 1:

• The session MUST be terminated.
• A full handshake MUST be performed to establish a new session.
• Epoch identifiers MUST NOT wrap or be reused.

11.9 Security Properties

The rekeying mechanism ensures:

• Forward secrecy across epochs
• Bounded AEAD nonce usage
• Replay resistance during and after transitions
• Continuity of service during rekeying

Rekeying is an internal session mechanism and does not alter authentication state.

11.10 Epoch Sovereignty

Epoch transitions MUST occur only via explicit, ordered protocol steps under non-early traffic keys. A receiver MUST NOT advance epoch state based solely on observing epoch_id in a packet header.

Correct Behavior:

• Advance epoch after successfully authenticating CTRL_REKEY

Incorrect Behavior:

• Advance epoch because packet header contained epoch_id > current_epoch

Security Rationale: Observing a higher epoch_id in a header does not authenticate that the peer has transitioned. Premature epoch advancement creates desync vulnerabilities exploitable by on-path attackers.

11.11 Epoch State Machine

Each session maintains an epoch state machine with two states:

Normative Requirement: Implementations MUST NOT remain in TRANSITION indefinitely. A maximum transition duration MUST be enforced.