Skip to content

SPEC Remote Logging TLS Requirements

Jump to bottom
Steve Grubb edited this page May 13, 2026 · 2 revisions

Linux Audit TLS Transport Requirements

This document defines the first TLS transport phase for audit remote logging. It covers only the mechanics needed to bring up TLS between an audit event sender and an audit collector. It intentionally excludes protocol-level sequence numbers, replay windows, signed acknowledgements, durable queue semantics, and test-suite design. Those are later phases.

The near-term TLS goal is pre-shared key TLS. Full X.509 mutual TLS remains the long-term target, but it requires CA operations, certificate issuance, revocation, renewal, identity mapping, and more administrator infrastructure than many deployments can reasonably stand up as the first step.

Terminology:

  • Sender: the host forwarding audit events, typically audisp-remote.
  • Collector: the central host receiving remote audit events, typically the auditd listener.
  • PSK: a high-entropy pre-shared secret used by TLS to authenticate the sender and collector.
  • PSK identity: the non-secret name sent during the TLS handshake so the collector can select the correct PSK and authorization record.
  • X.509 mTLS: certificate-based mutual TLS. This is the future target, not the first TLS on-ramp.

Source Requirements

Previous plans identified these areas of needed improvements:

  • Implement TLS 1.3 with mutual authentication.
  • Make cleartext TCP a legacy mode with loud documentation and ideally a build-time or runtime hardening option to disable it.
  • Bind collector identity to configured host identity, certificate SAN, and expected deployment role.
  • Add protocol-level sequence numbers, replay windows, and collector-signed or MACed acknowledgements even inside TLS.
  • Reject unauthenticated events before they reach local logs or plugins.

Those requirements are directionally correct, but they assume an X.509-first deployment model. That is a good future state, but it is not the most practical first step. The near-term target should be TLS with per-sender PSKs. PSK TLS still provides encrypted and authenticated transport, avoids cleartext remote logging, and gives operators a smaller enrollment problem.

The original list is also underspecified. It does not define the PSK security model, OpenSSL version strategy, FIPS behavior, PQC behavior, secret rotation, failure semantics, configuration surface, or enrollment workflow.

The initial plans had several useful constraints:

  • T_TLS already exists in auditd and audisp-remote config enums, but TLS is not exposed in the parser tables and is not implemented in transport code.
  • Exposed transports are TCP and, when built, Kerberos. Cleartext TCP remains a supported legacy transport.
  • Secure remote logging needs modern validation and clear operational identity.
  • TLS provisioning and rotation must be operable.
  • Blocking handshakes must not delay auditd, local logging, or remote sender progress.
  • Kerberos must remain available for existing deployments.

For this phase, the protocol-level sequence, replay, acknowledgement, gap, and hash-chain items are acknowledged but out of scope.

Non-Goals

  • No change to the audit event framing protocol beyond running it over TLS.
  • No application-level sequence numbers, replay windows, or signed/MACed acknowledgements in this phase.
  • No redesign of audisp-remote durability or batching in this phase.
  • No test-suite specification here, although the implementation should be written in a way that can be tested later.
  • No removal of Kerberos transport.
  • No requirement to deploy an audit CA or X.509 mutual TLS in the first phase.

Core TLS Requirements

TLS transport must be explicit. transport = tls should be accepted by both the collector listener configuration and the sender remote configuration only when audit was built with TLS support. If a configuration requests TLS on a build without TLS support, startup must fail or the plugin startup failure policy must fire. It must not silently fall back to TCP.

The first TLS authentication mode should be PSK:

transport = tls
tls_auth = psk

PSK authentication must be mutual in practice: the sender proves possession of the configured PSK, and the collector proves possession of the same PSK by completing the TLS handshake. A mode that encrypts without authenticating both sides should not be accepted as secure remote logging.

TLS must gate event ingestion. The collector must complete the TLS handshake, map the PSK identity to an enabled sender authorization record, and verify the selected crypto profile before any remote audit record is read into normal protocol handling, written to local logs, or delivered to plugins.

Cleartext TCP must become an explicit legacy mode. Existing deployments may need it for compatibility, but hardened builds or hardened runtime profiles should have a way to refuse cleartext remote logging. TLS configuration errors must not trigger automatic downgrade to TCP.

