Zum Hauptinhalt springen

10. Authentication and Message-Integrity Mechanisms (Authentifizierungs- und Nachrichtenintegritätsmechanismen)

Dieser Abschnitt definiert zwei Mechanismen, die Clients und Server verwenden können, um Authentifizierung und Nachrichtenintegrität in STUN bereitzustellen; diese beiden Mechanismen sind bekannt als Kurzzeit-Credential-Mechanismus (short-term credential mechanism) und Langzeit-Credential-Mechanismus (long-term credential mechanism). Diese beiden Mechanismen sind optional, und jede Verwendung muss (must) spezifizieren, ob und wann diese Mechanismen verwendet werden. Daher werden sowohl Clients als auch Server basierend auf dem Wissen, welche Verwendung gilt, wissen, welchem Mechanismus (falls vorhanden) zu folgen ist. Beispielsweise hätte ein STUN-Server im öffentlichen Internet, der ICE unterstützt, keine Authentifizierung, während die STUN-Server-Funktionalität in einem Agent, der Konnektivitätsprüfungen unterstützt, den Kurzzeit-Credential-Mechanismus verwenden würde. Eine Übersicht über diese beiden Mechanismen wird in Abschnitt 3 bereitgestellt.

Jeder Mechanismus spezifiziert die zusätzliche Verarbeitung, die erforderlich ist, um diesen Mechanismus zu verwenden, und erweitert die in Abschnitt 7 spezifizierte Verarbeitung. Die zusätzliche Verarbeitung erfolgt an drei verschiedenen Stellen: beim Bilden einer Nachricht, beim Empfangen einer Nachricht unmittelbar nachdem die grundlegenden Prüfungen durchgeführt wurden, und bei der detaillierten Verarbeitung von Fehlerantworten.

10.1. Short-Term Credential Mechanism (Kurzzeit-Credential-Mechanismus)​

Der Kurzzeit-Credential-Mechanismus geht davon aus, dass Client und Server vor der STUN-Transaktion ein anderes Protokoll verwendet haben, um ein Credential in Form von Benutzername und Passwort auszutauschen. Dieses Credential ist zeitlich begrenzt. Das Zeitlimit wird durch die Verwendung definiert.

Zum Beispiel verwenden in der ICE-Verwendung [MMUSIC-ICE] die beiden Endpunkte Out-of-Band-Signalisierung, um sich auf einen Benutzernamen und ein Passwort zu einigen, und dieser Benutzername und dieses Passwort gelten für die Dauer der Mediensitzung.

Dieses Credential wird verwendet, um in jeder Anfrage und in vielen Antworten eine Nachrichtenintegritätsprüfung zu bilden. Es gibt keine Herausforderung und Antwort wie beim Langzeitmechanismus; folglich wird Replay durch die zeitlich begrenzte Natur des Credentials verhindert.

10.1.1. Forming a Request or Indication (Bildung einer Anfrage oder Anzeige)​

Für eine Anfrage- oder Anzeigemeldung muss (MUST) der Agent die Attribute USERNAME und MESSAGE-INTEGRITY in der Nachricht einschließen. Der HMAC für das MESSAGE-INTEGRITY-Attribut wird wie in Abschnitt 15.4 beschrieben berechnet. Beachten Sie, dass das Passwort niemals in der Anfrage oder Anzeige enthalten ist.

10.1.2. Receiving a Request or Indication (Empfangen einer Anfrage oder Anzeige)​

Nachdem der Agent die grundlegende Verarbeitung einer Nachricht durchgeführt hat, führt der Agent die unten aufgeführten Prüfungen in der angegebenen Reihenfolge durch:

  • Wenn die Nachricht nicht sowohl ein MESSAGE-INTEGRITY- als auch ein USERNAME-Attribut enthält:

    • Wenn die Nachricht eine Anfrage ist, muss (MUST) der Server die Anfrage mit einer Fehlerantwort ablehnen. Diese Antwort muss (MUST) einen Fehlercode von 400 (Bad Request) verwenden.

    • Wenn die Nachricht eine Anzeige ist, muss (MUST) der Agent die Anzeige stillschweigend verwerfen.

  • Wenn der USERNAME keinen Benutzernamenwert enthält, der derzeit im Server gültig ist:

    • Wenn die Nachricht eine Anfrage ist, muss (MUST) der Server die Anfrage mit einer Fehlerantwort ablehnen. Diese Antwort muss (MUST) einen Fehlercode von 401 (Unauthorized) verwenden.

    • Wenn die Nachricht eine Anzeige ist, muss (MUST) der Agent die Anzeige stillschweigend verwerfen.

  • Unter Verwendung des mit dem Benutzernamen verknüpften Passworts berechnen Sie den Wert für die Nachrichtenintegrität wie in Abschnitt 15.4 beschrieben. Wenn der resultierende Wert nicht mit dem Inhalt des MESSAGE-INTEGRITY-Attributs übereinstimmt:

    • Wenn die Nachricht eine Anfrage ist, muss (MUST) der Server die Anfrage mit einer Fehlerantwort ablehnen. Diese Antwort muss (MUST) einen Fehlercode von 401 (Unauthorized) verwenden.

    • Wenn die Nachricht eine Anzeige ist, muss (MUST) der Agent die Anzeige stillschweigend verwerfen.

