From 4730672f107d8e39ab5edfcb85b97367c3055252 Mon Sep 17 00:00:00 2001 From: "glm-5.3-flash" Date: Sun, 13 Sep 2026 16:15:57 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20OQ-SK-02=20direction=20settled=20?= =?UTF-8?q?=E2=80=94=20"both"=20auth,=20split=20by=20the=20door?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - endgame story makes both mechanisms real: consumer binds the produced SOCKS5 resource locally (optional front door, ssh -D shape without the forced bind) and points tun2proxy at it - producer side: identity seam only (CF-005/CF-006); a password there is moot against the ACL system — in-band conversation runs NoAuth - consumer front door: owns RFC 1929 where vanilla clients need it (tun2proxy/curl user:pass), maps accepted credentials to the channel identity it opens the producer with; the SOCKS password never crosses the channel as a SOCKS password - replace-or-second-gate sub-question dissolves: the mechanisms occupy different planes (door-local creds vs channel-level identity) - remaining for Phase 1: credential->identity mapping shape; producer- side local backend door surface; AuthMethod trait vs door-owned check --- docs/research/phase-0.md | 57 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) diff --git a/docs/research/phase-0.md b/docs/research/phase-0.md index 50fbe80..d2094f9 100644 --- a/docs/research/phase-0.md +++ b/docs/research/phase-0.md @@ -388,10 +388,52 @@ own optional username/password auth (RFC 1929). Questions: consults the alkcall `AuthContext`/`Identity` (filed upstream if the hook shape doesn't fit — AGENTS.md convention 17)? -Hunch: identity-at-the-open-op is the primary gate for -channels-native consumers; in-band username/password exists for the -local-backend path only. Needs a decision (and possibly an upstream -ask) in Phase 1. +(Answered in direction by the 2026-09-13 posture statement below: +yes / planes-don't-compare / probably-not — Phase 1 formalizes.) + +**Posture — settled direction (2026-09-13 discussion): "both," split +by the door.** The planned end-to-end story is the vpn-like +composition: a consumer connects to an endpoint producing the SOCKS5 +resource, *optionally* binds it locally (component 2's front door — +ssh `-D`'s shape, with the defining difference that no port is bound by +default), and points tun2proxy (`--proxy socks5://user:pass@host:port` +natively, per §Vision principle 6) at the local port. That makes "both" +auth mechanisms real, each on its own side of the door: + +- **Producer side: identity only.** The channels-native open is + authorized by the alkcall ACL/identity seam (CF-005/CF-006); a + producer-side password is moot — the ACL system is strictly better + than a shared secret, and the producer's in-band conversation runs + NoAuth/no-op. A password there would add nothing the identity seam + doesn't already do. +- **Consumer side (the front door): RFC 1929 where vanilla clients + need it.** The door is where the vanilla world meets the ACL world, + so it owns credential presentation: a vanilla client carrying + `user:pass` (tun2proxy, curl) gets a real RFC 1929 conversation at + the door. The door then maps the accepted credential to *local* + configuration — which channel identity/endpoint to open the producer + channel with — and that identity reaches the producer via the + CF-005/CF-006 seam. The SOCKS password never crosses the channel as + a SOCKS password; the channel identity never reaches the vanilla + client. + +The "replace or second-gate" sub-question dissolves: the mechanisms +occupy different planes (in-band creds are door-local; identity is +channel-level). The NoAuth door (POC #1's raw-pipe shape, zero +protocol translation) remains valid for loopback-only or wrapper-aware +use; the cred-bearing door is the same bridge plus the greeting half +(fast-socks5's server typestate for auth + `read_command`, then the +consumer session in-band) — an assembly-layer choice, not a protocol +one. + +Remaining for Phase 1: the door's credential→identity mapping shape +(static config vs pluggable lookup); whether the producer-side +optional local backend offers the same door surface (same code shape — +door = vanilla↔ACL boundary — so presumably yes); and whether the door +needs a fast-socks5 `AuthMethod` impl or simply checks credentials +itself before handing the stream to the typestate (likely the latter — +the door is this crate's code, the trait was designed for embedders +who don't own the accept loop). ### OQ-SK-03: UDP ASSOCIATE without binding — the hard case @@ -824,7 +866,12 @@ Candidate reading for the research specialist (to be expanded): primary, in-band auth for the local backend); **POC #1 validated the seam end to end** (per-call opener identity at the establisher; channel-0 identity propagation is a producer - harness wiring requirement); decide in Phase 1 + harness wiring requirement); **direction settled 2026-09-13** + ("both," split by the door: producer-side identity only — a + password there is moot against the ACL; consumer-side front door + owns RFC 1929 for vanilla clients and maps credentials to the + channel identity); Phase 1 formalizes the door's + credential→identity mapping - [ ] OQ-SK-03 (UDP ASSOCIATE) — the shape space written (including the phase-model-vs-alktty-demux analysis); resolve via research + POC #2, ADR before the first consumer