TLS handshakes must not block the local audit path. The implementation can use nonblocking OpenSSL over the existing select/poll backend, a worker thread for handshake work, or another bounded design, but a slow or malicious remote peer must not stall local kernel event intake or local audit log writing.

TLS 1.3 0-RTT early data must be disabled. Audit records are not replay-safe, and TLS 1.3 early data has weaker replay properties than normal 1-RTT application data.

Ticket-based session resumption should be disabled for the first TLS transport phase. External PSK is the authentication mechanism; it should not be mixed with session tickets or 0-RTT until identity, revocation, and logging behavior are specified.

TLS compression, anonymous cipher suites, export cipher suites, static RSA key exchange, static DH, DSA-only paths, TLS renegotiation, SSLv2, SSLv3, TLS 1.0, and TLS 1.1 must be disabled.

PSK Security Model

PSK TLS has a different trust model than X.509 mTLS. It is useful precisely because it avoids standing up PKI, but the symmetric secret becomes the security boundary.

Requirements:

  • Each sender must have a unique PSK per collector or collector cluster. Fleet-wide PSKs are not acceptable.
  • PSKs must be generated from a cryptographically secure random generator. They must not be passwords, hostnames, hashes of predictable data, or derived from machine identifiers alone.
  • The default PSK length should be at least 32 random bytes. The PQC profile should require at least 32 random bytes and may recommend 48 or 64 bytes for margin.
  • The PSK identity is not secret. It should be stable, printable ASCII, free of control characters, and safe for logs and configuration files.
  • The collector must maintain an authorization record for each PSK identity. Possession of a CA or a network address is not relevant in the PSK model.
  • A sender identity must map to exactly one deployment role: audit event sender. Collector and sender credentials must not be interchangeable.
  • PSK files and PSK stores must be readable only by the audit daemon/plugin runtime identity and root. They must not be group/world-readable or group/world-writable.
  • The collector needs access to the recoverable PSK secret for each enabled sender. A one-way hash is useful for inventory, but it is not enough for TLS handshake operation.
  • If a PSK is disclosed, an attacker can impersonate the sender to the collector and can impersonate the collector to that sender. Rotation must be operationally simple.

Threat model:

  • A network attacker without the PSK cannot read audit events or inject valid TLS-protected audit records.
  • A network attacker with a sender's PSK can impersonate that sender and the collector for that sender. This is why PSKs must be per-sender and per-collector, not shared.
  • A compromised collector PSK store is serious. It can expose all sender secrets known to that collector.
  • A compromised sender PSK exposes that sender's remote logging channel but should not expose other senders.
  • PSK identity enumeration should not provide useful feedback to attackers. Rejections should be rate-limited and logged without revealing whether the identity was known.
  • TLS protects the connection, but it does not solve application-level replay, gap, or durable acknowledgement semantics. Those remain later protocol work.

Key establishment:

  • Prefer PSK with ephemeral key exchange, not PSK-only key exchange.
  • For TLS 1.3, require psk_dhe_ke behavior so the handshake includes an ephemeral key share.
  • Use separate listeners or explicit operator policy when a deployment must support materially different crypto profiles. The collector listener's profile is authoritative for all clients that connect to that listener.

Lifecycle:

  • The collector should be ready for a dedicated key lifecycle utility that creates, rotates, expires, disables, and inventories sender PSKs. The first PQC transport work does not need to implement this utility.
  • The runtime format must still carry enough metadata for that utility: identity, status, creation time, expiration time, owner or inventory reference, and optional non-secret fingerprint.
  • The collector should support a current and next PSK for a sender identity, or two adjacent sender identities during rotation, once lifecycle tooling is added.
  • Rotation should be possible without stopping local audit logging.
  • Old PSKs must have a defined retirement time.
  • Emergency revocation must be a collector-side operation: disable the PSK identity and close any active connection for that identity when feasible.

X.509 Mutual TLS Future Goal

Full X.509 mTLS is still the desired end state for organizations that can run the necessary infrastructure. It provides cleaner certificate lifecycle, stronger binding to existing enterprise identity, better support for hardware keys, and more standard revocation and renewal workflows.

