ADR-120 — Authentification hostbased : grappes en confiance mutuelle, signature via air-keysign (sans setuid), confiance transitive assumée

Statut : Accepté (2026-07-26, décision BDFL). RFC de direction (ADR-015). S’appuie sur ADR-094 (userauth — hostbased = une méthode), ADR-108 (air-keystore + service air-keysign oracle-safe), ADR-089 (SecurityManager — politique), ADR-091 (codec sans-IO), ADR-029 (nommage). Compagnon d’ [ADR-121] (provisioning) : celui-ci n’utilise PAS hostbased (voir §4).

Catégorie : Méthode d’authentification (couche 2 protocole + orchestration keystore). Vague 2 #8.

Contexte

En hostbased, un hôte authentifie au nom de ses utilisateurs : le client signe la requête avec sa clé d’hôte (pas la clé de l’utilisateur), en affirmant « l’utilisateur X sur l’hôte Y » ; le serveur fait confiance à la clé d’hôte de Y et à une liste de couples (hôte, utilisateur) autorisés. C’est précieux pour des grappes en confiance mutuelle (calcul, CI, orchestration inter-hôtes) où recopier des authorized_keys par utilisateur est lourd.

Deux caveats structurants : (1) côté client, signer avec la clé d’hôte privée depuis un processus non privilégié — OpenSSH utilise un helper setuid (ssh-keysign), qu’Air refuse ; (2) confiance transitive — une station cliente compromise peut usurper tous ses utilisateurs.

Directive BDFL (2026-07-26). « On avait oublié hostbased. Là je l’implémenterais — pour déployer à la chaîne des air-desktop-host. » Puis, après discussion : hostbased pour les grappes de confiance, mais pas pour le provisioning (chemin le plus sensible → [ADR-121]).

Décision

1. Hostbased = méthode userauth supportée (grappes de confiance)

air-sshd/air-ssh supportent la méthode hostbased ([ADR-094], RFC 4252 §9). Le codec (requête hostbased : nom d’algorithme, clé d’hôte cliente, nom d’hôte, nom d’utilisateur, signature) vit dans air-ssh-proto (couche 2, sans-IO [ADR-091], fuzzable).

2. Signature de la clé d’hôte via air-keysign — jamais setuid

Côté client, la signature hostbased est produite par le service air-keysign ([ADR-108] §5) — socket-activé, privilégié, oracle-safe, sans setuid. Son interface valide la structure du défi (lié session_id / nom d’hôte / nom d’utilisateur, RFC 4252 §9), refuse de signer des octets arbitraires, et restreint les appelants (peer-cred du socket Unix). On ferme ainsi la classe de vulnérabilités des helpers setuid et l’oracle de signature.

3. Confiance côté serveur

Le serveur s’appuie sur air-keystore ([ADR-108]) : magasin des clés d’hôtes de confiance (quels hôtes) + liste des couples (hôte, utilisateur) autorisés (qui, depuis où). La politique (activer hostbased, restreindre les hôtes/utilisateurs) relève du SecurityManager ([ADR-089]). Défaut : désactivé (opt-in explicite).

4. Confiance transitive assumée — et bornée

Hostbased implique qu’un hôte client compromis usurpe tous ses utilisateurs. On l’assume pour des grappes en confiance mutuelle, et on le borne : (a) opt-in + liste blanche d’hôtes/utilisateurs étroite ; (b) jamais dans le chemin le plus sensible — le provisioning ([ADR-121]) utilise une clé d’amorçage jetable / cert court, pas hostbased, précisément pour éviter la confiance transitive là où elle serait dangereuse.

Conséquences

Positives.

• Grappes de confiance : accès inter-hôtes sans distribution N×M d’authorized_keys.
• Sans setuid : air-keysign oracle-safe remplace ssh-keysign → classe de vulnérabilités fermée.
• Politique centralisée (SecurityManager) + défaut désactivé : surface maîtrisée.

Négatives / coûts assumés.

• Confiance transitive : intrinsèque à hostbased ; assumée pour les grappes, exclue du provisioning. Documentée comme limite de sécurité.
• Codec hostbased = surface pré-auth ⇒ sans-IO + fuzz obligatoires.
• Dépend de air-keysign (service privilégié) : composant du TCB à durcir.

Mise en œuvre (référence, hors décision). Incréments : (a) méthode hostbased dans air-ssh-proto (codec) + userauth air-sshd/air-ssh ([ADR-094]) ; (b) signature via air-keysign ([ADR-108]) ; (c) magasin hôtes de confiance + couples (hôte, utilisateur) dans air-keystore ; (d) politique SecurityManager ([ADR-089]), défaut désactivé. Non engagés par cet ADR.

Alternatives rejetées

Aucune alternative n’a été consignée lors de l’instruction.