Wenn diese Prüfungen bestanden werden, fährt der Agent mit der Verarbeitung der Anfrage oder Anzeige fort. Jede vom Server generierte Antwort muss (MUST) das MESSAGE-INTEGRITY-Attribut enthalten, berechnet unter Verwendung des zur Authentifizierung der Anfrage verwendeten Passworts. Die Antwort darf (MUST NOT) das USERNAME-Attribut enthalten.

Wenn eine der Prüfungen fehlschlägt, darf (MUST NOT) ein Server kein MESSAGE-INTEGRITY- oder USERNAME-Attribut in die Fehlerantwort einschließen. Dies liegt daran, dass der Server in diesen Fehlerfällen das gemeinsame Geheimnis, das zur Berechnung von MESSAGE-INTEGRITY erforderlich ist, nicht bestimmen kann.

10.1.3. Receiving a Response (Empfangen einer Antwort)​

Der Client sucht nach dem MESSAGE-INTEGRITY-Attribut in der Antwort. Falls vorhanden, berechnet der Client die Nachrichtenintegrität über die Antwort wie in Abschnitt 15.4 definiert, unter Verwendung desselben Passworts, das er für die Anfrage verwendet hat. Wenn der resultierende Wert mit dem Inhalt des MESSAGE-INTEGRITY-Attributs übereinstimmt, wird die Antwort als authentifiziert betrachtet. Wenn der Wert nicht übereinstimmt oder wenn MESSAGE-INTEGRITY nicht vorhanden war, muss (MUST) die Antwort verworfen werden, als ob sie nie empfangen worden wäre. Dies bedeutet, dass Wiederübertragungen, falls zutreffend, fortgesetzt werden.

10.2. Long-Term Credential Mechanism (Langzeit-Credential-Mechanismus)​

Der Langzeit-Credential-Mechanismus basiert auf einem langfristigen Credential in Form eines Benutzernamens und Passworts, die zwischen Client und Server geteilt werden. Das Credential wird als langfristig betrachtet, da angenommen wird, dass es für einen Benutzer bereitgestellt wird und gültig bleibt, bis der Benutzer kein Abonnent des Systems mehr ist oder bis es geändert wird. Dies ist im Grunde der traditionelle "Login"-Benutzername und das Passwort, die Benutzern gegeben werden.

Da diese Benutzernamen und Passwörter voraussichtlich über längere Zeiträume gültig sind, wird Replay-Schutz in Form einer Digest-Challenge bereitgestellt. Bei diesem Mechanismus sendet der Client zunächst eine Anfrage, ohne Credentials oder Integritätsprüfungen anzubieten. Der Server lehnt diese Anfrage ab und stellt dem Benutzer einen Bereich (realm, verwendet, um den Benutzer oder Agent bei der Auswahl eines Benutzernamens und Passworts zu leiten) und eine Nonce bereit. Die Nonce bietet Replay-Schutz. Es ist ein Cookie, vom Server ausgewählt und so kodiert, dass es eine Gültigkeitsdauer oder eine Client-Identität angibt, von der es gültig ist. Der Client wiederholt die Anfrage, diesmal einschließlich seines Benutzernamens und Bereichs und Echo der vom Server bereitgestellten Nonce. Der Client schließt auch eine Nachrichtenintegrität ein, die einen HMAC über die gesamte Anfrage, einschließlich der Nonce, bereitstellt. Der Server validiert die Nonce und prüft die Nachrichtenintegrität. Wenn sie übereinstimmen, ist die Anfrage authentifiziert. Wenn die Nonce nicht mehr gültig ist, wird sie als "veraltet" betrachtet, und der Server lehnt die Anfrage ab und stellt eine neue Nonce bereit.

In nachfolgenden Anfragen an denselben Server verwendet der Client die Nonce, den Benutzernamen, den Bereich und das Passwort erneut, die er zuvor verwendet hat. Auf diese Weise werden nachfolgende Anfragen nicht abgelehnt, bis der Server die Nonce ungültig macht, wobei die Ablehnung dem Client eine neue Nonce bereitstellt.

Beachten Sie, dass der Langzeit-Credential-Mechanismus nicht zum Schutz von Anzeigen verwendet werden kann, da Anzeigen nicht herausgefordert werden können. Verwendungen, die Anzeigen verwenden, müssen entweder den Kurzzeit-Credential-Mechanismus verwenden oder die Authentifizierung und Nachrichtenintegrität für sie weglassen.

Da der Langzeit-Credential-Mechanismus anfällig für Offline-Wörterbuchangriffe ist, sollten (SHOULD) Bereitstellungen Passwörter verwenden, die schwer zu erraten sind. In Fällen, in denen das Credential nicht von einem Benutzer eingegeben wird, sondern während der Gerätebereitstellung auf einem Client-Gerät platziert wird, sollte (SHOULD) das Passwort mindestens 128 Bits Zufälligkeit haben. In Fällen, in denen das Credential von einem Benutzer eingegeben wird, sollten (SHOULD) sie den aktuellen Best Practices zur Passwortstruktur folgen.

10.2.1. Forming a Request (Bildung einer Anfrage)​

Es gibt zwei Fälle beim Bilden einer Anfrage. Im ersten Fall ist dies die erste Anfrage vom Client an den Server (identifiziert durch seine IP-Adresse und seinen Port). Im zweiten Fall sendet der Client eine nachfolgende Anfrage nach erfolgreichem Abschluss einer vorherigen Anfrage/Antwort-Transaktion. Das Bilden von Anfragen als Folge einer 401- oder 438-Fehlerantwort wird in Abschnitt 10.2.3 behandelt und gilt nicht als "nachfolgende Anfrage" und verwendet daher nicht die in Abschnitt 10.2.1.2 beschriebenen Regeln.

10.2.1.1. First Request (Erste Anfrage)​

Wenn der Client keine erfolgreiche Anfrage/Antwort-Transaktion mit dem Server abgeschlossen hat (identifiziert durch Hostname, wenn die DNS-Verfahren von Abschnitt 9 verwendet werden, oder durch IP-Adresse, wenn nicht), sollte (SHOULD) er die Attribute USERNAME, MESSAGE-INTEGRITY, REALM und NONCE weglassen. Mit anderen Worten, die allererste Anfrage wird gesendet, als ob keine Authentifizierung oder Nachrichtenintegrität angewendet würde.

10.2.1.2. Subsequent Requests (Nachfolgende Anfragen)​

Sobald eine Anfrage/Antwort-Transaktion erfolgreich abgeschlossen wurde, hat der Server dem Client einen Bereich und eine Nonce bereitgestellt, und der Client hat einen Benutzernamen und ein Passwort ausgewählt, mit denen er sich authentifiziert hat. Der Client sollte (SHOULD) den Benutzernamen, das Passwort, den Bereich und die Nonce für die nachfolgende Kommunikation mit dem Server zwischenspeichern. Wenn der Client eine nachfolgende Anfrage sendet, sollte (SHOULD) er die Attribute USERNAME, REALM und NONCE mit diesen zwischengespeicherten Werten einschließen. Er sollte (SHOULD) das MESSAGE-INTEGRITY-Attribut einschließen, berechnet wie in Abschnitt 15.4 beschrieben unter Verwendung des zwischengespeicherten Passworts.

10.2.2. Receiving a Request (Empfangen einer Anfrage)​

Nachdem der Server die grundlegende Verarbeitung einer Anfrage durchgeführt hat, führt er die unten aufgeführten Prüfungen in der angegebenen Reihenfolge durch:

  • Wenn die Nachricht kein MESSAGE-INTEGRITY-Attribut enthält, muss (MUST) der Server eine Fehlerantwort mit einem Fehlercode von 401 (Unauthorized) generieren. Diese Antwort muss (MUST) einen REALM-Wert enthalten. Es wird empfohlen (RECOMMENDED), dass der REALM-Wert der Domänenname des Anbieters des STUN-Servers ist. Die Antwort muss (MUST) eine vom Server ausgewählte NONCE enthalten. Die Antwort sollte (SHOULD NOT) ein USERNAME- oder MESSAGE-INTEGRITY-Attribut enthalten.

  • Wenn die Nachricht ein MESSAGE-INTEGRITY-Attribut enthält, aber das USERNAME-, REALM- oder NONCE-Attribut fehlt, muss (MUST) der Server eine Fehlerantwort mit einem Fehlercode von 400 (Bad Request) generieren. Diese Antwort sollte (SHOULD NOT) ein USERNAME-, NONCE-, REALM- oder MESSAGE-INTEGRITY-Attribut enthalten.

  • Wenn die NONCE nicht mehr gültig ist, muss (MUST) der Server eine Fehlerantwort mit einem Fehlercode von 438 (Stale Nonce) generieren. Diese Antwort muss (MUST) NONCE- und REALM-Attribute enthalten und sollte (SHOULD NOT) das USERNAME- oder MESSAGE-INTEGRITY-Attribut enthalten. Server können Nonces ungültig machen, um zusätzliche Sicherheit zu bieten. Siehe Abschnitt 4.3 von [RFC2617] für Anleitungen.

  • Wenn der Benutzername im USERNAME-Attribut nicht gültig ist, muss (MUST) der Server eine Fehlerantwort mit einem Fehlercode von 401 (Unauthorized) generieren. Diese Antwort muss (MUST) einen REALM-Wert enthalten. Es wird empfohlen (RECOMMENDED), dass der REALM-Wert der Domänenname des Anbieters des STUN-Servers ist. Die Antwort muss (MUST) eine vom Server ausgewählte NONCE enthalten. Die Antwort sollte (SHOULD NOT) ein USERNAME- oder MESSAGE-INTEGRITY-Attribut enthalten.

  • Unter Verwendung des mit dem Benutzernamen im USERNAME-Attribut verknüpften Passworts berechnen Sie den Wert für die Nachrichtenintegrität wie in Abschnitt 15.4 beschrieben. Wenn der resultierende Wert nicht mit dem Inhalt des MESSAGE-INTEGRITY-Attributs übereinstimmt, muss (MUST) der Server die Anfrage mit einer Fehlerantwort ablehnen. Diese Antwort muss (MUST) einen Fehlercode von 401 (Unauthorized) verwenden. Sie muss (MUST) REALM- und NONCE-Attribute enthalten und sollte (SHOULD NOT) das USERNAME- oder MESSAGE-INTEGRITY-Attribut enthalten.

Wenn diese Prüfungen bestanden werden, fährt der Server mit der Verarbeitung der Anfrage fort. Jede vom Server generierte Antwort (mit Ausnahme der obigen Fälle) muss (MUST) das MESSAGE-INTEGRITY-Attribut enthalten, berechnet unter Verwendung des Benutzernamens und Passworts, die zur Authentifizierung der Anfrage verwendet wurden. Die Attribute REALM, NONCE und USERNAME sollten (SHOULD NOT) eingeschlossen werden.

10.2.3. Receiving a Response (Empfangen einer Antwort)​

Wenn die Antwort eine Fehlerantwort mit einem Fehlercode von 401 (Unauthorized) ist, sollte (SHOULD) der Client die Anfrage mit einer neuen Transaktion wiederholen. Diese Anfrage muss (MUST) einen USERNAME enthalten, der vom Client als der geeignete Benutzername für den REALM aus der Fehlerantwort bestimmt wurde. Die Anfrage muss (MUST) den REALM enthalten, kopiert aus der Fehlerantwort. Die Anfrage muss (MUST) die NONCE enthalten, kopiert aus der Fehlerantwort. Die Anfrage muss (MUST) das MESSAGE-INTEGRITY-Attribut enthalten, berechnet unter Verwendung des mit dem Benutzernamen im USERNAME-Attribut verknüpften Passworts. Der Client darf (MUST NOT) diese Wiederholung durchführen, wenn er den USERNAME oder REALM oder das zugehörige Passwort nicht vom vorherigen Versuch ändert.

Wenn die Antwort eine Fehlerantwort mit einem Fehlercode von 438 (Stale Nonce) ist, muss (MUST) der Client die Anfrage wiederholen, wobei die neue in der 438 (Stale Nonce)-Antwort bereitgestellte NONCE verwendet wird. Diese Wiederholung muss (MUST) auch USERNAME, REALM und MESSAGE-INTEGRITY einschließen.

Der Client sucht nach dem MESSAGE-INTEGRITY-Attribut in der Antwort (Erfolg oder Fehler). Falls vorhanden, berechnet der Client die Nachrichtenintegrität über die Antwort wie in Abschnitt 15.4 definiert, unter Verwendung desselben Passworts, das er für die Anfrage verwendet hat. Wenn der resultierende Wert mit dem Inhalt des MESSAGE-INTEGRITY-Attributs übereinstimmt, wird die Antwort als authentifiziert betrachtet. Wenn der Wert nicht übereinstimmt oder wenn MESSAGE-INTEGRITY nicht vorhanden war, muss (MUST) die Antwort verworfen werden, als ob sie nie empfangen worden wäre. Dies bedeutet, dass Wiederübertragungen, falls zutreffend, fortgesetzt werden.

Letztes Update am