Future X.509 work should add:

  • Audit-specific CA or intermediate CA guidance.
  • Certificate SAN, EKU, and role validation.
  • Collector-side client authorization, not just CA trust.
  • Revocation and renewal mechanics through CRL, OCSP, or short-lived certificates.
  • Optional certificate or SPKI pinning for constrained deployments.
  • Migration support from PSK identities to certificate identities.

The PSK phase should not block this. The TLS transport abstraction should make authentication mode a policy choice:

tls_auth = psk      # first phase
tls_auth = x509     # future phase

Configuration Surface

The exact option names can change during implementation, but the feature needs this class of configuration on both sides.

Common options:

transport = tls
tls_auth = psk
tls_crypto_profile = standard | fips | pqc
tls_handshake_timeout = 10

PSK sender options:

remote_server = audit-collector.example.com
port = 60
transport = tls
tls_auth = psk
tls_crypto_profile = standard
tls_psk_identity = host-1234
tls_psk_file = /etc/audit/private/remote.psk
tls_server_name = audit-collector.example.com

PSK collector options:

tcp_listen_port = 60
transport = tls
tls_auth = psk
tls_crypto_profile = standard
tls_psk_store = /etc/audit/psk.d
tls_allowed_clients = /etc/audit/tls-psk-clients

Advanced override options are useful for distributions and controlled environments, but should not be required for normal deployments:

tls_ciphersuites = ...
tls_groups = ...
tls_psk_exchange_mode = psk_dhe_ke

Defaults should come from the selected crypto profile. Overrides should fail closed if the requested setting is unsupported or would weaken the selected profile below its floor.

All first-phase profiles require TLS 1.3. Older TLS protocol compatibility is not part of this PSK transport phase.

Path validation must be compatible with NixOS-style symlinked configuration. The TLS implementation should allow root-owned symlink chains when the final target is root-owned and not group/world-writable. PSK files must not be accepted from world-readable paths, group/world-writable paths, or untrusted store locations. A symlink policy should be explicit rather than relying on accidental stat() behavior.

Recommended PSK identity rules:

  • The PSK identity is the opaque identity value sent in the TLS 1.3 pre_shared_key extension.
  • It is not a secret and it is not required to be a URI.
  • The value should be stable, unique within the collector's authorization and PSK store scope, printable ASCII, bounded in length, and free of whitespace for the proposed whitespace-separated file formats.
  • Simple inventory-oriented values such as host-1234, web-prod-17, or inventory-8f7a3c are acceptable.
  • A deployment may use a namespaced value such as collector-prod:host-1234 if that helps operations, log review, or shared key-store management, but the namespace is a local convention rather than an IETF or NIAP requirement.

NIAP's useful concept here is that a PSK is associated with a specific reference identifier. For this PSK-only phase, the configured PSK identity is that reference identifier.

Recommended PSK file format:

identity = host-1234
secret = base64:<base64url-or-standard-base64-random-secret>
created = 2026-05-08T00:00:00Z
expires = 2026-08-06T00:00:00Z

The sender can use a simpler secret-only file if the identity remains in the main config, but the collector store should keep enough metadata for rotation, revocation and operator auditability. The PSK store may include non-authority inventory metadata about how a key was generated, but it must not authorize a weaker cryptographic mode than the listener's configured profile.

Recommended tls_allowed_clients format:

# identity                              status    notes
host-1234                              enabled   prod web host
host-5678                              disabled  retired

Lines beginning with # and blank lines are ignored. Non-comment records are whitespace-separated. The first field is the exact PSK identity sent in the TLS handshake. The second field is the authorization status; valid values are enabled and disabled, and only enabled identities may connect. Remaining fields are operator notes and must not contain PSK material.

Duplicate identities, unknown statuses, malformed lines, and unsafe identity strings should make the file fail validation. The file should be root-owned and must not be group/world-writable. Reload failures must leave the previous working authorization list active.

