Zusammenfassung

  • draft-ietf-rpp-core-01 vom 2. November ergänzt das RESTful Provisioning Protocol um Regeln für Weiterleitungen. Das Dokument ist ein Arbeitsgruppenentwurf, kein RFC.
  • Der Server darf nur 307 oder 308 mit einer absoluten HTTPS-Adresse verwenden. Folgt der Client, muss er Inhalt und Header einschließlich RPP-Cltrid erhalten.
  • Bei einem anderen Ursprung bleiben Authorization und RPP-Authorization zurück, außer der Client kennt ein Alias oder besitzt für den neuen Ursprung gültige Zugangsdaten.

Ein Wegweiser ist keine Vollmacht

Die technische Adresse einer Registry kann sich ändern. Ein Registrar, der dort einen Domain-Eintrag anlegt oder ändert, schickt aber mehr als einen gewöhnlichen Seitenaufruf: Er sendet eine Operation mit Identität und Berechtigung. Die Fassung vom 2. November trennt deshalb die Frage nach dem Weg von der Frage nach den Schlüsseln.

Für den Weg sind nur HTTP 307 und 308 vorgesehen. Beide bewahren die Methode; Location muss eine absolute HTTPS-URL enthalten. Der Client darf der Weiterleitung folgen. Tut er es, sendet er denselben Inhalt und dieselben Header weiter, darunter die Transaktionskennung RPP-Cltrid. So bleibt die umgeleitete Operation für die Idempotenz dieselbe Operation. Andere Weiterleitungscodes sind Protokollfehler, auch wenn ein zwischengeschalteter Dienst sie erzeugt.

Die Zugangsdaten folgen einer strengeren Logik. Wechselt der Ursprung, darf der Client weder Authorization noch RPP-Authorization einfach weitergeben. Er kann den neuen Ursprung als Alias des alten kennen. Oder er verfügt über Zugangsdaten, die gerade für das neue Ziel gültig sind, und verwendet diese. Ein Server kann mit einem Weiterleitungsheader einen Ort nennen; er kann dem neuen Ort damit keine Berechtigung verleihen.

Hinzu kommt eine ausdrückliche Pflicht zur Serverprüfung. Vor dem Versand muss der Client die TLS-Zertifikatskette und den Abgleich mit dem Hostnamen der URL prüfen. Scheitert das, wird die Anfrage nicht gesendet. Dienstsuche, Identitätsprüfung und Freigabe der Zugangsdaten bleiben getrennte Schritte. Gerade bei einem Umzug schützt diese Trennung vor dem bequemen, aber falschen Schluss, die neue Adresse sei schon deshalb vertrauenswürdig.

RPP liegt als Entwurf der IETF-Arbeitsgruppe vor. Die Originalquellen belegen weder einen produktiven Einsatz noch einen Vorfall. Sie belegen eine präzise neue Grenze: Wer den Zielserver benennt, erhält dadurch noch keine Verfügung über die Geheimnisse des Registrars.

Originalquellen