6.2 Commandes client - État non authentifié (Client Commands - Not Authenticated State)

Dans l'état non authentifié, la commande AUTHENTICATE ou LOGIN établit l'authentification et entre dans l'état authentifié. La commande AUTHENTICATE fournit un mécanisme général pour une variété de techniques d'authentification, de protection de la vie privée et de vérification de l'intégrité, tandis que la commande LOGIN utilise une paire conventionnelle nom d'utilisateur et mot de passe en texte clair et n'a aucun moyen d'établir une protection de la vie privée ou une vérification de l'intégrité.

La commande STARTTLS est une forme alternative d'établissement de la protection de la vie privée et de la vérification de l'intégrité de la session, mais n'établit pas elle-même l'authentification ni n'entre dans l'état authentifié.

Les implémentations de serveur peuvent (peuvent) permettre l'accès à certaines boîtes aux lettres sans établir l'authentification. Cela peut être fait au moyen de l'authentificateur ANONYMOUS [SASL] décrit dans [ANONYMOUS]. Une convention plus ancienne est une commande LOGIN utilisant le nom d'utilisateur "anonymous" ; dans ce cas, un mot de passe est requis bien que le serveur puisse choisir d'accepter n'importe quel mot de passe. Les restrictions placées sur les utilisateurs anonymes dépendent de l'implémentation.