tls_allowed_clients is the authorization list, not the secret store. The collector must accept a PSK identity only when all of the following are true:

  • The identity is present in tls_allowed_clients.
  • The identity status is enabled.
  • The identity exists in tls_psk_store.
  • The PSK store record has a usable current secret.

tls_allowed_clients does not select cryptographic policy. The collector listener's tls_crypto_profile defines the required cryptographic profile for all clients on that listener. A client that cannot negotiate the listener's profile must fail closed. The sender's tls_crypto_profile is a local expectation and guardrail; it must never cause the collector to weaken its configured profile.

Crypto Profiles

The implementation needs three supported TLS 1.3 profile classes. They should be selected by profile, not by scattering raw cipher strings through normal documentation.

The profile names are:

  • standard: default robust TLS 1.3 PSK mode. This is the normal deployment mode when neither FIPS nor PQC behavior is requested.
  • fips: TLS 1.3 PSK constrained by the active FIPS-capable OpenSSL and system crypto policy.
  • pqc: TLS 1.3 PSK requiring post-quantum or hybrid key establishment.

All three profiles must fail closed:

  • If the requested OpenSSL APIs are unavailable, fail.
  • If the configured profile cannot produce an allowed TLS 1.3 context, fail.
  • If the peer negotiates below TLS 1.3, fail.
  • If the requested PSK mode cannot be combined with the profile's allowed cipher and group policy, fail.
  • Never downgrade from pqc to standard, from fips to standard, or from TLS to cleartext TCP without an explicit operator configuration change.

System crypto policy should be used as much as possible. Auditd should define the requested security intent, and OpenSSL plus the system crypto policy should constrain the final algorithm set. System crypto policy may make an auditd profile stricter or unavailable, but it must not silently lower the selected auditd profile. If the intersection of auditd's selected profile and system policy is empty, auditd must fail the TLS configuration and log the reason.

standard: Robust Classical TLS 1.3

Purpose: provide the default strong TLS 1.3 PSK transport for systems that are not explicitly asking for FIPS or PQC behavior.

Protocol and algorithms:

  • Require TLS 1.3.
  • Require external PSK with ephemeral key exchange.
  • Use strong TLS 1.3 AEAD ciphersuites allowed by OpenSSL and system crypto policy.
  • Prefer X25519 where allowed by system policy; otherwise use P-256 and P-384.
  • Do not require PQC groups.
  • Do not claim FIPS operation.

Recommended TLS 1.3 ciphersuites:

TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

PSK requirements:

  • At least 32 random bytes.
  • Unique per sender and collector.
  • Stable across key rotation unless the operator intentionally enrolls a replacement identity.

fips: FIPS Enabled Systems

Purpose: run within system or application FIPS policy without accidentally fetching non-approved algorithms.

FIPS profile behavior must be fail closed. If OpenSSL, the active provider, the system crypto policy, or the distribution FIPS mode cannot support the requested TLS 1.3 PSK configuration, audit must reject tls_crypto_profile = fips instead of weakening the profile.

Auditd should not try to implement a competing FIPS interpretation. It should request FIPS-capable OpenSSL behavior where the OpenSSL version supports it, defer algorithm approval to the active provider and system crypto policy, and fail closed when that policy rejects the resulting TLS context.

Protocol and algorithms:

  • Require TLS 1.3.
  • Require external PSK with ephemeral key exchange.
  • Use AES-GCM ciphersuites and SHA-256/SHA-384 as allowed by the active FIPS provider and system crypto policy.
  • Use NIST curves P-256 and P-384 unless system policy explicitly allows another group.
  • Do not use ChaCha20-Poly1305 unless the active validated module and system policy explicitly allow it.
  • Do not use X25519 unless the active validated module and system policy explicitly allow it.
  • Generate PSKs with a FIPS-approved random bit generator through the active FIPS-capable provider or system-approved tool.
  • Do not enable PQC in the FIPS profile merely because a PQC algorithm is a NIST standard or is implemented by a provider. FIPS compliance depends on the active validated module and its approved operating conditions.

PSK requirements:

  • At least 32 random bytes generated by an approved source.
  • Operational procedures should prevent FIPS-generated PSKs from being reused in non-FIPS deployments, but runtime authorization still comes from the listener profile and allowed-client identity.

