Zusammenfassung
- RFC 9729 lässt einen vorab ausgestatteten Client bereits mit der ersten Anfrage einen Nachweis senden; ein 401-Challenge muss die geschützte Fähigkeit nicht mehr verraten.
- Der Nachweis bindet Ursprung und TLS-Verbindung, aber nicht Methode, Pfad oder Inhalt. Damit gehören Verbindungswiederverwendung, TLS-Terminierung und der Vertrauenssprung zum Backend zur Authentifizierungsgrenze.
- Eine nach außen einheitliche Nicht-Existenz-Antwort ist keine Diagnose. Intern müssen Sperrung, Schlüsselgeneration, Frontend, Berechtigung und tatsächliche Auslieferung unterscheidbar bleiben.
Eine nicht öffentlich auffindbare Betriebsschnittstelle antwortet einem Unbekannten so, als habe es den Pfad nie gegeben. Ein berechtigter Client ruft dieselbe Adresse mit einer Concealed-Berechtigung auf und erhält den Dienst. Der Server musste nicht zuvor mitteilen, dass er eine Anmeldung erwartet. Der Client bringt den Nachweis mit.
RFC 9729 verwendet dazu einen TLS Keying-Material Exporter. Dessen verbindungsspezifischer Wert ersetzt die Frische eines Server-Challenges. Die öffentliche Auskunft wird kleiner; die operative Autorität verschwindet nicht. Sie liegt nun bei den Stellen, die Schlüssel ausgeben, akzeptierte Schlüssel verteilen, TLS beenden und den Nachweis an die Anwendung übergeben.
Die erste Vertrauensentscheidung liegt außerhalb von HTTP
Der Standard setzt einen externen Mechanismus zur Schlüsselverteilung voraus. Der Client besitzt Kennung und asymmetrisches Schlüsselpaar, der Ursprung eine Zuordnung akzeptierter Kennungen zu öffentlichen Schlüsseln. Wer zugelassen ist, wie der private Schlüssel geschützt wird, wie Verlust gemeldet und wann eine Sperrung vollständig umgesetzt ist, bleibt Organisationsaufgabe.
Eine korrekte Signatur gegen einen alten Datenbestand beweist exakt eine alte Regel. Das Löschen einer Client-Datei sperrt keinen weiterhin akzeptierten öffentlichen Schlüssel. Auch ein Datenbank-Update ist erst dann wirksam, wenn jeder Verifier, der die Ressource ausliefern kann, die neue Generation geladen hat und ein negativer Versuch die alte Berechtigung tatsächlich zurückweist.
Ein belastbares Inventar verknüpft Aussteller, Subjektklasse, Ursprung und Realm, Fingerprint, Aktivierung, Ablauf, Sperrstatus, Verteilungsgeneration und alle konsumierenden Prüfpunkte. Der private Schlüssel bleibt verborgen; die Entscheidungskette muss prüfbar sein.
Die genaue Reichweite des Exporter-Kontexts
Der registrierte Bezeichner lautet EXPORTER-HTTP-Concealed-Authentication. In den Kontext gehen TLS-Signaturverfahren, Schlüsselkennung, öffentlicher Schlüssel, URI-Scheme, Host, Port und optional Realm ein. Von 48 Ausgabebytes fließen 32 in die Signaturvorlage, 16 werden als Prüfwert v übertragen.
Die Berechtigung enthält außerdem k, a, p und s. Der Server findet die Kennung, vergleicht den präsentierten mit dem gespeicherten öffentlichen Schlüssel, prüft v gegen diese Verbindung und validiert die Signatur. Die expliziten Vergleiche begrenzen Schlüsselverwechslung und koppeln die Annahme an den erwarteten Kanal.
Methode, Pfad und Body sind nicht Teil des Kontexts. Derselbe Schlüssel erzeugt auf derselben Verbindung für verschiedene Anfragen denselben Nachweis. Das spart Header-Volumen, macht aber die Isolierung multiplexierter Kontexte sicherheitsrelevant: Wer den Authorization-Header eines anderen Kontexts lesen kann, kann ihn innerhalb dieser Verbindung wiederholen.
Auch Frische hat ein Alter. Ein Nachweis kann so alt sein wie eine langlebige oder wiederaufgenommene Verbindung. Eine erzwungene Neuverbindung verkürzt das Fenster, kostet aber Handshakes, Kapazität und Verfügbarkeit. Verbindungsalter, Resumption-Herkunft und Erneuerungsgrund gehören zum Authentifizierungsdatensatz.
Der TLS-Terminator wird zum Identitätszeugen
In einer geteilten Architektur beendet ein Frontend TLS oder QUIC und sendet den ursprünglichen Authorization-Header zusammen mit Concealed-Auth-Export an das Backend. Das Backend kann den Exporter des Client-Frontend-Kanals nicht aus seiner eigenen Verbindung rekonstruieren. Es übernimmt eine Aussage des Frontends.
Daher darf es das Feld nur von einem bereits vertrauenswürdigen Absender verwenden; das Frontend darf eine vom Client eingespeiste Kopie nicht weiterreichen. Ein Load Balancer, der den für Identitätsannahme entscheidenden Wert erzeugen kann, ist nicht bloß Transport.
Ein breites Netz-ACL ist dafür oft zu unscharf. Nachweise sollten authentifizierte Frontend-Identität, Software- und Konfigurationsgeneration, clientseitige Verbindung, Virtual Host, normalisierte Authority, geschützte Exporter-Korrelation und Zielroute enthalten. Entfernt ein Mesh den Header, verdoppelt es ihn oder baut es den Kontext mit einem anderen Host, bleibt außen womöglich nur eine perfekte 404-Antwort.
Nach fünf Prüfungen beginnt erst die Autorisierung
Das Backend parst die Parameter, findet die Kennung, vergleicht den Schlüssel, vergleicht den Exporter-Prüfwert und prüft die Signatur. Jede Abweichung wird wie eine fehlende Berechtigung behandelt. Erst nach allen Prüfungen gilt der Client als authentifiziert.
Damit ist die Operation noch nicht erlaubt. Ein gültiger Auftragnehmer darf vielleicht nur eine Funktion nutzen; ein Konto kann gesperrt sein; ein Backend kann alte Autorisierungsdaten tragen. Umgekehrt könnte eine Route die Ressource liefern, ohne Concealed überhaupt auszuführen. Authentifizierung, Autorisierungsentscheidung und Ressourceneffekt müssen getrennte Ereignisse sein und durch einen Client-Canary zusammengeführt werden.
Einheitliche Fehler sind Offenlegungspolitik
Für eine nicht ausforschbare Ressource muss ein Authentifizierungsfehler genau die Antwort einer nicht existierenden Ressource erhalten. Status 404 allein genügt nicht. Body, Header, Cache, Verbindungsbehandlung, Länge und Latenzverteilung können Zweige unterscheiden.
Signaturprüfung kostet Zeit. Antwortet ein unbekannter Pfad sofort, während der geschützte Pfad Schlüssel sucht und Kryptografie ausführt, entsteht ein Timing-Orakel. Getestet werden Verteilungen unter vergleichbarer Last, nicht zwei Einzelmessungen. Index, Sitemap, Fehlermeldung, Client-Bundle, Telemetrie, Dokumentation oder DNS können die Existenz ebenfalls offenlegen.
Auch der Normtext braucht Versionsnachweise
Das Errata-Verzeichnis liefert ein praktisches Beispiel. Erratum 8807, bereits bestätigt, korrigiert das Hex-Beispiel: Es codierte HTTP Signature Authentication, während die normative Konstruktion HTTP Concealed Authentication verlangt. Wer das Beispiel kopierte, kann Interoperabilität verlieren und sieht nur den absichtlich unspezifischen Fehler.
Das noch gemeldete Erratum 8843 betrifft die Integer-ABNF für s: Die gedruckte Form schließt einstellige Nichtnullwerte aus, obwohl der Text 0 bis 65535 zulässt. Betreiber müssen Parser-Version, gewählte Auslegung und Kompatibilitätstests festhalten und den Status verfolgen.
IANA registriert Scheme, HTTP-Feld und Exporter-Label. Das koordiniert Namen und Referenzen, beweist aber weder Client-Unterstützung noch korrekte Schlüsselvergabe, Routenabdeckung oder Antwortgleichheit. Dokumentarische Autorität und ausführbare Wirkung bleiben unterschiedliche Realitätsebenen.
Zwei Oberflächen mit absichtlich verschiedener Schärfe
Die öffentliche Oberfläche minimiert Unterschiede für Unbefugte. Die private, zugriffskontrollierte Oberfläche unterscheidet fehlerhaftes Format, unbekannten oder gesperrten Schlüssel, abweichenden öffentlichen Schlüssel, Exporter-Mismatch, ungültige Signatur, ungeeignetes TLS, nicht vertrauenswürdiges Frontend, Autorisierungsverweigerung, Fehlroute und nachgelagerten Ausfall.
Diese Gründe dürfen nicht in Antworttext oder Timing zurückfließen. Sie benötigen geschützte Korrelation, definierte Aufbewahrung und Zugriffskontrolle. Die Negativmatrix enthält echte unbekannte Pfade, verborgene Pfade ohne Berechtigung, beschädigte Nachweise, unbekannte und gesperrte Schlüssel, falschen Host oder Port, ungeeignetes TLS, clientseitig injizierte Exporter-Felder, nicht vertrauenswürdige Frontends und Verweigerung nach gültiger Authentifizierung. Außen konvergieren die vorgesehenen Fälle, innen bleiben sie unterscheidbar.
Quellen
- RFC 9729, RFC-Editor-Information und Errata
- IETF-Datatracker-Eintrag
- IANA-Register für HTTP-Authentifizierung, HTTP-Felder und TLS-Parameter
- RFC 9110, RFC 5705, RFC 7627 und RFC 8446
- Lu Heng: Running-Code Primacy, Minimum Initial Specification und Reality Layers
- Ergänzende Primärquellen: RFC 9729 als Klartext, RFC 9846 zu TLS-Exporter-Labels und RFC 9266 zu Channel Bindings
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

