Groupe de travail Réseau	N. Cook, Cloudmark	
Request for Comments: 5593	juin 2009	
RFC mise à jour : 5092		
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Extension d'identifiant d'accès par URL au protocole d'accès au message Internet (IMAP)

Résumé
La spécification existante d'URL IMAP (RFC 5092) mentionne plusieurs identifiants <access> et préfixes d'identifiant <access> qui peuvent être utilisés pour interdire l'accès à des URL générés par URLAUTH. Cependant, ces identifiants ne fournissent pas de facilités pour les nouveaux services comme les flux en direct. Le présent document propose un ensemble de nouveaux identifiants <access> ainsi qu'un mécanisme pour que l'IANA enregistre les nouveaux identifiants <access> pour des futures applications.

Le présent document met à jour la RFC 5092.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Table des matières
1. Introduction	2
2. Conventions utilisées dans le document	2
3. Identifiants d'accès autorisé supplémentaires	2
3.1 Identifiants d'accès existants	2
3.2 Exigence pour des identifiants d'accès supplémentaires	2
3.3 Spécification d'identifiant d'accès supplémentaire	3
3.4 Définition d'un identifiant d'accès pour l'écoulement en direct	3
4. Syntaxe formelle	3
5. Remerciements	4
6. Considérations relatives à l'IANA	4
6.1 Gabarit d'enregistrement d'identifiant d'accès	4
6.2 Enregistrement d'application de flux	4
6.3 Enregistrement d'application Submit	5
6.4 Enregistrement d'application User	5
6.5 Enregistrement d'application Authuser	5
6.6 Enregistrement d'application Anonymous	5
7. Considérations sur la sécurité	5
8. Références	5
8.1 Références normatives	5
8.2 Références pour information	6
Adresse de l'auteur	6

 	1.	Introduction

La spécification d'URL IMAP [RFC5092] donne un moyen pour porter les informations d'autorisation dans les URL IMAP. Plusieurs identifiants d'autorisation <access> sont spécifiées dans le document qui permet aux URL autorisés par URLAUTH d'être utilisés seulement par des utilisateurs anonymes, des utilisateurs authentifiés, ou des entités de soumission de message. Cependant, il n'y a pas de mécanisme défini pour créer de nouveaux identifiants <access>, et surcharger les mécanismes existants a des implications de sécurité ainsi qu'administratives.

Le présent document décrit un nouvel identifiant <access>, "stream", à utiliser par les entités d'écoulement de message (comme décrit dans la [RFC5616]) et définit un gabarit d'enregistrement pour l'IANA, qui peut être utilisé pour enregistrer de nouveaux identifiants <access>pour des futures applications. Les définitions de l'IANA pour les identifiants et préfixes d'accès existants provenant de la RFC 5092 sont aussi définies dans le présent document -- le présent document met à jour la RFC 5092 et devraient être pris comme maître en cas de différences ou discordances.

 	2.	Conventions utilisées dans le document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur,. Si une seule étiquette "C:" ou "S:" s'applique à plusieurs lignes, certaines des coupures de ligne entre ces lignes sont seulement pour la clarté de la présentation et peuvent ne pas faire partie de l'échange réel de protocole.

 	3.	Identifiants d'accès autorisé supplémentaires
 	3.1	Identifiants d'accès existants
La spécification d'URL IMAP [RFC5092] spécifie les identifiants <access> autorisés suivants :

o	"authuser" - indique que l'utilisation de cet URL est limitée à l'authentification des sessions IMAP qui sont enregistrées comme un utilisateur non anonyme.

o	"anonymous" - Indique que l'utilisation de cet URL n'est pas restreinte par l'identité d'autorisation de session.

De plus, les préfixes d'identifiant <access> suivants sont définis dans la [RFC5092] :

o	"submit+" - suivi par un identifiant d'utilisateur (userid) indique que seul un userid autorisé comme entité de soumission de message au nom de l'userid spécifié est autorisé à utiliser cet URL.

o	"user+" - suivi par un userid, indique que l'utilisation de cet URL est limitée aux sessions IMAP qui sont enregistrées comme le userid spécifié.

 	3.2	Exigence pour des identifiants d'accès supplémentaires
Les identifiants <access> existants conviennent pour l'autorisation fondée sur l'utilisateur, mais seul le préfixe d'identifiant <access> "submit+" convient pour les entités qui agissent au nom d'un utilisateur. La prise en charge générique d'entités externes agissant au nom des utilisateurs est exigée pour les nouveaux services comme l'écoulement de flux en direct [RFC5616].