pqc: Forward-Looking Post-Quantum Systems

Purpose: allow deployments to begin using post-quantum TLS key establishment where both peers and OpenSSL support it.

PQC profile behavior must be fail closed. If the runtime OpenSSL and system crypto policy cannot negotiate the configured PQC or hybrid TLS group, the connection must fail. It must not silently downgrade to classical ECDHE.

OpenSSL compatibility:

  • Require OpenSSL 3.5 or newer, or another explicitly supported OpenSSL build that exposes compatible TLS PQC groups.
  • Require TLS 1.3.
  • Require external PSK with ephemeral key exchange.

Key establishment:

  • Prefer hybrid key establishment first, with X25519MLKEM768 as the baseline when OpenSSL exposes it and system policy allows it.
  • ML-KEM-768 is the recommended default security/performance point.
  • ML-KEM-1024 can be available as a high-security option.
  • Pure classical fallback belongs in standard, not in pqc.

PSK requirements:

  • At least 32 random bytes. Consider 48 or 64 random bytes for deployments that want larger symmetric margin.
  • Unique per sender and collector.
  • Operational procedures should prevent PQC deployment PSKs from being reused in weaker deployments, but runtime authorization still comes from the listener profile and allowed-client identity.

FIPS interaction:

  • pqc and fips should be separate profiles until the project has a clear validation story for the specific OpenSSL module and deployment policy.

Profile Construction Guidance

Profiles should be implemented as data-driven policy tables plus capability checks. Avoid burying profile behavior in scattered if statements.

Each profile definition should declare:

  • TLS version, which is always TLS 1.3 for this phase.
  • Allowed authentication mode: initially psk.
  • Allowed PSK exchange mode: psk_dhe_ke.
  • Minimum PSK length.
  • TLS 1.3 ciphersuite list.
  • Group list.
  • OpenSSL feature gates.
  • Disallowed features.
  • Whether OpenSSL FIPS properties are required.
  • Whether PQC groups are required.
  • The error to report when the profile cannot be built.

Example shape:

profile standard:
  tls = 1.3
  auth = psk
  psk_min_bytes = 32
  ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
  groups = X25519:P-256:P-384 as allowed by system policy
  fail_if_no_ephemeral_psk = yes

profile fips:
  tls = 1.3
  auth = psk
  psk_min_bytes = 32
  require_fips_provider_or_system_fips = yes
  ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
  groups = P-256:P-384 as allowed by system policy
  fail_on_policy_rejection = yes

profile pqc:
  tls = 1.3
  auth = psk
  psk_min_bytes = 32
  require_pqc_group = yes
  ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
  groups = X25519MLKEM768
  fail_on_classical_group = yes

Implementation guidance:

  • Probe OpenSSL capabilities at configure time and again at runtime where provider configuration can change the result.
  • Build the SSL_CTX from the profile, then inspect the resulting context where OpenSSL exposes enough information.
  • Log a profile-specific reason when context creation fails.
  • Keep operator overrides behind profile floor checks.
  • Add a diagnostic mode later that prints available profiles and why a profile is unavailable on the current host.

OpenSSL Implementation Mechanics

Use configure-time feature probes rather than only version-number checks. Vendors backport APIs and security behavior, and OpenSSL 3.x provider behavior is capability-driven.

Useful capability gates:

  • TLS support available.
  • SSL_CTX_set_min_proto_version() available.
  • SSL_CTX_set_ciphersuites() available for TLS 1.3 ciphersuite control.
  • TLS 1.3 external PSK callbacks available.
  • Provider APIs and SSL_CTX_new_ex() available for OpenSSL 3.x FIPS handling.
  • TLS group-list APIs available for X25519, NIST curves, and PQC groups.

Context setup:

  • Create role-specific SSL_CTX objects for sender and collector.
  • Load the PSK secret from the configured file or store with explicit error handling.
  • Decode PSK material from a strict format such as base64: or hex:.
  • Enforce minimum PSK length before creating the TLS context.
  • Set TLS 1.3 as the only supported protocol version for this phase.
  • Configure TLS 1.3 ciphersuites according to the selected crypto profile.
  • Configure groups according to the selected crypto profile.
  • Disable compression, ticket-based resumption, and 0-RTT.
  • Use TLS 1.3 PSK session callbacks where available.
  • Zeroize temporary PSK buffers after use where practical.

