P0 — add CURVE/ZAP authentication, authorization, key lifecycle, and daemon abuse controls #130

New issue

Closed

opened 2026-08-21 23:40:50 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-21 23:40:50 +00:00

(Migrated from github.com)

Parent epic: #127
Depends on: #129
Research: docs/research/001-daemon-zeromq-voice-service.md

Goal

Make the daemon safe for authenticated multi-user operation before remote listening is considered production-ready.

Authentication

daemon long-term CURVE keypair;
unique CURVE keypair per client/device;
client pins daemon public key;
ZAP maps client public key to an internal Zara principal and role/capability set;
authenticated principal is attached server-side to every request/session;
payload-supplied user_id or display identity cannot override the principal;
explicit key enrollment, rotation, revocation, and disabled-key behavior;
owner-only key material permissions and sanitized diagnostics.

Authorization

Define a principal-aware authorization boundary for:

ordinary conversation/voice actions;
tool approvals/side effects;
context/memory access;
daemon administration/status;
future plugin-contributed capabilities.

Authentication alone must not grant every Zara capability.

Safe listener policy

remote/wildcard TCP bind is opt-in;
daemon rejects unsafe public/wildcard binding when secure auth is not configured;
NULL auth is fixture/development-only;
do not use ZMTP PLAIN as the production remote transport security mechanism;
local IPC/loopback policy is explicit and documented.

Abuse/resource controls

Per-principal or per-session bounds for:

connections;
request rate;
queued messages/mailboxes;
audio bytes/time;
concurrent turns;
provider/model requests;
tool runs;
malformed protocol errors.

Use ZeroMQ HWM/MAXMSGSIZE/timeouts/heartbeats together with application quotas.

Audit

Add a bounded structured security audit record containing principal/session/request/turn identifiers, action, authorization result, error class, and timing. Never include raw audio, transcript text, prompts, provider auth headers, API keys, CURVE secret keys, or secret-looking environment/config dumps.

Tests

valid enrolled client;
unknown key denied;
revoked key denied without daemon restart where practical;
wrong pinned server key fails;
spoofed user_id ignored/rejected;
unauthorized capability denied;
admin vs normal-user separation;
wildcard bind without auth rejected;
oversized/rate-limited client isolated from healthy client;
malformed-auth/protocol flood remains bounded;
audit redaction fixtures;
no secret key material reaches logs/errors/events;
focused security script plus full repo/Nix gate.

Acceptance

A daemon can authenticate distinct client devices into distinct Zara principals, enforce capability policy, revoke access, and remain bounded under hostile client behavior without exposing secrets.

References

ZeroMQ ZMTP-CURVE RFC 25
ZeroMQ ZAP RFC 27
PyZMQ CURVE documentation

Parent epic: #127 Depends on: #129 Research: `docs/research/001-daemon-zeromq-voice-service.md` ## Goal Make the daemon safe for authenticated multi-user operation before remote listening is considered production-ready. ## Authentication - daemon long-term CURVE keypair; - unique CURVE keypair per client/device; - client pins daemon public key; - ZAP maps client public key to an internal Zara principal and role/capability set; - authenticated principal is attached server-side to every request/session; - payload-supplied `user_id` or display identity cannot override the principal; - explicit key enrollment, rotation, revocation, and disabled-key behavior; - owner-only key material permissions and sanitized diagnostics. ## Authorization Define a principal-aware authorization boundary for: - ordinary conversation/voice actions; - tool approvals/side effects; - context/memory access; - daemon administration/status; - future plugin-contributed capabilities. Authentication alone must not grant every Zara capability. ## Safe listener policy - remote/wildcard TCP bind is opt-in; - daemon rejects unsafe public/wildcard binding when secure auth is not configured; - NULL auth is fixture/development-only; - do not use ZMTP PLAIN as the production remote transport security mechanism; - local IPC/loopback policy is explicit and documented. ## Abuse/resource controls Per-principal or per-session bounds for: - connections; - request rate; - queued messages/mailboxes; - audio bytes/time; - concurrent turns; - provider/model requests; - tool runs; - malformed protocol errors. Use ZeroMQ HWM/MAXMSGSIZE/timeouts/heartbeats together with application quotas. ## Audit Add a bounded structured security audit record containing principal/session/request/turn identifiers, action, authorization result, error class, and timing. Never include raw audio, transcript text, prompts, provider auth headers, API keys, CURVE secret keys, or secret-looking environment/config dumps. ## Tests - valid enrolled client; - unknown key denied; - revoked key denied without daemon restart where practical; - wrong pinned server key fails; - spoofed `user_id` ignored/rejected; - unauthorized capability denied; - admin vs normal-user separation; - wildcard bind without auth rejected; - oversized/rate-limited client isolated from healthy client; - malformed-auth/protocol flood remains bounded; - audit redaction fixtures; - no secret key material reaches logs/errors/events; - focused security script plus full repo/Nix gate. ## Acceptance A daemon can authenticate distinct client devices into distinct Zara principals, enforce capability policy, revoke access, and remain bounded under hostile client behavior without exposing secrets. ## References - ZeroMQ ZMTP-CURVE RFC 25 - ZeroMQ ZAP RFC 27 - PyZMQ CURVE documentation