Control Plane

Status of This Appendix

This appendix is informative (non-normative).

It describes a recommended control-plane architecture for provisioning and authorizing PALISADE tunnel sessions, but it does not define mandatory protocol behavior. Implementations MAY use alternative provisioning mechanisms provided they satisfy the security properties described in the PALISADE core specification.

1. Motivation and Threat Model Context

PALISADE establishes post-quantum-secure tunnels over an unreliable transport (e.g., UDP). However, in many deployments, tunnel establishment is gated by a control plane that:

• authenticates users or devices,
• enforces policy (subscriptions, quotas, device limits),
• allocates tunnel parameters (e.g., IP addresses, server selection).

If control-plane authorization is weak or replayable, an attacker may be able to create unauthorized tunnel sessions even if the tunnel cryptography itself is secure.

This appendix describes a control-plane design that:

• avoids reusable bearer credentials,
• uses post-quantum proof-of-possession authentication,
• cryptographically binds control-plane authorization to the tunnel handshake.

2. Provisioning Models

PALISADE assumes one of the following provisioning models.

2.1 Static or Out-of-Band Provisioning

In static provisioning, all parameters required to initiate a tunnel (e.g., server address, identity keys, authorization material) are configured out of band.

Examples include:

• pre-installed device configurations,
• manual key distribution,
• embedded credentials.

This model requires no online control plane and is fully compatible with the PALISADE core protocol.

2.2 Control-Plane Provisioning (Recommended)

In dynamic environments, a control plane is used to authorize tunnel creation and allocate resources. In this model, the control plane issues a short-lived session authorization artifact ("SessionGrant") that is later presented during the PALISADE handshake.

3. Device Enrollment and Identity

In control-plane provisioning, clients are identified by a long-term post-quantum identity key pair, typically the same key used for PALISADE client authentication.

A common pattern is:

1. A one-time enrollment step authenticates the account using a recovery or enrollment secret.
2. The client registers a device identity public key (e.g., Dilithium-3).
3. The control plane binds this public key to an account and device identifier.

After enrollment, routine control-plane operations SHOULD authenticate the client using proof-of-possession of the device private key, rather than reusable bearer tokens.

4. Proof-of-Possession Control-Plane Authentication

To avoid replayable credentials, control-plane API requests can be authenticated using digital signatures:

• Each request is signed using the device's post-quantum private key.
• The signature covers a canonical representation of the request (method, path, body hash, nonce, etc.).
• The server verifies the signature using the enrolled device public key.

This approach ensures that:

• Recorded transport-layer traffic does not yield reusable credentials.
• Authentication remains secure against future cryptanalytic advances.

5. SessionGrant Structure and Semantics

A SessionGrant is a short-lived authorization artifact issued by the control plane to permit tunnel establishment.

A typical SessionGrant contains:

• session_id: Identifier for the authorized tunnel session.
• device_id: Identifier for the enrolled device.
• expires_at: Absolute expiration time.
• grant_nonce: Random value to ensure uniqueness.
• grant_mac: Message authentication code computed by the server.

The SessionGrant is:

• bound to a specific device identity,
• valid for a short duration (e.g., seconds to minutes),
• intended for single use.

6. Use of SessionGrant in PALISADE Handshake

When control-plane provisioning is used, the client includes the SessionGrant in the initial PALISADE handshake (e.g., as part of ClientHello or an extension).

Upon receipt, the server:

1. Verifies the SessionGrant MAC and expiration.
2. Confirms that the referenced session and device are valid.
3. Ensures that the client authentication key presented in the handshake matches the enrolled device key bound to the SessionGrant.

Only after these checks succeed does the server proceed with the cryptographic handshake.

Implementations SHOULD perform SessionGrant verification before committing significant computational resources.

After the handshake completes, the session is identified by a Routing Identifier (RID), a 24-byte structured field derived from the handshake key schedule. The RID replaces the 5-tuple (source IP:port, destination IP:port, protocol) as the session identifier, enabling stable session identification independent of source IP:port. This design supports NAT rebinding tolerance and multi-server deployments, as sessions can be identified by RID even when the client's source address changes. The RID is not provisioned by the control plane; it is cryptographically derived during the handshake from the established key material.

7. Control-Plane Threat Model (Informative)