PSK identity handling:

  • The sender must present exactly the configured tls_psk_identity.
  • The collector must look up the identity in the PSK store and allowed-client registry before accepting application records.
  • Identity strings must be length-limited and reject NUL bytes, control characters, path separators where file-backed stores use identity-derived paths, and log-hostile characters.
  • Unknown identities should fail the handshake and be rate-limited in logs.
  • The collector should avoid timing and logging behavior that makes identity enumeration easy.

Nonblocking operation:

  • SSL_accept(), SSL_connect(), SSL_read(), and SSL_write() must handle SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE.
  • Handshake state must have a bounded timeout.
  • A peer stuck in handshake must count against listener connection limits and should be closed on timeout.
  • The implementation must not let TLS handshake work run in the same blocking path as netlink intake or local log writing.

Reload and key updates:

  • On reload, build new PSK store state and a new SSL_CTX first. If both succeed, atomically swap them for new connections.
  • Existing connections may continue until idle timeout or reconnect, unless a PSK identity is disabled or an authorization change requires active disconnect.
  • PSK-store reload failures must leave the previous working context active and log a clear error.
  • A malformed new key, missing allowed-client entry, unsupported profile, or system crypto policy rejection must not discard the previous working keys.

Logging:

  • Record accepted TLS connections in the audit system with remote IP address, PSK identity, profile, TLS version, cipher, and group when available.
  • Record rejected TLS handshakes in the audit system with remote IP address, PSK identity when safely known, and a success or failure reason that is useful to operators but does not leak PSK material.
  • The logging model should adopt NIAP TLS package audit expectations where they fit this PSK-only design. In particular, TLS session establishment failure must be audit-recorded with a stable failure reason, and client-side establishment/termination records should identify the non-TOE endpoint when sender-side audit logging is implemented. Relevant NIAP references are Table 2 FCS_TLSS_EXT.1.10, Table 2 FCS_TLSC_EXT.1.11, and Table 2 FCS_TLSC_EXT.1.13.
  • For auditd, accepted collector-side TLS sessions must also be audit-recorded even where NIAP only requires failure auditing for the TLS server role. This is an audit transport, so operators need positive evidence that protected audit forwarding was established.
  • Connection audit records should include the peer network address, local role (collector or sender), claimed or established PSK identity, configured crypto profile, negotiated TLS version, negotiated ciphersuite, negotiated group when available, whether PSK authentication was used, whether establishment succeeded, and a stable failure reason when it failed.
  • These cryptographic connection establishment records are audit records, not syslog-only messages. Implementations may also emit diagnostic syslog messages, but syslog does not satisfy this requirement.
  • Never log PSKs, derived secrets, session secrets, or full key store dumps.

Client Setup Process

This is the operator flow for a host that will forward audit events to a central collector using the near-term PSK model.

  1. Install an audit build with TLS transport support.
  2. Receive an assigned PSK identity from the collector administrator or enrollment system.
  3. Generate or receive a high-entropy PSK using the site's approved secret distribution path. The preferred operational model is collector-generated PSK delivered through secure configuration management, but sender-generated PSK is also acceptable if the collector receives it through an approved secure channel.
  4. Install the PSK file with restrictive ownership and permissions:
/etc/audit/private/remote.psk
  1. Configure audisp-remote:
remote_server = audit-collector.example.com
port = 60
transport = tls
format = managed
tls_auth = psk
tls_crypto_profile = standard
tls_psk_identity = host-1234
tls_psk_file = /etc/audit/private/remote.psk
tls_server_name = audit-collector.example.com
  1. Restart or reload the remote plugin according to the existing audit service management model.
  2. Confirm that the sender reports a TLS connection and that the collector logs the expected PSK identity and crypto profile.

For FIPS systems, set tls_crypto_profile = fips only when the runtime OpenSSL and system policy can support the FIPS PSK profile. It must fail closed otherwise.