Le préfixe d'identifiant <access> "submit+" ne convient pas comme mécanisme d'utilisation générale pour accorder l'accès aux entités qui agissent au nom des utilisateurs, pour des raisons qui incluent :

o	Sécurité - le serveur IMAP tient une liste des serveurs de soumission qui sont habilités à restituer des URL IMAP en spécifiant le préfixe d'identifiant <access> "submit+". Si cette liste est étendue pour inclure l'ensemble des entités externes qui pourraient agir au nom des utilisateurs, la surface d'attaque en serait augmentée.

o	Administration - quand des URL IMAP de style URLAUTH sont présentés à un serveur IMAP par des entités agissant au nom d'utilisateurs, l'administrateur du serveur n'a pas de moyen de déterminer l'usage prévu de cet URL d'après les enregistrements du serveur.

o	Ressources - avec un mécanisme pour distinguer entre les applications pour lesquelles un URL IMAP va être utilisé, le serveur IMAP n'a pas de moyen de donner de priorité aux ressources pour des applications particulières. Par exemple, le serveur pourrait donner la priorité aux demandes d'aller chercher un URL "submit+" sur d'autres identifiants d'accès.

 	3.3	Spécification d'identifiant d'accès supplémentaire
Le paragraphe précédent établit que des identifiants d'accès supplémentaires sont nécessaires pour prendre en charge des applications comme l'écoulement de flux en direct [RFC5616], qui exigent que les entités restituent les URL URLAUTH au nom des utilisateurs. Ce paragraphe décrit la portée et la signification des tous les identifiants <access> supplémentaires qui sont créés.

Les identifiants <access> supplémentaires DOIVENT prendre une des deux formes (la Section 4 donne la syntaxe ABNF formelle) :

o	identifiant <access> - nom de l'application, par exemple, "exempleapp".

o	préfixe d'identifiant <access> - nom de l'application, par exemple, "exempleapp3", suivi par un "+" et ensuite un userid. Par exemple, voir "exempleapp3+testuser".

Noter qu'un nom d'identifiant <access> peut aussi être enregistré comme un préfixe d'identifiant <access>. Cependant, cela exigerait deux enregistrements IANA distincts.

Dans les deux cas, la sémantique est la même que celle de "submit+", c'est-à-dire, l'identifiant <access> ou le préfixe d'identifiant <access> (qui DOIT être suivi d'un userid) indique que seul un userid autorisé comme entité d'application pour l'application spécifié a la permission d'utiliser cet URL. Dans le cas de préfixes d'identifiant <access>, le serveur IMAP NE DEVRA PAS valider le userid spécifié mais DOIT valider que la session IMAP a une identité d'autorisation qui est autorisée comme entité d'application pour l'application spécifiée.

L'entité d'application elle-même PEUT choisir d'effectuer la validation sur tout userid spécifié avant de tenter de restituer l'URL.

L'autorisation accordée par tout identifiant <access> utilisé comme décrit ci-dessus est auto suffisante, et donc exige que le serveur IMAP fournisse un mécanisme extensible pour associer les userids à de nouvelles applications. Par exemple, imaginons qu'une nouvelle application, "foo", soit créée qui exige que les entités d'application restituent des URL au nom des utilisateurs. Dans ce cas, le serveur IMAP aurait besoin de fournir un moyen d'enregistrer la nouvelle application "foo" et d'associer l'ensemble des userids à utiliser par ces entités à l'application "foo". Toute tentative de restituer les URL contenant l'identifiant d'<access> "foo" seraient confrontées à la liste des userids associés à l'application "foo" pour voir si elle est autorisé.

La Section 6 donne le gabarit exigé pour enregistrer les nouveaux identifiants ou préfixes <access> auprès de l'IANA.

 	3.4	Définition d'un identifiant d'accès pour l'écoulement en direct
Une application qui utilise les URL autorisés pour URLAUTH est celle des fichiers multimédia d'écoulement de flux en direct qui sont reçus comme des pièces jointes de la messagerie Internet. Cette application est décrite dans la [RFC5616].

Voir au paragraphe 6.2 le gabarit d'enregistrement auprès de l'IANA pour l'identifiant d'<access> "stream".

 	4.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation en format Backus-Naur augmenté (ABNF) spécifiée dans la [RFC5234].

Sauf mention contraire, tous le caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des chaînes de jetons est seulement pour la clarté éditoriale. Les mises en œuvre DOIVENT accepter ces chaînes de façon insensible à la casse.

L'ABNF spécifié ci-dessous met à jour la syntaxe formelle des identifiants <access> définie dans l'URL IMAP [RFC5092].

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du code. Tous droits réservés.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

application = 1*(ALPHA/DIGIT)

access =/ application / (application "+" enc-user)

 	5.	Remerciements

Le présent document a été inspiré par des discussions dans le groupe de travail Lemonade.

 	6.	Considérations relatives à l'IANA

L'IANA a créé un nouveau registre pour les identifiants et préfixes d'accès URLAUTH de IMAP.

Les identifiants et préfixes d'accès DOIVENT être enregistrés en utilisant la politique de "revue de l'IETF" [RFC5226]. Cette Section donne les entrées d'enregistrement de l'IANA pour les identifiants et préfixes d'accès existants de la RFC  5092 ainsi que l'entrée pour l'application "stream".

 	6.1	Gabarit d'enregistrement d'identifiant d'accès
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : [soit identifiant "<access>, soit préfixe d'identifiant "<access>"]
Application : [nom de l'application, par exemple, "stream"]
Description : [description de l'application et son utilisation des URL IMAP]
Numéro de RFC : [numéro de la RFC dans laquelle l'application est définie]
Contact : [mél et/ou adresse physique à contacter pour plus d'informations]

 	6.2	Enregistrement d'application de flux
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : identifiant <access>
Application : stream
Description : utilisée par les serveur de supports SIP pour restituer des pièces jointes pour écoulement à des clients de messagerie
Numéro de RFC : RFC 5593
Contact : Neil Cook <neil.cook@noware.co.uk>

 	6.3	Enregistrement d'application Submit
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : préfixe d'identifiant <access>
Application : submit
Description : utilisée par les entités de soumission de messages pour restituer des pièces jointes à inclure dans les messages soumis.
Numéro de RFC : RFC 5593 et RFC 5092
Contact : groupe de travail Lemonade <lemonade@ietf.org>

 	6.4	Enregistrement d'application User
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : préfixe d'identifiant <access>
Application :  user
Description : utilisé pour restreindre l'accès aux sessions IMAP qui sont enregistrées comme dans l'userid spécifié.
Numéro de RFC : RFC 5593 et RFC 5092
Contact : groupe de travail Lemonade <lemonade@ietf.org>

 	6.5	Enregistrement d'application Authuser
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : identifiant <access>
Application : authuser
Description : utilisé pour restreindre l'accès aux sessions IMAP qui sont enregistrées comme tout utilisateur non anonyme de ce serveur IMAP.
Numéro de RFC : RFC 5593 et RFC 5092
Contact : groupe de travail Lemonade <lemonade@ietf.org>

 	6.6	Enregistrement d'application Anonymous
Pour : iana@iana.org
Objet : enregistrement d'identifiant d'accès d'URL IMAP
Type : identifiant <access>
Application : anonymous
Description : Indique que l'utilisation de cet URL n'est pas restreinte par l'identité d'autorisation de session.
Numéro de RFC : RFC 5593 et RFC 5092
Contact : groupe de travail Lemonade <lemonade@ietf.org>

 	7.	Considérations sur la sécurité

L'extension aux identifiants <access> spécifiée dans le présent document fournit un mécanisme pour étendre la sémantique du préfixe <access> "submit+" à des applications arbitraires. L'utilisation de ces identifiants et préfixes <access> supplémentaires est principalement pour des besoins de sécurité, c'est-à-dire, pour empêcher la surcharge de "submit+" comme mécanisme générique pour permettre aux entités de restituer des URL IMAP au nom des userids. À part cela, les implications de sécurité sont identiques à celles discutées au paragraphe 10.1 de IMAPURL [RFC5092].

 	8.	Références
 	8.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC5092]	A. Melnikov et C. Newman, "Schéma d'URL IMAP", novembre 2007. (Remplace RFC2192 ; MàJ RFC4467 ; MàJ par RFC5593) (P.S.)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

 	8.2	Références pour information

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5616]	N. Cook, "Transformation en flux directs des pièces jointes de la messagerie Internet", août 2009. (Information)

 	Adresse de l'auteur

Neil L Cook
Cloudmark
mél : neil.cook@noware.co.uk