3. Schéma d'authentification d'accès par condensé (Digest Access Authentication Scheme)
3.1 Introduction
3.1.1 Objectif (Purpose)
Le protocole appelé « HTTP/1.0 » comprend la spécification d'un schéma d'authentification d'accès de base (Basic Access Authentication Scheme) [1]. Ce schéma n'est pas considéré comme une méthode sécurisée d'authentification des utilisateurs, car le nom d'utilisateur et le mot de passe sont transmis sur le réseau sous forme non chiffrée. Cette section fournit la spécification d'un schéma qui n'envoie pas le mot de passe en texte clair, mais utilise plutôt une technique de somme de contrôle, appelée « Authentification d'accès par condensé » (Digest Access Authentication).
Le schéma d'authentification d'accès par condensé n'est pas destiné à être une réponse complète au besoin de sécurité sur le World Wide Web. Ce schéma ne fournit pas de chiffrement du contenu des messages. L'intention est simplement de créer une méthode d'authentification d'accès qui évite les défauts les plus graves de l'authentification de base.
3.1.2 Fonctionnement général (Overall Operation)
Comme l'authentification d'accès de base (Basic Access Authentication), le schéma par condensé est basé sur un paradigme défi-réponse simple (Challenge-Response Paradigm). Le schéma par condensé défie en utilisant une valeur nonce. Une réponse valide contient une somme de contrôle (par défaut, la somme de contrôle MD5) du nom d'utilisateur, du mot de passe, de la valeur nonce donnée, de la méthode HTTP et de l'URI demandé. De cette façon, le mot de passe n'est jamais envoyé en clair. Comme avec le schéma de base, le nom d'utilisateur et le mot de passe doivent être préalablement arrangés d'une manière non traitée par ce document.
3.1.3 Représentation des valeurs de condensé (Representation of digest values)
Un en-tête optionnel permet au serveur de spécifier l'algorithme utilisé pour créer la somme de contrôle ou le condensé. Par défaut, l'algorithme MD5 est utilisé et c'est le seul algorithme décrit dans ce document.
Aux fins de ce document, un condensé MD5 de 128 bits est représenté par 32 caractères ASCII imprimables. Les bits du condensé de 128 bits sont convertis du bit le plus significatif au bit le moins significatif, quatre bits à la fois, en leur représentation ASCII comme suit. Chaque groupe de quatre bits est représenté par sa notation hexadécimale familière à partir des caractères 0123456789abcdef. C'est-à-dire que le binaire 0000 est représenté par le caractère '0', 0001 par '1', et ainsi de suite jusqu'à la représentation de 1111 par 'f'.
3.1.4 Limitations
Le schéma d'authentification par condensé décrit dans ce document souffre de nombreuses limitations connues. Il est destiné à remplacer l'authentification de base et rien de plus. C'est un système basé sur les mots de passe et (côté serveur) il souffre de tous les mêmes problèmes que tout système de mots de passe. En particulier, aucune disposition n'est prévue dans ce protocole pour l'arrangement initial sécurisé entre l'utilisateur et le serveur pour établir le mot de passe de l'utilisateur.
Les utilisateurs et les implémenteurs doivent être conscients que ce protocole n'est pas aussi sécurisé que Kerberos et n'est pas aussi sécurisé qu'un schéma côté client à clé privée. Néanmoins, il est meilleur que rien, meilleur que ce qui est couramment utilisé avec telnet et ftp, et meilleur que l'authentification de base.
3.2 Spécification des en-têtes de condensé (Specification of Digest Headers)
Le schéma d'authentification d'accès par condensé est conceptuellement similaire au schéma de base. Les formats pour la ligne d'en-tête WWW-Authenticate modifiée et la ligne d'en-tête Authorization sont spécifiés ci-dessous. De plus, un nouvel en-tête, Authentication-Info, est également spécifié.
3.2.1 L'en-tête de réponse WWW-Authenticate (The WWW-Authenticate Response Header)
Si un serveur reçoit une requête pour un objet protégé par accès et qu'un en-tête Authorization acceptable n'est pas envoyé, le serveur répond avec un code de statut « 401 Unauthorized » et un en-tête WWW-Authenticate selon le cadre défini ci-dessus, qui pour le schéma par condensé est utilisé comme suit :
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
Les significations des valeurs des directives utilisées ci-dessus sont les suivantes :
realm (domaine)
- Une chaîne à afficher aux utilisateurs afin qu'ils sachent quel nom d'utilisateur et mot de passe utiliser. Cette chaîne devrait contenir au moins le nom de l'hôte effectuant l'authentification et pourrait également indiquer la collection d'utilisateurs qui pourraient avoir accès.
domain (domaine)
- Une liste d'URI séparés par des espaces et entre guillemets qui définissent l'espace de protection (Protection Space). Si un URI est un abs_path, il est relatif à l'URL racine canonique du serveur accédé.
nonce
- Une chaîne de données spécifiée par le serveur qui devrait être générée de manière unique chaque fois qu'une réponse 401 est émise. Il est recommandé que cette chaîne soit des données base64 ou hexadécimales.
opaque
- Une chaîne de données, spécifiée par le serveur, qui devrait être renvoyée par le client sans modification dans l'en-tête Authorization des requêtes ultérieures avec des URI dans le même espace de protection.
stale (périmé)
- Un drapeau indiquant que la requête précédente du client a été rejetée car la valeur nonce était périmée. Si stale est TRUE (insensible à la casse), le client peut souhaiter simplement réessayer la requête avec une nouvelle réponse chiffrée, sans redemander à l'utilisateur un nouveau nom d'utilisateur et mot de passe.
algorithm (algorithme)
- Une chaîne indiquant une paire d'algorithmes utilisés pour produire le condensé et une somme de contrôle. Si ceci n'est pas présent, il est supposé être « MD5 ».
qop-options (options de qualité de protection)
- Cette directive est optionnelle, mais elle l'est uniquement pour la compatibilité ascendante avec RFC 2069 [6] ; elle devrait être utilisée par toutes les implémentations conformes à cette version du schéma par condensé. Si présente, c'est une chaîne entre guillemets d'un ou plusieurs jetons indiquant les valeurs de « qualité de protection » supportées par le serveur.
3.2.2 L'en-tête de requête Authorization (The Authorization Request Header)
Le client est censé réessayer la requête en passant une ligne d'en-tête Authorization avec la directive response calculée comme spécifié ci-dessous.
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 L'en-tête Authentication-Info (The Authentication-Info Header)
Le champ d'en-tête Authentication-Info peut être utilisé par le serveur dans une réponse pour transmettre des informations sur l'authentification réussie. Cet en-tête est particulièrement utile avec la qualité de protection « auth-int ».
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 Fonctionnement du condensé (Digest Operation)
Le fonctionnement de l'authentification d'accès par condensé est le suivant. Le client fait une requête au serveur, qui défie avec une réponse 401 fournissant un nonce et d'autres paramètres. Le client utilise ces paramètres pour calculer la valeur de réponse et l'envoie avec d'autres informations dans une requête ultérieure au serveur. Le serveur vérifie la valeur de réponse et, si elle est correcte, accorde l'accès.
3.4 Négociation du protocole de sécurité (Security Protocol Negotiation)
Un serveur peut fournir plusieurs défis dans l'en-tête WWW-Authenticate, chacun utilisant un schéma d'authentification différent. Le client devrait sélectionner le schéma le plus fort qu'il supporte.
3.5 Exemple (Example)
L'exemple suivant suppose que l'accès au document protégé nécessite une authentification. Le serveur défie avec une réponse 401 :
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Le client peut répondre avec l'en-tête Authorization suivant :
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 et Proxy-Authorization
L'authentification et l'autorisation par proxy fonctionnent de manière similaire à l'authentification et à l'autorisation du serveur d'origine, mais utilisent les champs d'en-tête Proxy-Authenticate et Proxy-Authorization. Le proxy doit être complètement transparent dans la gestion de l'authentification entre le client et le serveur d'origine.