7.1 Scope and Purpose

This appendix describes the threat model for the control plane used to provision and authorize PALISADE tunnel sessions. The control plane is responsible for authenticating clients, authorizing session creation, and issuing short-lived session grants that are cryptographically bound to subsequent PALISADE tunnel establishment.

The control plane does not carry user traffic and does not participate directly in data-plane confidentiality or integrity. Its purpose is to ensure that only authorized and authenticated clients can initiate PALISADE tunnels.

This appendix is informative and non-normative. It describes one secure control-plane architecture as implemented by SeraphVPN and does not define requirements for PALISADE implementations.

7.2 Adversary Model

The control-plane threat model assumes adversaries with the following capabilities:

• Passive observation of control-plane network traffic
• Active network attacks, including message injection, replay, and modification
• Compromise of control-plane databases or storage systems
• Exfiltration of API credentials or account identifiers
• Long-term recording of control-plane communications for future cryptanalysis
• Access to large-scale quantum computing capabilities in the future

The adversary is not assumed to be able to break the underlying post-quantum cryptographic primitives used for authentication or key establishment.

7.3 Security Objectives

The control plane is designed to achieve the following security objectives:

1. Authorization Safety
   Possession of control-plane credentials alone MUST NOT be sufficient to establish a PALISADE tunnel.
2. Proof-of-Possession Binding
   Tunnel establishment MUST require cryptographic proof of possession of the client's post-quantum identity key.
3. Replay Resistance
   Control-plane authorization material MUST be replay-safe and short-lived.
4. Separation of Concerns
   Compromise of the control plane MUST NOT enable decryption of data-plane traffic or impersonation of a client without additional cryptographic material.
5. Post-Quantum Resilience
   Control-plane authentication and authorization MUST remain secure against adversaries with future quantum capabilities.

7.4 Threat Analysis and Mitigations

7.5 Post-Quantum Properties

Control-plane authorization relies on post-quantum proof-of-possession, typically implemented using Dilithium-based signatures. Authorization material issued by the control plane is cryptographically bound to:

• the client's post-quantum identity key, and
• the subsequent PALISADE handshake transcript.

As a result, possession of recorded control-plane messages or stored authorization artifacts does not enable future tunnel establishment, even under a quantum adversary.

7.6 Relationship to Data-Plane Threat Model

The control-plane threat model is complementary to, but independent from, the PALISADE data-plane threat model. Failure of the control plane may affect availability or authorization, but MUST NOT compromise the confidentiality or integrity of established PALISADE tunnels.

8. Explicit Non-Goals

The following are explicit non-goals of the control-plane design:

• Providing a general identity or authentication framework
• Acting as a public-key infrastructure (PKI)
• Guaranteeing anonymity at the control-plane layer
• Preventing denial-of-service attacks against the control plane
• Protecting against compromise of endpoint devices
• Replacing transport-layer security for general web services

The control plane is intentionally scoped to session authorization and provisioning and relies on PALISADE for data-plane security guarantees.

9. Security Properties Achieved

This provisioning model provides:

• resistance to replay attacks against the control plane,
• cryptographic binding between control-plane authorization and tunnel authentication,
• isolation between tunnel security and management-plane transport security,
• compatibility with post-quantum threat models.

10. Rationale for Informative Status

This appendix is informative rather than normative because:

• PALISADE does not mandate a specific management or API protocol.
• Multiple secure provisioning mechanisms are possible.
• The core tunnel security properties do not depend on a single provisioning design.

However, implementations that adopt control-plane provisioning SHOULD satisfy the properties described here to avoid weakening overall system security.

11. Summary

The control-plane architecture described in this appendix is designed to minimize trust assumptions, eliminate long-lived reusable credentials for tunnel establishment, and remain secure under future quantum adversaries. By cryptographically binding authorization to post-quantum proof-of-possession during PALISADE tunnel establishment, the system reduces the impact of credential compromise and control-plane attacks. PALISADE secures the tunnel itself. This appendix describes one recommended way to ensure that only authorized clients can initiate those tunnels, without introducing replayable or long-lived credentials.

By separating tunnel cryptography from provisioning while still cryptographically binding them at session establishment, implementations can achieve a clean and future-proof security architecture.