Trust is earned at every boundary.

Mercurius treats every network and Portal as untrusted. The Workstation proves its identity, authenticates the user, and authorises each action within the attached Session.

Mercurius Authentication and Authorisation Model

Mercurius is a zero-trust network-native Window System. A network connection establishes communication, not authority. A Portal gains no privilege from being on the same LAN as a Workstation, from running on the Workstation itself, or from knowing the identifiers of Sessions, Windows, Seats, or other resources.

mwsd is an Internet-facing daemon which starts with root privilege. Its security model must therefore be understandable without relying on favourable network placement or cooperative peers. Trust is established through three separate decisions. Each gate answers a different question, protects a different party, and must succeed independently. Authentication establishes identity; authorisation determines what that identity may do.

In this document, the Workstation is the host running the MWS Server (mwsd), while a Portal is the user-facing endpoint which displays Windows and returns input. An Association is one protected connection between them. A Session is the server-resident graphical environment belonging to an authenticated user.

1. The Three Security Gates

When a user runs:

mwsc per@xavier.tebibyte.org mlogo

Mercurius applies these gates in order:

1. The Portal authenticates the Workstation: “Is this really xavier.tebibyte.org?”
2. The Workstation authenticates the user: “Is this really user per?”
3. The Workstation authorises the action: “May per run mlogo, and may this Association act upon the requested Session resources?”

Passing one gate does not imply passing either of the others. An authenticated Workstation has not authenticated the user. An authenticated user is not automatically entitled to perform every action. A Portal device is never the source of user authority.

2. Security Design Principles

Two requirements govern how Mercurius implements and reviews the three gates:

1. The Handshake must be cheap and fail fast. This limits the resources an unauthenticated peer can consume during a denial-of-service attack.
2. The Session must remain secure after authentication. This limits what a persistent attacker with valid credentials or control of an Application can reach.

The first principle applies while the peer is unauthenticated. The Server assumes that peers may be numerous, malformed, silent, slow, or deliberately wasteful. It therefore creates only bounded, disposable Association and Handshake state; rejects invalid Messages early; applies an absolute authentication deadline; and retires a failed peer without disturbing any other Association. Expensive persistent Session state is created only after authentication succeeds.

The second principle applies after authentication. The Server assumes that an attacker may possess valid credentials, control an Application, or remain connected for a long time. Successful authentication therefore does not relax Session isolation or Message validation. Identity remains stable, authority remains scoped to the attached Session, and every operation still passes Gate 3.

These are separate threats requiring separate structures. Handshake is transient, cheap, and disposable. Session is long-lived, stateful, and protected by explicit ownership and narrow authority. For an administrator, this means that neither a busy public listener nor a successful login is treated as permission to trust subsequent input.

3. Gate 1: Portal Authenticates Workstation

The Portal establishes the identity of the named Workstation before it sends user credentials or accepts any MWS Session state.

For an SCTP connection, the Portal:

1. validates the Workstation name through DNSSEC;
2. obtains the applicable DANE TLSA records;
3. establishes DTLS 1.3 over the SCTP Association;
4. verifies the Workstation certificate against the TLSA policy;
5. requires the mws ALPN identifier; and
6. fails closed if any step fails.

DANE uses a DNSSEC-protected TLSA record to bind the Workstation name entered by the user to the certificate or public key presented by that Workstation. DTLS then provides confidentiality and integrity for every MWS Message on every SCTP stream. The DTLS-over-SCTP profile also applies its required SCTP-AUTH protection; SCTP-AUTH alone is not a substitute for DTLS because it does not encrypt MWS Messages.

There is no cleartext fallback. An external VPN or encrypted tunnel may add defence in depth, but it does not replace Workstation authentication or the MWS DTLS profile. A deployment using conventional public-key infrastructure in place of DANE must still authenticate the named Workstation before proceeding. An unavailable or invalid DNSSEC answer, a missing applicable TLSA record, a certificate mismatch, or failure to negotiate the MWS DTLS profile ends the connection before user credentials are sent.

A deployment may additionally authenticate managed Portal devices with mutual DTLS. Device identity can inform local policy, but possession of an approved device does not authenticate its user and cannot grant access to a Session by itself.

Local and network Portals follow the same security model. A local Transport may optimise how Messages are carried, but it does not bypass certificate validation, user authentication, or Session isolation.

4. Gate 2: Workstation Authenticates User

After the secure Association exists, the MWS application-layer handshake authenticates the user. The Server advertises the authentication mechanisms it supports in MWS_AUTH_CHALLENGE, together with a fresh per-Association nonce. The Portal selects one advertised mechanism and replies with MWS_AUTH_RESPONSE. It may not invent a mechanism or skip the exchange.

Mercurius defines a mechanism-independent outer handshake. The mechanism determines how the user proves identity:

• PAM authenticates through the Workstation’s normal account policy. The password is carried only inside the authenticated and encrypted DTLS Association.
• SSHKEY proves possession of a private key whose public key is authorised for the requested account. The private key is never sent. The signature is bound to the current Association with the DTLS exporter, so a response captured on one Association cannot authenticate another.
• Other registered mechanisms may provide hardware-token, federated, or multi-step authentication without changing the outer MWS handshake.

Malformed credentials, an unadvertised mechanism, an invalid proof, an expired deadline, or an ordinary policy rejection all fail authentication. The Server does not create the bootstrap Session until authentication has succeeded.

The accepted account becomes an immutable, Server-created Identity. It is not derived from a Portal-supplied numeric user ID, and it is not transient text retained only by the Handshake. The Identity supplies the local account, UID, GID, and supplementary groups under which the Session’s Applications run.

