Groupe de travail Internet |
J. Myers |
Request for comments: 2554 |
Netscape Communications |
Catégorie: Suivi des normes |
Mars 1999 |
Statut de ce Mémo
Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et nécessite des discussions et suggestions pour ses améliorations. Veuillez vous référer à l'édition courante du "Internet Official Protocol Standards" (STD 1) pour pour l'état de normalisation et le statut de ce protocole. La distribution de cette note est illimitée.
Copyright
Copyright (C) The Internet Society (1999). Tous droits réservés.
Ce document définit une extension du service SMTP [ESMTP] grâce à laquelle un client SMTP peut indiquer un mécanisme d'authentification sur le serveur, exécuter un protocole d'authentification pour l'échange des données, et éventuellement négocier une couche de sécurité pour les protocoles d'interactions. Cette extension concerne le niveau simple d'authentification et de sécurité qu'on notera [SASL] (Simple Authentication and Security Layer).
Dans les exemples, "C:" et "S:" indiquent respectivement les lignes envoyées par le client et le serveur. Les mots clés "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", et "PEUT" du présent document doivent être interprétés tel que défini dans "Mots clés à utiliser dans les RFC pour indiquer le niveau d'exigence" [KEYWORDS].
(1) le nom de l'extension du service SMTP est "authentification"
(2) la valeur du mot clé EHLO associée à cette extension est "AUTH"
(3) le mot clé AUTH EHLO contient comme paramètre une liste de noms de mécanismes de SASL supportés, séparés par des espaces.
(4) on définit un nouveau verbe SMTP "AUTH"
(5) un paramètre facultatif utilisant le mot clé "AUTH" est ajouté à la commande MAIL FROM, et étend la longueur maximale de la commande MAIL FROM de 500 caractères.
(6) cette extension est appropriée pour le protocole de soumission [SUBMIT].
AUTH mécanisme [réponse-initiale]
Arguments :
une chaîne pour définir un mécanisme d'authentification SASL une réponse optionnelle encodée base64.
Restrictions :
Après une commande AUTH terminée avec succès, aucune autre commande AUTH ne peut être envoyée dans la même session. Après un succès de la commande AUTH, un serveur DOIT rejeter toute nouvelle commande AUTH avec la réponse 503.
La commande AUTH n'est pas autorisée au cours de l'envoi d'un mail.
Discussion :
La commande AUTH indique un mécanisme d'authentification vers le serveur. Si le serveur supporte le mécanisme d'authentification requis, il effectue un protocole d'authentification de l'échange pour authentifier et identifier l'utilisateur. Accessoirement, il négocie aussi une couche sécurité pour les protocoles d'interactions. Si le mécanisme d'authentification demandé n'est pas pris en charge, le serveur rejette la commande AUTH avec la réponse 504.
Le protocole d'authentification d'échange se compose d'une série défis proposés par le serveur et de réponses du client qui sont spécifiques au mécanisme d'authentification.
Un défit du serveur est une réponse 334 assimilée à une réponse "prêt", avec une partie texte contenant une chaîne codée en BASE64. Le client répond en envoyant une ligne contenant une chaîne codée en BASE64.
Si le client souhaite renoncer à l'authentification de l'échange, il émet une ligne avec un seul "*". Si le serveur reçoit une telle réponse, il DOIT rejeter la commande AUTH, par l'envoi d'une réponse 501.
L'argument de réponse initiale optionnel de la commande AUTH est utilisé pour sauvegarder un aller-retour lors de l'utilisation des mécanismes d'authentification qui sont définis pour n'envoyer aucune donnée dans le premier défit. Lorsque le mécanisme "argument de réponse initiale" est utilisé, le premier défit vide n'est pas envoyé au client et le serveur utilise les données de l'argument de réponse initiale comme s'il était envoyé en réponse au défit vide.
Contrairement à une réponse vide du client suite à la réponse 334 du serveur, une première réponse vide correspond à l'envoi d'un seul signe égale ("="). Si le client utilise l'argument de réponse initiale de la commande AUTH, avec un mécanisme permettant d'envoyer les données du premier défi, le serveur rejette la commande AUTH avec la réponse 535.
Si le serveur ne peut pas décoder l'argument BASE64, il rejette la commande AUTH avec la réponse 501.
Si le serveur rejette les données d'authentification, il DEVRAIT rejeter la commande AUTH avec la réponse 535 à moins qu'un code d'erreur plus spécifique, comme ceux figurant à la section 6, soit approprié. Si le client termine avec succès l'échange d'authentification, le serveur SMTP envoie une réponse 235.
Le nom de service défini par le présent profil de protocole SASL est "smtp".
Si une couche de sécurité est négociée grâce à l'échange d'authentification SASL, elle prend effet immédiatement après le CRLF qui termine l'échange d'authentification pour le client, et le CRLF de la réponse succès du serveur. Lorsqu'une couche de sécurité prend effet, le protocole SMTP est remis à l'état initial (l'état de SMTP après que le serveur ait émit la réponse de service prêt 220).
Le serveur DOIT rejeter toute information obtenue à partir du client, comme l'argument de la commande EHLO, qui n'a pas été obtenu grâce à la négociation SASL elle-même. Le client DOIT rejeter les informations obtenues à partir du serveur, comme la liste des extensions de service SMTP, si elle n'a pas été obtenu de la négociation SASL elle-même (excepté qu'un client PEUT comparer la liste des mécanismes SASL annoncés avant et après l'authentification afin de détecter une activité d'attaque par baisse de la négociation).
Le client DEVRAIT envoyer une commande EHLO comme première commande après le succès de la négociation SASL qui aboutit à la création d'une couche de sécurité.
Le serveur n'est pas obligé de traiter tel ou tel mécanisme d'authentification, ni les mécanismes d'authentification nécessaires pour supporter toute les couches de sécurité. Si une commande AUTH échoue, le client peut essayer un autre mécanisme d'authentification par l'émission d'une autre commande AUTH.
Si une commande AUTH échoue, le serveur DOIT se comporter comme si le client n'avait pas émis la commande AUTH.
Une chaîne BASE64 peut en général être de longueur arbitraire. Les clients et les serveurs DOIVENT être capable de supporter des défis et des réponses qui sont aussi longs que ceux générés par les mécanismes d'authentification qu'ils prennent en charge, indépendamment de toute limitation de la longueur de la ligne que le client ou le serveur peuvent avoir pour la mise en œuvre d'autres parties de leur protocole SMTP.
Exemples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
AUTH=spec-addr
Argument :
La spec-addr contient l'identité de celui qui a soumis le message au système de courrier, ou la séquence de deux caractères "<>" indiquant qu'une telle identité est inconnue ou insuffisamment authentifié. Afin de se conformer aux restrictions imposées sur les paramètres ESMTP, la spec-addr est codé dans un xtext. La syntaxe d'un xtext est décrite à la section 5 de [ESMTP-DSN].
Discussion :
Le paramètre AUTH facultatif de la commande MAIL FROM permet aux agents coopérant dans un climat de confiance favorable de communiquer l'authentification des messages individuels.
Si le serveur fait confiance à l'authentification de l'identité du client qui affirme que le message a été initialement soumis par la spec-addr fourni, alors il DEVRAIT fournir les mêmes spec-addr dans un paramètre AUTH lors du relais du message vers tout serveur qui supporte les extensions AUTH.
Un paramètre AUTH=<> dans la commande MAIL FROM indique que l'expéditeur initial du message n'est pas connu. Le serveur NE DOIT PAS traiter le message comme ayant été envoyé à l'origine par le client.
Si le paramètre AUTH de la commande MAIL FROM n'est pas fourni, le client est authentifié, et le serveur croit que le message est une première communication du client, le serveur PEUT indiquer l'identité du client dans la spec-addr d'un paramètre AUTH lors du relais du message vers n'importe quel serveur qui supporte les extensions AUTH.
Si le serveur ne fait pas suffisamment confiance à l'authentification de l'identité du client, ou si le client n'est pas authentifié, le serveur DOIT se comporter comme si le paramètre AUTH=<> a été fourni. Le serveur PEUT toutefois mémoriser la valeur du paramètre AUTH dans un fichier journal.
Si un paramètre AUTH=<> a été fourni, soit explicitement, soit en raison des contraintes du paragraphe précédent, alors le serveur DOIT fournir le paramètre AUTH=<> lors du relais du message vers tous les serveurs qu'il a authentifié comme utilisant l'extension AUTH.
Un serveur PEUT traiter l'expansion d'une liste de diffusion comme une nouvelle soumission, en initialisant le paramètre AUTH avec l'adresse de la liste ou l'adresse d'administration de la liste, lors du relais du message vers les abonnés de la liste.
Une mise en œuvre codé en dur consistant à traiter tous les clients comme étant insuffisamment fiables est conforme. Dans ce cas, l'application ne fait que rajouter des paramètres AUTH syntaxiquement valides à la commande MAIL FROM et le paramètre AUTH=<> à tout serveurs avec lesquels elle s'authentifie grâce à l'extension AUTH.
Exemples :
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK
Les codes d'erreur suivants peuvent être utilisés pour indiquer les différentes conditions décrites.
432 Un mot de passe est nécessaire pour la transition
Cette réponse à la commande AUTH indique que l'utilisateur en a besoin pour la transition vers le mécanisme d'authentification choisi. C'est typiquement fait une fois en utilisant le mécanisme d'authentification COMPLET.
534 Le mécanisme d'authentification est trop faible
Cette réponse à la commande AUTH indique que le mécanisme d'authentification choisi est plus faible que ce que la politique du serveur autorise pour cet utilisateur.
538 Cryptage requis pour le mécanisme d'authentification demandé
Cette réponse à la commande AUTH indique que le mécanisme d'authentification choisi ne peut être utilisée que lorsque la connexion SMTP sous-jacente est cryptée.
454 Échec d'authentification temporaire
Cette réponse à la commande AUTH indique que l'authentification a échoué en raison d'une panne temporaire du serveur.
530 Authentification nécessaire
Cette réponse peut être renvoyée par tout commande autre que AUTH, EHLO, HELO, NOOP, RSET, ou QUIT. Elle indique que la politique du serveur requiert une authentification afin de pouvoir réaliser l'opération demandée.
La spécification de syntaxe qui suit utilise la notation Backus-Naur Form (BNF) étendue comme spécifié dans [ABNF].
Sauf avis contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des mots-clés sert seulement à la clarté de rédaction. Les implémentations DOIVENT accepter ces chaînes indépendamment de leur casse.
UPALPHA = %x41-5A ;; Majuscules: A-Z
LOALPHA = %x61-7A ;; Minuscules: a-z
ALPHA = UPALPHA / LOALPHA ;; Insensible à la casse
DIGIT = %x30-39 ;; Chiffre 0-9
HEXDIGIT = %x41-46 / DIGIT ;; Caractère hexadécimal (majuscules)
hexchar = "+" HEXDIGIT HEXDIGIT
xchar = %x21-2A / %x2C-3C / %x3E-7E
;; US-ASCII sauf pour les "+", "=", SPACE et CTL
xtext = *(xchar / hexchar)
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
auth_type = 1*20AUTH_CHAR
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64]) CRLF
auth_param = "AUTH=" xtext
;; La forme décodée du xtext DOIT être soit
;; une spec-addr soit les deux caractères "<>"
base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Sensible à la casse
base64_terminal = (2base64_char "==") / (3base64_char "=")
continue_req = "334" SPACE [base64] CRLF
CR = %x0C ;; Caractère ASCII CR : retour chariot
CRLF = CR LF
CTL = %x00-1F / %x7F ;; n'importe quel caractère de contrôle
;; ASCII et caractère DEL
LF = %x0A ;; Caractère ASCII LF : saut de ligne
SPACE = %x20 ;; Caractère ASCII SP : espace
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Novembre 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, Septembre 1997.
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, Novembre 1995.
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, Janvier 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Mars 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, Octobre 1997.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, Décembre 1998.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, Août 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, Août 1982.
Les problèmes de sécurité sont décrits dans ce mémo.
Si un client utilise cette extension pour obtenir un tunnel chiffré à travers un réseau non sécurisé vers un serveur coopérant, il doit être configuré de manière à ne jamais envoyer de mail à ce serveur lorsque la connexion n'est pas authentifiée et chiffrée des deux cotés. Sinon, un attaquant pourrait tromper le client de messagerie par le détournement d'une connexion SMTP ou également en prétendant que le serveur ne supporte pas l'extension authentification, ou en causant l'échec de toutes les commandes AUTH.
Avant que la négociation SASL ait commencé, toutes les interactions du protocole sont effectuées en clair et peuvent être modifiées par un attaquant actif. Pour cette raison, les clients et les serveurs DOIVENT rejeter les informations acquises avant le début de la négociation SASL, à l'issue d'une négociation SASL qui se traduit par une couche de sécurité.
Ce mécanisme ne protège pas le port TCP, ainsi un attaquant actif peut rediriger une tentative de connexion relais au port de soumission [SUBMIT]. Le paramètre AUTH=<> évite une telle attaque d'un message relayé sans une enveloppe d'authentification pour récupérer l'authentification du relais du client.
Un message de présentation du client peut exiger que l'utilisateur s'authentifie à chaque fois qu'un mécanisme SASL est précisé. Toutefois, il peut ne pas être souhaitable pour un serveur de soumission [SUBMIT] de mentionner un mécanisme SASL, lorsque l'utilisation de ce mécanisme n'apporte pas au client de bénéfice par rapport aux soumissions plus anonymes.
Cette extension n'est pas supposée remplacer la signature de message bout en bout et les systèmes de chiffrement comme S/MIME ou PGP. Cette extension répond à un problème différent que celui des systèmes de bout en bout; elle comporte des différences majeures :
(1) il n'est généralement utile qu'au sein d'une enclave de confiance
(2) il protège l'ensemble de l'enveloppe d'un message, et non pas seulement le corps du message.
(3) il authentifie le message de présentation, pas la paternité du contenu du message
(4) il peut donner à l'expéditeur une certaine garantie que le message a été délivré au prochain tronçon, dans le cas où l'expéditeur et le prochain tronçon s'authentifient mutuellement et négocient une couche de sécurité appropriée.
Des considérations de sécurité supplémentaires sont mentionnées dans la spécification [SASL].
John Gardiner Myers
Netscape Communications
501 East Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043
Email: jgmyers@netscape.com
Traduction :
Bernard Chardonneau
1 rue Dauvillier
91290 ARPAJON (FRANCE)
Contact : bechforum @ free . fr (en supprimant les espaces)
Copyright (C) The Internet Society (1999). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.