Zusammenfassung

  • draft-cel-nfsv4-rpc-tls-othername-04 vom 5. September 2026 schlägt vor, genau eine RPC-Nutzeridentität in einem X.509-subjectAltNameotherName zu tragen. Es ist ein individueller Internet-Draft, keine RFC, kein IETF-Konsens und kein Einsatznachweis.
  • Ein durchsetzender Server ersetzt die AUTH_NONE- oder AUTH_SYS-Identität des Headers durch die geprüfte Zertifikatsidentität. Scheitern Abbildung oder Autorisierung, verweigert er mit AUTH_TOOWEAK, ohne auf den Header zurückzufallen.
  • Ein nicht unterstützender oder deaktivierter Server ignoriert dasselbe Feld und behandelt die gewöhnliche RPC-Credential. Der Client kann die beiden Fälle nicht unterscheiden; die Ausstellung beweist deshalb keine wirksame Beschränkung.

Ein Sicherungsdienst erhält ein Zertifikat, das ihn auf das Konto backup festlegen soll. Am ersten Speicherknoten wird eine abweichende UID im RPC-Header ignoriert. Am zweiten Knoten gelingt dieselbe TLS-Authentisierung, doch der unbekannte Namenstyp wird übergangen und die UID aus dem Header wieder ausgewertet.

Die Signatur hat sich nicht verändert. Verändert hat sich, welche Software ihr eine Autorisierungswirkung gibt.

Revision 04 des Identitäts-Squashing-Entwurfs setzt an einer bewusst offenen Grenze von RFC 9289 an. RPC über TLS schützt Vertraulichkeit und Integrität und authentisiert Peers, lässt die RPC-Nutzerauthentisierung aber unberührt. Für Geräte und Dienste, die nur als ein Nutzer handeln sollen, soll das Clientzertifikat diesen Nutzer nennen; der Server prüft ihn beim Sitzungsaufbau und verwendet ihn statt schwächerer Behauptungen in einzelnen Aufrufen.

Drei Formen sind vorgesehen. RPCAuthSys enthält numerische UID und GIDs. GSSExportedName trägt einen mechanismusspezifischen Exportnamen, für Kerberos im Umfeld von RFC 4121. NFSv4Principal nutzt das user@domain-Format aus RFC 8881, das der Server über sein Owner-Mapping auflöst.

Diese Formen sind keine beliebig austauschbaren Schreibweisen. Zahlen brauchen konsistente Nutzer- und Gruppenbestände, ein GSS-Name einen vollständig unterstützten Mechanismus und der NFSv4-Principal lokale Domainregeln. Enthält ein Zertifikat mehr als eine Squashing-Identität, muss der Server es ablehnen. Mehrdeutigkeit wird durch eine Signatur nicht eindeutig.

Der Sicherheitsgewinn steckt im verbotenen Rückfall

Ein durchsetzender Server validiert zuerst den X.509-Pfad nach RFC 5280 und den RPC-with-TLS-Regeln. Dann liest er eine einzige Identität, bildet sie auf einen lokalen Nutzer ab und prüft, ob der authentisierte Peer sie verwenden darf. Subject-ACLs, UID/GID-Bereiche, Gruppenregeln, erwartete Domains oder zugelassene GSS-Mechanismen können Teil dieser lokalen Entscheidung sein.

Das Ergebnis wird an die TLS-Sitzung gebunden. Für AUTH_NONE und AUTH_SYS ignoriert der Server anschließend die Identität im RPC-Header nach RFC 5531. RPCSEC_GSS bleibt davon ausgenommen: Sein Sicherheitskontext nach RFC 2203 hat bereits eine eigene Identität nachgewiesen.

Ist die Zertifikatsidentität fehlerhaft, nicht abbildbar oder nicht autorisiert, erhalten betroffene Nicht-NULL-Prozeduren AUTH_TOOWEAK. Der Server darf dann nicht die Header-Identität als Ersatz akzeptieren. Ein solcher Fallback würde genau die Berechtigung zurückbringen, die das Zertifikat beschneiden sollte.

Ein altes Programm kennt dieses Verbot jedoch nicht. Das Profil verlangt ein nicht leeres Subject und einen nicht kritischen SAN; die neue Bedeutung steckt im type-id eines otherName. Ältere Software kann die SAN-Erweiterung erkennen, den unbekannten inneren Typ ignorieren und nach bisheriger Header-Policy fortfahren. Ein moderner Server mit abgeschalteter Funktion verhält sich ebenso. Der Client erkennt den Unterschied nicht.

Diese Wahl erhält Interoperabilität. Wäre der ganze SAN kritisch, könnten alte Systeme das Zertifikat mitsamt anderen gültigen Namen ablehnen. Die Migration wird damit leichter, doch die signierte Einschränkung ist kein portables Vollstreckungsversprechen.

Die Bestandsliste braucht eine Sitzungsquittung

Der maßgebliche Bestand verknüpft Zertifikatsprofil, Ausstellungszweck, Trust Anchor, Knoten-Build, Aktivierungszustand, Policy-Umfang, Mappingdaten, RPC-Flavor und konkrete Sitzung. Der Entwurf gestattet eine serverweite, exportbezogene oder anders lokal zugeschnittene Anwendung. „Unterstützt“ ist daher kein ausreichendes Kontrollfeld.

Hinter einem Load Balancer kann eine Sitzung an einem Knoten landen, der die Header-UID ersetzt, und die nächste an einem, der sie beibehält. Beide liefern Antworten, beide erscheinen verfügbar. Nur die Autorisierungssemantik wechselt unbemerkt.

Auch Widerruf ist lediglich ein Teil der Kette. Wo die Funktion greift, vermittelt das Zertifikat Zugriff als Nutzer; Laufzeit sowie Aktualität von CRL oder OCSP sind deshalb relevant. Revision 04 empfiehlt separate Trust Anchors für Squashing-Zertifikate und Zertifikate, die lediglich den TLS-Peer authentisieren. Eine frische Widerrufsauskunft beweist dennoch keine OID-Auswertung, und ein richtiger Parser keine richtige Nutzerzuordnung.

Der Entwurf führt eine von Mitwirkenden gemeldete FreeBSD-Implementierung der user@domain-Form als abgeschlossen auf. Er erklärt zugleich, dass dies weder IETF-Billigung noch unabhängige Prüfung oder Produktkatalog sei; Einsatzerfahrung wird nicht berichtet. RFC 7942 begründet den Wert solcher Running-Code-Angaben für die Standardisierung, macht aus einer Meldung aber keinen Produktionsnachweis.

Hier hilft Heng Lus Trennung der Realitätsebenen: Signiertes Feld, Serverentscheidung und Ressourceneffekt sind nicht dieselbe Evidenz. Der Vorrang des laufenden Codes verlangt den Blick auf das tatsächlich bedienende Binary. Eine minimale Ausgangsspezifikation kann den gemeinsamen Sockel definieren, ohne eine bereits vollzogene Adoption zu behaupten.

Die Auditfrage lautet deshalb: Welcher Knoten kann nachweisen, dass er in dieser Sitzung die Zertifikatsidentität verwendete und die konkurrierende Header-Angabe verwarf?

Quellen