5. Gate 3: Workstation Authorises the Action

Authentication answers who the user is. It does not grant unrestricted access to the Workstation.

For an application launch, the Session’s privileged mwsdm host establishes the authenticated account’s UID, GID, supplementary groups, environment, and PAM session before executing the requested program. Normal operating-system policy then makes the final decision: filesystem permissions, executable permissions, ACLs, account policy, and other host controls apply exactly as they do to a local process. Running mwsd and mwsdm with root privilege does not cause the launched Application to inherit that privilege.

Gate 3 continues after launch. Every Portal-originated Message is authorised against the Association and Session in which it was received. In particular:

• the receiving Association supplies the authoritative Session context;
• a Portal cannot select another Session by supplying its session_id;
• Window and Seat identifiers are meaningful only within their owning Session;
• input may target only a Window belonging to the attached Session;
• rendering, audio, clipboard, and other resources remain within their defined Session and policy boundaries;
• a detached Session may be resumed only when the Server has offered it to the newly authenticated user; and
• knowing or guessing an identifier never grants access to the referenced resource.

The Server rejects unauthorised or out-of-scope requests without revealing whether another user’s resource exists. A policy rejection is reported as MWS_ERROR_POLICY; an invalid Session-scoped reference is reported as MWS_ERROR_SESSION, with identifying details suppressed where they would disclose cross-Session state.

6. The Privileged Daemon Boundary

mwsd starts with root privilege and supervises the privileged mwsdm Session host. Together they establish login Sessions, adopt authenticated identities, initialise supplementary groups, and provide access to the Workstation resources managed by the Window System. Root is an implementation capability used to establish the requested security context; it is not authority delegated to a Portal or Application.

Before authentication, the daemon treats every byte as hostile. The initial MWS_QUERY is deliberately empty, authentication has an absolute deadline, and malformed or unexpected Messages are rejected before Session resources are created. No unauthenticated request may select a UID, launch a process, address a Session, or obtain a Window-system resource.

After authentication, process launch crosses an explicit privilege boundary. The child receives the authenticated user’s UID, GID, supplementary groups, PAM credentials, and login environment. It does not retain the daemon’s root identity. Failure to establish every required part of that context prevents the launch.

The daemon itself remains privileged and must continue to distrust the authenticated Portal. It validates Message framing, protocol state, stream assignment, object ownership, and Session scope on every request. Successful login removes the unauthenticated boundary; it does not remove the authorisation boundary.

7. Session Authority and Reconnection

Authority belongs to the authenticated user’s relationship with a Session, not to a socket, Portal hostname, or remembered numeric identifier. The Controller binds an authenticated Association to the authorised Session, while the Session retains its immutable Identity independently of that particular connection.

After an unexpected disconnection, a replacement Portal must establish a new secure Association and authenticate again. The Server may rebind it during the Session’s grace period only after proving the same Identity and satisfying Session policy. Explicitly detached Sessions follow the same principle: the user authenticates first, and the Server offers only Sessions that user is authorised to resume.

Detachment and resumption therefore preserve Session state without turning a Session identifier or resume selector into a bearer credential.

8. Trust Boundary

The network and every Portal are untrusted. A Portal may be mobile, lost, stolen, compromised, or connected through a hostile network. Network topology does not change the Server’s decisions.

An active Portal necessarily displays the user’s content and observes the user’s input. It may also hold reusable authentication material. A compromised active Portal can therefore compromise the user operating it. The security boundary requires that such a compromise cannot grant authority over another user’s Session, expose unrelated Server resources, or make Portal-supplied state authoritative.

Session isolation is consequently an authorisation property, not merely an object-storage convention. A Portal cannot observe, enumerate, infer, or manipulate another Session’s Windows, input, rendering state, clipboard, audio, or other resources.

9. Administrator Responsibilities

A secure installation requires the administrator to maintain all three gates:

• the Workstation’s DNS name must be protected by DNSSEC and its TLSA records must match the deployed certificate or public key;
• certificate private keys and other Server credentials must be readable only by the accounts which require them;
• the MWS service must run with enforcing security policy and must never offer the development-only TRUST mechanism;
• the PAM service policy must express the site’s account and login rules;
• SSHKEY access must use each account’s maintained authorized_keys policy;
• local accounts, groups, filesystem permissions, ACLs, and executable permissions must express what authenticated users may do; and
• security-relevant logs must be retained and monitored according to local operational policy.

A firewall, private address, VPN, or physically local Portal does not satisfy any of these responsibilities by itself. Those controls may reduce exposure, but they do not replace cryptographic Workstation identity, user authentication, or per-request authorisation.

10. Failure and Audit Behaviour

All three gates fail closed:

• failure to authenticate the Workstation ends Transport establishment;
• failure to authenticate the user prevents Session creation; and
• failure to authorise an action rejects that action without widening the caller’s authority.

Malformed handshake Messages and invalid state transitions are protocol errors. Authentication deadlines cannot be extended indefinitely by activity from an unauthenticated peer. A fatal failure closes the Association after the Server has attempted to report it; failure cleanup must not affect unrelated Associations or Sessions.

Security-relevant connection, authentication, identity, Session, execution, rejection, and teardown events are logged with enough context for operational audit and abuse detection. Credentials, passwords, private keys, authentication payloads, clipboard contents, and other user data are never logged.

The implementation’s permissive TRUST mechanism is a development facility. It is advertised only when permissive security policy has been explicitly selected and is not a valid configuration for an exposed Server. Production operation requires all three gates.