5. IANA-Überlegungen (IANA Considerations)

5.1 Registry der Authentifizierungsschemata (Authentication Scheme Registry)

Die "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" definiert den Namensraum für die Authentifizierungsschemata in Challenges und Anmeldedaten. Sie wurde eingerichtet und wird nun unter http://www.iana.org/assignments/http-authschemes gepflegt.

5.1.1 Verfahren (Procedure)

Registrierungen müssen die folgenden Felder enthalten (MUST):

• Name des Authentifizierungsschemas (Authentication Scheme Name)
• Verweis auf den Spezifikationstext (Pointer to specification text)
• Anmerkungen (optional) (Notes (optional))

Werte, die diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe [RFC5226], Abschnitt 4.1).

5.1.2 Überlegungen für neue Authentifizierungsschemata (Considerations for New Authentication Schemes)

Es gibt bestimmte Aspekte des HTTP-Authentifizierungsrahmenwerks, die Einschränkungen dafür auferlegen, wie neue Authentifizierungsschemata funktionieren können:

• Es wird angenommen, dass die HTTP-Authentifizierung zustandslos ist: Alle Informationen, die zur Authentifizierung einer Anfrage erforderlich sind, müssen in der Anfrage bereitgestellt werden, statt davon abzuhängen, dass der Server sich an frühere Anfragen erinnert (MUST). Eine Authentifizierung, die auf der zugrunde liegenden Verbindung beruht oder an sie gebunden ist, liegt außerhalb des Geltungsbereichs dieser Spezifikation und ist inhärent fehlerhaft, sofern nicht Maßnahmen ergriffen werden, die sicherstellen, dass die Verbindung von keiner anderen Partei als dem authentifizierten Benutzer verwendet werden kann (siehe Abschnitt 2.3 von [RFC7230]).

• Der Authentifizierungsparameter "realm" ist für die Definition von Schutzbereichen reserviert, wie in Abschnitt 2.2 beschrieben. Neue Schemata dürfen ihn nicht in einer mit dieser Definition unvereinbaren Weise verwenden (MUST NOT).

• Die Notation "token68" wurde aus Kompatibilität mit bestehenden Authentifizierungsschemata eingeführt und kann nur einmal pro Challenge oder Anmeldedaten verwendet werden. Daher sollten neue Schemata stattdessen die auth-param-Syntax verwenden, weil ansonsten künftige Erweiterungen unmöglich wären.

• Die Analyse von Challenges und Anmeldedaten ist durch diese Spezifikation definiert und kann von neuen Authentifizierungsschemata nicht verändert werden. Wenn die auth-param-Syntax verwendet wird, sollten alle Parameter sowohl die token- als auch die quoted-string-Syntax unterstützen, und syntaktische Einschränkungen sollten für den Feldwert nach der Analyse (d. h. nach der quoted-string-Verarbeitung) definiert werden. Dies ist notwendig, damit Empfänger einen generischen Parser verwenden können, der auf alle Authentifizierungsschemata anwendbar ist.

Hinweis: Die Tatsache, dass die Wertsyntax für den Parameter "realm" auf quoted-string beschränkt ist, war eine schlechte Entwurfsentscheidung, die bei neuen Parametern nicht wiederholt werden sollte.

• Definitionen neuer Schemata sollten die Behandlung unbekannter Erweiterungsparameter festlegen. Im Allgemeinen ist eine "must-ignore"-Regel einer "must-understand"-Regel vorzuziehen, weil es ansonsten schwierig sein wird, neue Parameter einzuführen, wenn veraltete Empfänger vorhanden sind. Darüber hinaus ist es gut, die Richtlinie für die Definition neuer Parameter zu beschreiben (etwa „die Spezifikation aktualisieren" oder „diese Registry verwenden").

• Authentifizierungsschemata müssen dokumentieren, ob sie bei der Ursprungsserver-Authentifizierung (d. h. unter Verwendung von WWW-Authenticate) und/oder bei der Proxy-Authentifizierung (d. h. unter Verwendung von Proxy-Authenticate) verwendbar sind.

• Die in einem Header-Feld Authorization mitgeführten Anmeldedaten sind für den Benutzeragenten spezifisch und haben daher im Geltungsbereich der Anfrage, in der sie erscheinen, dieselbe Wirkung auf HTTP-Zwischenspeicher wie die Antwortdirektive "private" von Cache-Control (Abschnitt 5.2.2.6 von [RFC7234]).

Daher müssen neue Authentifizierungsschemata, die sich dafür entscheiden, keine Anmeldedaten im Header-Feld Authorization mitzuführen (z. B. unter Verwendung eines neu definierten Header-Felds), das Zwischenspeichern ausdrücklich verbieten, indem sie die Verwendung entweder von Cache-Control-Anfragedirektiven (z. B. "no-store", Abschnitt 5.2.1.5 von [RFC7234]) oder von Antwortdirektiven (z. B. "private") vorschreiben.

5.2 Registrierung der Statuscodes (Status Code Registration)

Die unter http://www.iana.org/assignments/http-status-codes befindliche "Hypertext Transfer Protocol (HTTP) Status Code Registry" wurde mit den untenstehenden Registrierungen aktualisiert:

Wert	Beschreibung	Referenz
401	Unauthorized	Abschnitt 3.1
407	Proxy Authentication Required	Abschnitt 3.2

5.3 Registrierung der Header-Felder (Header Field Registration)

HTTP-Header-Felder werden in der unter http://www.iana.org/assignments/message-headers/ gepflegten Registry "Message Headers" registriert.

Dieses Dokument definiert die folgenden HTTP-Header-Felder, sodass die Registry "Permanent Message Header Field Names" entsprechend aktualisiert wurde (siehe [BCP90]).

Header-Feldname	Protokoll	Status	Referenz
Authorization	http	standard	Abschnitt 4.2
Proxy-Authenticate	http	standard	Abschnitt 4.3
Proxy-Authorization	http	standard	Abschnitt 4.4
WWW-Authenticate	http	standard	Abschnitt 4.1

Der Change Controller ist: "IETF ([email protected]) - Internet Engineering Task Force".

---