Résumé

  • draft-cel-nfsv4-rpc-tls-othername-04, daté du 5 septembre 2026, place une identité RPC dans un otherName du subjectAltName X.509. C’est un Internet-Draft individuel, pas une RFC, un consensus IETF ni une preuve de déploiement.
  • Un serveur qui impose le mécanisme remplace l’identité AUTH_NONE/AUTH_SYS de l’en-tête par celle du certificat. Si validation, conversion ou autorisation échoue, il refuse sans revenir à l’en-tête.
  • Un serveur ancien ou un serveur où la fonction est désactivée ignore le champ et applique sa politique RPC habituelle. Le client ne distingue pas ces deux cas : émettre le certificat ne prouve donc pas l’exécution de la restriction.

Le même certificat peut signifier « toujours cet utilisateur » devant une machine et « choisissez l’utilisateur dans l’en-tête » devant la suivante. Aucun octet du certificat ne change. La frontière d’autorisation, elle, se déplace avec le code qui reçoit la session.

La révision 04 part d’une limite volontaire de RFC 9289. RPC avec TLS chiffre le trafic, protège son intégrité et authentifie les pairs ; il ne transforme pas l’identité RPC déclarée par chaque appel. Pour les portables mono-utilisateur, les conteneurs ou les services dédiés, le projet propose de mettre l’utilisateur dans le certificat client et de l’associer à la session TLS.

Trois représentations sont prévues. RPCAuthSys transporte UID et GID. GSSExportedName transporte un nom exporté lié à un mécanisme, notamment le format Kerberos de RFC 4121. NFSv4Principal transporte le user@domain de RFC 8881, que la table de propriétaires du serveur doit résoudre.

Le serveur ne peut pas traiter ces formes comme des synonymes faciles. Les nombres exigent des bases d’utilisateurs cohérentes ; le nom GSS exige un mécanisme maîtrisé ; le principal NFSv4 exige une politique de domaine. Si deux identités de réduction figurent dans le même SAN, le certificat doit être rejeté. Une ambiguïté signée reste une ambiguïté.

Le chemin qui refuse le repli

Un serveur actif valide d’abord la chaîne selon RFC 5280 et les règles RPC-TLS. Il lit l’unique otherName, calcule un utilisateur local et vérifie que le pair TLS peut réellement l’utiliser. Une ACL de sujet, les plages UID/GID, l’appartenance aux groupes, le domaine attendu et la confiance dans le mécanisme GSS sont autant de décisions locales.

Le résultat est attaché à la session. Pour AUTH_NONE et AUTH_SYS, l’identité inscrite dans l’en-tête RFC 5531 est ignorée. En revanche, une requête RPCSEC_GSS continue sous le contexte de sécurité de RFC 2203, car ce contexte a déjà prouvé son propre principal.

Si l’identité du certificat est invalide, impossible à mapper ou interdite, les procédures non NULL concernées reçoivent AUTH_TOOWEAK. Le serveur ne doit surtout pas reprendre l’identité de l’en-tête : ce repli redonnerait précisément le pouvoir que le certificat cherchait à retirer.

Le paradoxe apparaît avec la compatibilité. Le SAN doit être non critique et le nouveau sens réside dans le type OID d’un otherName. Un ancien serveur connaît l’extension SAN mais pas ce type interne ; il l’ignore et traite l’en-tête normalement. Un serveur moderne dont l’administrateur a coupé la fonction produit le même résultat. Le client ne sait pas lequel des deux il a rencontré.

Ce choix évite qu’un ancien logiciel rejette tout le certificat à cause d’une extension critique qu’il ne comprend pas. Il facilite une migration progressive. Mais il interdit de présenter le certificat comme une politique de moindre privilège autonome. La contrainte n’est réelle que là où un programme l’exécute.

L’inventaire doit suivre le nœud et l’export

Le contrôle complet relie profil de certificat, finalité d’émission, ancre de confiance, version du serveur, état de la fonction, portée locale, table de noms, saveur RPC et session. Le projet laisse au serveur le choix d’imposer la réduction globalement, par export ou selon une autre unité. « Compatible » ne dit donc pas où la règle s’applique.

Une ferme hétérogène peut faire varier l’autorité à chaque nouvelle connexion. Le répartiteur peut livrer une session à un nœud qui écrase l’UID de l’en-tête, puis la suivante à un nœud qui le conserve. Les deux nœuds répondent et les métriques de disponibilité restent vertes.

La révocation ne résout qu’une partie du problème. Ces certificats ouvrent un accès sous une identité d’utilisateur, donc durée de validité et fraîcheur CRL/OCSP sont importantes. Le projet recommande aussi des ancres distinctes de celles qui servent seulement à authentifier le pair TLS. Une révocation fraîche ne prouve cependant ni l’interprétation de l’OID, ni la justesse du mapping, ni l’autorisation du compte.

Le texte mentionne une implémentation FreeBSD user@domain déclarée complète par ses contributeurs. Il précise qu’elle n’est ni cautionnée par l’IETF, ni vérifiée indépendamment, ni représentative d’un marché, et qu’aucune expérience n’est rapportée. RFC 7942 valorise ces informations de code réel pour éclairer le processus ; elles ne deviennent pas un reçu de production.

La grille de Heng Lu sur les couches de réalité empêche ici une confusion commode : champ signé, décision serveur et effet sur le fichier sont trois preuves. La primauté du code en fonctionnement oblige à observer chaque binaire servant. Une spécification initiale minimale fixe le langage commun sans prétendre que l’adoption est déjà universelle.

La question de contrôle devient alors concrète : quel nœud peut montrer qu’il a choisi l’identité du certificat pour cette session et refusé l’identité concurrente de l’en-tête ?

Sources