Groupe de travailo Réseau

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent mémoire propose deux codes de réponse : SYS et AUTH, qui permettent aux clients de déterminer sans ambiguïté une réponse optimale à un échec d’authentification. De plus, une nouvelle capacité (AUTH-RESP-CODE) est définie.

Table des Matières

1. Introduction 1

2. Conventions utilisées dans le document 1

3. Fondements 1

4. Code de réponse SYS 2

5. Code de réponse AUTH 2

6. Capacité AUTH-RESP-CODE 2

7. Considérations relatives à l’IANA 3

8. Considérations sur la sécurité 3

9. Références 3

10. Adresse de l’auteur 3

11. Déclaration complète de droits de reproduction 3

La [RFC2449] définissait des codes de réponse étendus [RFC1939], pour donner aux clients plus d’informations sur les erreurs afin qu’ils puissent répondre de façon plus appropriée. En plus de ce mécanisme, deux codes de réponse initiaux étaient définis (IN-USE et LOGIN-DELAY) pour tenter de différencier les échecs d’authentification en rapport avec les accréditifs de l’utilisateur, et les autres erreurs.

En pratique, ces deux codes de réponse, bien qu’utiles, ne vont pas assez loin. Le présent mémoire propose deux codes de réponse supplémentaires : SYS et AUTH, qui permettent aux clients de déterminer sans ambiguïté une réponse optimale à un échec d’authentification.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

La [RFC2449] introduisait les codes de réponse IN-USE et LOGIN-DELAY. Leur intention est de permettre aux clients de déterminer clairement la cause sous-jacente d’une défaillance afin de répondre. Par exemple, les clients ont besoin de savoir si on devrait demander de nouveaux accréditifs à l’usager, ou si la session POP3 devrait simplement être réessayée plus tard. (Certain clients POP3 déployés tentent d’analyser le texte des erreurs d’échec d’authentification, à la recherche de chaînes connues pour être produites par divers serveurs qui indiquent que la boîte aux lettres est verrouillée.)

IN-USE indique qu’un verrouillage exclusif ne peut pas être obtenu pour la boîte aux lettres de l’utilisateur, probablement parce qu’une autre session POP3 est en cours. LOGIN-DELAY informe le client que l’usager n’a pas attendu assez longtemps avant de recommencer l’authentification.

Cependant, il y a d’autres conditions d’erreur qui n’exigent pas de nouveaux accréditifs, dont certains devraient être portés à l’attention de l’utilisateur.

En dépit des réponses IN-USE et LOGIN-DELAY, les clients ne peuvent pas être sûrs qu’une autre erreur n’exige de nouveaux accréditifs de l’utilisateur.

Le code de réponse SYS annonce qu’un échec est dû à une erreur du système, par opposition aux accréditifs de l’usager ou à une condition externe. Il est hiérarchique, avec deux codes possibles de second niveau : TEMP et PERM. (La casse n’est significative à aucun niveau de la hiérarchie.)

SYS/TEMP indique un problème qui est probablement de nature temporaire, et qu’il n’y a donc pas lieu d’alarmer l’usager, sauf si la défaillance persiste. On peut citer comme exemples une ressource centrale qui serait actuellement verrouillée ou temporairement indisponible, un espace de disque ou de mémoire insuffisant, etc.

SYS/PERM est utilisé pour des problèmes qui ont peu de chances d’être résolus sans intervention. Il est approprié d’alerter l’utilisateur et de suggérer que le personnel de soutien ou d’assistance de l’organisation soit contacté. On peut citer comme exemples une boîte aux lettres endommagée, des erreurs de configuration du système, etc.

Le code de réponse AUTH informe le client qu’il y a un problème avec les accréditifs de l’usager. Cela peut être un mot de passe incorrect, un nom d’utilisateur inconnu, un compte arrivé à expiration, une tentative d’authentification en violation d’une politique (comme une localisation invalide ou durant une période non autorisée) ou quelque autre problème.

Le code de réponse AUTH est valide avec une réponse -ERR à toute commande d’authentification, y compris AUTH, USER (voir la note) PASS, ou APOP.

Les serveurs qui incluent le code de réponse AUTH avec un échec d’authentification DEVRAIENT prendre en charge la commande CAPA [RFC2449] et DEVRAIENT inclure la capacité AUTH-RESP-CODE dans la réponse CAPA. AUTH-RESP-CODE assure au client que seules des erreurs ayant le code AUTH sont causées par des problèmes d’accréditifs.

Note : Retourner le code de réponse AUTH à la commande USER révèle au client que l’usager spécifié existe. Il est fortement RECOMMANDÉ que le serveur ne produise pas ce code de réponse à la commande USER.

Discussion : la capacité AUTH-RESP-CODE indique que le serveur inclut le code de réponse AUTH avec toute erreur d’authentification causée par un problème avec les accréditifs de l’utilisateur.

L’IANA a ajouté la capacité AUTH-RESP-CODE à la liste des capacités de POP3 (établie par la [RFC2449]).

L’IANA a aussi ajouté les codes de réponse SYS et AUTH à la liste des codes de réponse POP3 (aussi établie par la [RFC2449]).

La Section 5 “Code de réponse AUTH” discute des questions de sécurité en rapport avec l’utilisation du code de réponse AUTH avec la commande USER.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2449] R. Gellens, C. Newman, L. Lundblade, "Mécanisme d'extension de POP3", novembre 1998. (MàJ par RFC5034) (P.S.)

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travailo Réseau	R. Gellens, QUALCOMM
Request for Comments : 3206	février 2002
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle