Zum Hauptinhalt springen

3. Digest-Zugriffs-Authentifizierungsschema (Digest Access Authentication Scheme)

3.1 Einführung (Introduction)​

3.1.1 Zweck (Purpose)​

Das als „HTTP/1.0" bezeichnete Protokoll enthält die Spezifikation für ein Basis-Zugriffs-Authentifizierungsschema (Basic Access Authentication Scheme) [1]. Dieses Schema wird nicht als sichere Methode zur Benutzerauthentifizierung angesehen, da der Benutzername und das Passwort in unverschlüsselter Form über das Netzwerk übertragen werden. Dieser Abschnitt bietet die Spezifikation für ein Schema, das das Passwort nicht im Klartext sendet, sondern stattdessen eine Prüfsummentechnik verwendet, die als „Digest-Zugriffs-Authentifizierung" (Digest Access Authentication) bezeichnet wird.

Das Digest-Zugriffs-Authentifizierungsschema ist nicht als vollständige Antwort auf den Sicherheitsbedarf im World Wide Web gedacht. Dieses Schema bietet keine Verschlüsselung des Nachrichteninhalts. Die Absicht besteht lediglich darin, eine Zugriffs-Authentifizierungsmethode zu schaffen, die die schwerwiegendsten Mängel der Basis-Authentifizierung vermeidet.

3.1.2 Gesamtbetrieb (Overall Operation)​

Wie die Basis-Zugriffs-Authentifizierung (Basic Access Authentication) basiert das Digest-Schema auf einem einfachen Challenge-Response-Paradigma (Challenge-Response Paradigm). Das Digest-Schema fordert mit einem Nonce-Wert heraus. Eine gültige Antwort enthält eine Prüfsumme (standardmäßig die MD5-Prüfsumme) des Benutzernamens, des Passworts, des gegebenen Nonce-Werts, der HTTP-Methode und des angeforderten URI. Auf diese Weise wird das Passwort niemals im Klartext gesendet. Wie beim Basis-Schema müssen Benutzername und Passwort auf irgendeine Weise vorab vereinbart werden, die in diesem Dokument nicht behandelt wird.

3.1.3 Darstellung von Digest-Werten (Representation of digest values)​

Ein optionaler Header ermöglicht es dem Server, den Algorithmus anzugeben, der zum Erstellen der Prüfsumme oder des Digest verwendet wird. Standardmäßig wird der MD5-Algorithmus verwendet, und dies ist der einzige in diesem Dokument beschriebene Algorithmus.

Für die Zwecke dieses Dokuments wird ein MD5-Digest von 128 Bit als 32 ASCII-druckbare Zeichen dargestellt. Die Bits des 128-Bit-Digest werden vom höchstwertigen zum niedrigstwertigen Bit, jeweils vier Bits auf einmal, wie folgt in ihre ASCII-Darstellung umgewandelt. Jede Vierergruppe von Bits wird durch ihre vertraute Hexadezimalnotation aus den Zeichen 0123456789abcdef dargestellt. Das heißt, binär 0000 wird durch das Zeichen '0' dargestellt, 0001 durch '1', und so weiter bis zur Darstellung von 1111 als 'f'.

3.1.4 Einschränkungen (Limitations)​

Das in diesem Dokument beschriebene Digest-Authentifizierungsschema leidet unter vielen bekannten Einschränkungen. Es ist als Ersatz für die Basis-Authentifizierung gedacht und nichts mehr. Es ist ein passwortbasiertes System und leidet (auf der Serverseite) unter allen gleichen Problemen wie jedes Passwortsystem. Insbesondere ist in diesem Protokoll keine Vorkehrung für die anfängliche sichere Vereinbarung zwischen Benutzer und Server zur Festlegung des Benutzerpassworts getroffen.

Benutzer und Implementierer sollten sich bewusst sein, dass dieses Protokoll nicht so sicher wie Kerberos ist und nicht so sicher wie ein clientseitiges Schema mit privatem Schlüssel. Dennoch ist es besser als nichts, besser als das, was üblicherweise mit Telnet und FTP verwendet wird, und besser als die Basis-Authentifizierung.

3.2 Spezifikation der Digest-Header (Specification of Digest Headers)​

Das Digest-Zugriffs-Authentifizierungsschema ist konzeptionell dem Basis-Schema ähnlich. Die Formate für die modifizierte WWW-Authenticate-Header-Zeile und die Authorization-Header-Zeile sind unten spezifiziert. Zusätzlich wird auch ein neuer Header, Authentication-Info, spezifiziert.

3.2.1 Der WWW-Authenticate-Response-Header (The WWW-Authenticate Response Header)​

Wenn ein Server eine Anfrage für ein zugriffsgeschütztes Objekt erhält und kein akzeptabler Authorization-Header gesendet wird, antwortet der Server mit einem „401 Unauthorized"-Statuscode und einem WWW-Authenticate-Header gemäß dem oben definierten Framework, das für das Digest-Schema wie folgt verwendet wird:

challenge        =  "Digest" digest-challenge

digest-challenge  = 1#( realm | [ domain ] | nonce |
                    [ opaque ] |[ stale ] | [ algorithm ] |
                    [ qop-options ] | [auth-param] )

domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
URI               = absoluteURI | abs_path
nonce             = "nonce" "=" nonce-value
nonce-value       = quoted-string
opaque            = "opaque" "=" quoted-string
stale             = "stale" "=" ( "true" | "false" )
algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
qop-options       = "qop" "=" <"> 1#qop-value <">
qop-value         = "auth" | "auth-int" | token