For PQC systems, set tls_crypto_profile = pqc only after both sender and collector support the selected OpenSSL PQC TLS group. The connection must fail if it cannot negotiate PQC or hybrid key establishment.

Collector Enrollment Process

This is the central aggregator's perspective for the near-term PSK model.

Initial collector preparation:

  1. Choose the default crypto profile for the collector or collector cluster.
  2. Create the PSK store directory with restrictive ownership and permissions.
  3. Configure the auditd listener for TLS:
tcp_listen_port = 60
transport = tls
tls_auth = psk
tls_crypto_profile = standard
tls_psk_store = /etc/audit/psk.d
tls_allowed_clients = /etc/audit/tls-psk-clients
  1. Open firewall policy only from expected sender networks where possible.
  2. Define the PSK identity naming scheme before enrolling hosts.

Client enrollment:

  1. Validate the host against inventory, change control, or another out-of-band authority.
  2. Allocate a PSK identity for the sender. Example:
host-1234
  1. Generate at least 32 random bytes using a cryptographically secure random source. For FIPS deployments, use an approved generator under the active FIPS policy.
  2. Store the PSK in the collector PSK store with metadata: identity, status, creation time, expiration time, owner, and optional non-secret fingerprint for inventory.
  3. Add the PSK identity to tls_allowed_clients.
  4. Deliver the PSK identity, secret, collector hostname, port, and selected profile to the sender administrator or configuration system through an approved secure channel.
  5. Reload collector TLS authorization state transactionally. If the new PSK store or allowed-client file is invalid, the old working state must remain active.
  6. On first connection, verify that the collector logs the expected PSK identity, remote IP address, TLS profile, TLS version, cipher, group, and success result.

Renewal and revocation:

  • A dedicated lifecycle utility should manage PSK creation, rotation, expiration, disabling, inventory metadata, and safe updates to tls_psk_store and tls_allowed_clients.
  • The first PQC transport work only needs to consume the runtime files and be ready for this utility's model; it does not need to implement the utility.
  • Prefer short-lived PSKs with automated rotation once lifecycle tooling is available.
  • Allow overlap between old and new PSKs during planned rotation, either with a current/next key record or with adjacent identities.
  • If a host is retired or compromised, disable the PSK identity and close any active connection for that identity when feasible.
  • Authorization removal should block new connections immediately after reload.
  • Collector backup and restore procedures must treat the PSK store as highly sensitive material.

Additional Requirements To Levy

The original assessment should be extended with these TLS-only requirements:

  • Add transport = tls parser support in both auditd and audisp-remote.
  • Add tls_auth = psk as the first supported TLS authentication mode.
  • Add a TLS transport abstraction shared enough to avoid separate policy drift between sender and collector.
  • Add a configure option for TLS support and clear failure when TLS is requested on a non-TLS build.
  • Add TLS 1.3-only crypto profiles for standard, fips, and pqc, with standard as the default.
  • Make all profiles fail closed when unsupported.
  • Use OpenSSL and system crypto policy as the source of algorithm constraints where possible, but never let system policy silently downgrade the selected auditd profile.
  • Add PSK identity authorization, not just possession of a shared secret.
  • Require per-sender, per-collector high-entropy PSKs.
  • Define PSK store and tls_allowed_clients runtime file formats that can be managed by a later dedicated key lifecycle utility.
  • Keep PSK key reload transactional: new keys and authorization state are activated only after the full new state validates, and the old working keys remain active on failure.
  • Add nonblocking or bounded handshake behavior.
  • Disable 0-RTT and ticket-based session resumption in the first phase.
  • Add cleartext TCP hardening controls and no automatic fallback from TLS.
  • Add NixOS-compatible but secure PSK path validation.
  • Add reload behavior that preserves the old working TLS context on reload failure.
  • Add audit-system records for PSK identity and negotiated TLS parameters without exposing PSK material.
  • Record cryptographic connection establishment in the audit system with remote IP address, identity, success or failure result, and failure reason where safe. Syslog-only diagnostics are not sufficient.
  • Keep X.509 mTLS as a future authentication mode with SAN/EKU/role validation.

References

All information in this wiki is licensed under the CC BY 4.0 license.

Clone this wiki locally