Une fois authentifié (y compris en tant qu'anonyme), il n'est pas possible de réentrer dans l'état non authentifié.

En plus des commandes universelles (CAPABILITY, NOOP et LOGOUT), les commandes suivantes sont valides dans l'état non authentifié : STARTTLS, AUTHENTICATE et LOGIN. Consultez les Considérations de sécurité (Section 11) pour des informations importantes sur ces commandes.

6.2.1 Commande STARTTLS

Arguments : aucun

Réponses : aucune réponse spécifique pour cette commande

Résultat :

• OK - starttls terminée, commencer la négociation TLS
• NO - la négociation TLS ne peut pas être initiée en raison d'une erreur de configuration du serveur
• BAD - STARTTLS reçu après une négociation TLS réussie ou arguments invalides

Notez que la commande STARTTLS n'est disponible que sur les ports en texte clair. Le serveur doit (doit) toujours répondre avec une réponse BAD étiquetée lorsque la commande STARTTLS est reçue sur un port TLS implicite.

Une négociation TLS [TLS-1.3] commence immédiatement après le CRLF à la fin de la réponse OK étiquetée du serveur. Une fois qu'un client émet une commande STARTTLS, il ne doit pas (ne doit pas) émettre d'autres commandes jusqu'à ce qu'une réponse du serveur soit vue et que la négociation TLS soit terminée. Certaines implémentations de serveur passées ont implémenté incorrectement le traitement STARTTLS et sont connues pour contenir la vulnérabilité d'injection de commande en texte clair STARTTLS [CERT-555316]. Afin d'éviter cette vulnérabilité, les implémentations de serveur doivent (doivent) faire l'une des choses suivantes si des données sont reçues dans le même tampon TCP après le CRLF qui démarre la commande STARTTLS :

1. Les données supplémentaires du tampon TCP sont interprétées comme le début de la négociation TLS. (Si les données sont en texte clair, cela entraînera l'échec de la négociation TLS.)

2. Les données supplémentaires du tampon TCP sont jetées.

Notez que la première option est plus conviviale pour les clients qui mettent en pipeline le début de la commande STARTTLS avec les données de négociation TLS.

Après une négociation TLS réussie, le serveur reste dans l'état non authentifié, même si des informations d'identification du client sont fournies pendant la négociation TLS. Cela n'empêche pas un mécanisme d'authentification tel que EXTERNAL (défini dans [SASL]) d'utiliser l'identité du client déterminée par la négociation TLS.

Une fois que TLS a été démarré, le client doit (doit) supprimer les informations mises en cache sur les capacités du serveur et devrait (devrait) réémettre la commande CAPABILITY. Cela est nécessaire pour se protéger contre les attaques actives qui modifient la liste des capacités avant STARTTLS. Le serveur peut (peut) annoncer différentes capacités et, en particulier, ne devrait pas (ne devrait pas) annoncer la capacité STARTTLS après une commande STARTTLS réussie.

Exemple :

C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<Négociation TLS, les commandes suivantes sont sous couche TLS>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: a004 OK Success (tls protection)

6.2.2 Commande AUTHENTICATE

Arguments :

• Nom du mécanisme d'authentification SASL
• Réponse initiale OPTIONNELLE

Réponses : les données de continuation peuvent être demandées

Résultat :

• OK - authentification terminée, maintenant dans l'état authentifié
• NO - échec de l'authentification : mécanisme d'authentification non pris en charge, informations d'identification rejetées
• BAD - commande inconnue ou arguments invalides, échange d'authentification annulé

La commande AUTHENTICATE indique un mécanisme d'authentification [SASL] au serveur. Si le serveur prend en charge le mécanisme d'authentification demandé, il effectue un échange de protocole d'authentification pour authentifier et identifier le client. Il peut (peut) également négocier une couche de sécurité OPTIONNELLE pour les interactions de protocole ultérieures. Si le mécanisme d'authentification demandé n'est pas pris en charge, le serveur devrait (devrait) rejeter la commande AUTHENTICATE en envoyant une réponse NO étiquetée.

La commande AUTHENTICATE prend en charge la fonctionnalité de "réponse initiale" optionnelle définie dans la Section 4 de [SASL]. Le client n'a pas besoin de l'utiliser. Si un mécanisme SASL prend en charge la "réponse initiale", mais qu'elle n'est pas spécifiée par le client, le serveur la gère comme spécifié dans la Section 3 de [SASL].

Le nom de service spécifié par le profil [SASL] de ce protocole est "imap".

L'échange de protocole d'authentification consiste en une série de défis du serveur et de réponses du client qui sont spécifiques au mécanisme d'authentification. Un défi du serveur consiste en une réponse de demande de continuation de commande avec le jeton "+" suivi d'une chaîne codée en base64 (voir Section 4 de [RFC4648]). La réponse du client consiste en une seule ligne constituée d'une chaîne codée en base64. Si le client souhaite annuler un échange d'authentification, il émet une ligne constituée d'un seul "*". Si le serveur reçoit une telle réponse, ou s'il reçoit une chaîne base64 invalide (par exemple, des caractères en dehors de l'alphabet base64 ou un "=" non terminal), il doit (doit) rejeter la commande AUTHENTICATE en envoyant une réponse BAD étiquetée.

Comme pour toute autre réponse client, la réponse initiale doit (doit) être codée en base64. Elle doit (doit) également être transmise en dehors d'une chaîne entre guillemets ou d'un littéral. Pour envoyer une réponse initiale de longueur nulle, le client doit (doit) envoyer un seul caractère de remplissage ("="). Cela indique que la réponse est présente, mais qu'il s'agit d'une chaîne de longueur nulle.

Lors du décodage des données base64 dans la réponse initiale, les erreurs de décodage doivent (doivent) être traitées comme dans toute réponse client SASL normale, c'est-à-dire avec une réponse BAD étiquetée.

Si le client utilise une réponse initiale avec un mécanisme SASL qui ne prend pas en charge une réponse initiale, le serveur doit (doit) rejeter la commande avec une réponse BAD étiquetée.

Si une couche de sécurité est négociée via l'échange d'authentification [SASL], elle prend effet immédiatement après le CRLF qui conclut l'échange d'authentification pour le client et le CRLF de la réponse OK étiquetée pour le serveur.

Bien que les implémentations client et serveur doivent (doivent) implémenter la commande AUTHENTICATE elle-même, il n'est pas nécessaire d'implémenter des mécanismes d'authentification autres que le mécanisme PLAIN décrit dans [PLAIN]. En outre, un mécanisme d'authentification n'est pas tenu de prendre en charge des couches de sécurité.

Note : une implémentation de serveur doit (doit) implémenter une configuration dans laquelle elle ne permet aucun mécanisme de mot de passe en texte clair, sauf si la commande STARTTLS a été négociée, TLS a été négocié sur un port TLS implicite, ou un autre mécanisme qui protège la session contre l'espionnage de mot de passe a été fourni.

Les serveurs et les clients peuvent prendre en charge plusieurs mécanismes d'authentification. Le serveur devrait (devrait) lister ses mécanismes d'authentification pris en charge dans la réponse à la commande CAPABILITY afin que le client sache quels mécanismes d'authentification utiliser.

Exemple :

S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED] Server ready
C: A01 STARTTLS
S: A01 OK STARTTLS completed
<Négociation TLS, les commandes suivantes sont sous couche TLS>
C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: A02 OK CAPABILITY completed
C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A03 OK Success (tls protection)

6.2.3 Commande LOGIN

Arguments :

• nom d'utilisateur
• mot de passe

Réponses : aucune réponse spécifique pour cette commande

Résultat :

• OK - connexion terminée, maintenant dans l'état authentifié
• NO - échec de connexion : nom d'utilisateur ou mot de passe rejeté
• BAD - commande inconnue ou arguments invalides

La commande LOGIN identifie le client auprès du serveur et transporte le mot de passe en texte clair authentifiant cet utilisateur. La commande LOGIN ne devrait pas (ne devrait pas) être utilisée sauf en dernier recours (après avoir tenté et échoué à s'authentifier en utilisant la commande AUTHENTICATE une ou plusieurs fois), et il est recommandé que les implémentations client aient un moyen de désactiver toute utilisation automatique de la commande LOGIN.

Exemple :

C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed

Note : L'utilisation de la commande LOGIN sur un réseau non sécurisé (tel qu'Internet) présente un risque de sécurité, car toute personne surveillant le trafic réseau peut obtenir des mots de passe en texte clair. Pour cette raison, les clients ne doivent pas (ne doivent pas) utiliser LOGIN sur des réseaux non sécurisés.

---