Die Bedeutungen der Werte der oben verwendeten Direktiven sind wie folgt:

realm (Bereich)

  • Eine Zeichenkette, die den Benutzern angezeigt wird, damit sie wissen, welchen Benutzernamen und welches Passwort sie verwenden sollen. Diese Zeichenkette sollte mindestens den Namen des Hosts enthalten, der die Authentifizierung durchführt.

domain (Domäne)

  • Eine durch Anführungszeichen eingeschlossene, durch Leerzeichen getrennte Liste von URIs, die den Schutzbereich (Protection Space) definieren.

nonce

  • Eine vom Server spezifizierte Datenzeichenkette, die jedes Mal, wenn eine 401-Antwort erstellt wird, eindeutig generiert werden sollte. Es wird empfohlen, dass diese Zeichenkette Base64- oder Hexadezimaldaten ist.

opaque

  • Eine vom Server spezifizierte Datenzeichenkette, die vom Client unverändert im Authorization-Header nachfolgender Anfragen mit URIs im selben Schutzbereich zurückgegeben werden sollte.

stale (veraltet)

  • Ein Flag, das anzeigt, dass die vorherige Anfrage des Clients abgelehnt wurde, weil der Nonce-Wert veraltet war. Wenn stale TRUE ist (Groß-/Kleinschreibung wird nicht beachtet), kann der Client einfach die Anfrage mit einer neuen verschlüsselten Antwort wiederholen, ohne den Benutzer erneut nach einem neuen Benutzernamen und Passwort zu fragen.

algorithm (Algorithmus)

  • Eine Zeichenkette, die ein Paar von Algorithmen angibt, die zum Erzeugen des Digest und einer Prüfsumme verwendet werden. Wenn dies nicht vorhanden ist, wird „MD5" angenommen.

qop-options (Schutzqualitätsoptionen)

  • Diese Direktive ist optional, aber nur aus Gründen der Rückwärtskompatibilität mit RFC 2069 [6]; sie sollte von allen Implementierungen verwendet werden, die mit dieser Version des Digest-Schemas konform sind.

3.2.2 Der Authorization-Request-Header (The Authorization Request Header)​

Es wird erwartet, dass der Client die Anfrage wiederholt und eine Authorization-Header-Zeile mit der wie unten angegeben berechneten Response-Direktive übergibt.

credentials      = "Digest" digest-response
digest-response  = 1#( username | realm | nonce | digest-uri
                   | response | [ algorithm ] | [cnonce] |
                   [opaque] | [message-qop] |
                   [nonce-count]  | [auth-param] )

username         = "username" "=" username-value
username-value   = quoted-string
digest-uri       = "uri" "=" digest-uri-value
digest-uri-value = request-uri
message-qop      = "qop" "=" qop-value
cnonce           = "cnonce" "=" cnonce-value
cnonce-value     = nonce-value
nonce-count      = "nc" "=" nc-value
nc-value         = 8LHEX
response         = "response" "=" request-digest
request-digest   = <"> 32LHEX <">
LHEX             = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                   "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"

3.2.3 Der Authentication-Info-Header (The Authentication-Info Header)​

Das Authentication-Info-Header-Feld kann vom Server in einer Antwort verwendet werden, um Informationen über die erfolgreiche Authentifizierung zu übertragen. Dieser Header ist besonders nützlich bei der „auth-int"-Schutzqualität.

AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info          = 1#(nextnonce | [ message-qop ]
                     | [ response-auth ] | [ cnonce ]
                     | [nonce-count] )
nextnonce          = "nextnonce" "=" nonce-value
response-auth      = "rspauth" "=" response-digest
response-digest    = <"> *LHEX <">

3.3 Digest-Betrieb (Digest Operation)​

Der Betrieb der Digest-Zugriffs-Authentifizierung ist wie folgt. Der Client stellt eine Anfrage an den Server, der mit einer 401-Antwort herausfordert und einen Nonce und andere Parameter bereitstellt. Der Client verwendet diese Parameter, um den Response-Wert zu berechnen und sendet ihn zusammen mit anderen Informationen in einer nachfolgenden Anfrage an den Server. Der Server überprüft den Response-Wert und gewährt bei Richtigkeit den Zugriff.

3.4 Sicherheitsprotokoll-Verhandlung (Security Protocol Negotiation)​

Ein Server kann mehrere Challenges im WWW-Authenticate-Header bereitstellen, von denen jede ein anderes Authentifizierungsschema verwendet. Der Client sollte das stärkste Schema auswählen, das er unterstützt.

3.5 Beispiel (Example)​

Das folgende Beispiel geht davon aus, dass der Zugriff auf das geschützte Dokument eine Authentifizierung erfordert. Der Server fordert mit einer 401-Antwort heraus:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    realm="[email protected]",
    qop="auth,auth-int",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

Der Client kann mit dem folgenden Authorization-Header antworten:

Authorization: Digest username="Mufasa",
    realm="[email protected]",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    uri="/dir/index.html",
    qop=auth,
    nc=00000001,
    cnonce="0a4f113b",
    response="6629fae49393a05397450978507c4ef1",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

3.6 Proxy-Authentication und Proxy-Authorization​

Proxy-Authentifizierung und -Autorisierung funktionieren ähnlich wie Origin-Server-Authentifizierung und -Autorisierung, verwenden jedoch die Proxy-Authenticate- und Proxy-Authorization-Header-Felder. Der Proxy muss bei der Handhabung der Authentifizierung zwischen Client und Origin-Server vollständig transparent sein.

Letztes Update am