Groupe de travail 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 document enregistre le type de support message/sipfrag d'extension de messagerie Internet multi objets (MIME, Multipurpose Internet Mail Extensions). Ce type est similaire au message/sip, mais permet de représenter certains sous-ensembles de messages bien formés du protocole d'initialisation de session (SIP, Session Initiation Protocol) au lieu de devoir recourir à un message SIP complet. En plus des utilisation de sécurité de bout en bout, le message/sipfrag est utilisé avec la méthode REFER pour convoyer des informations sur le statut d'une demande référencée.

Table des Matières

1. Introduction 1

2. Définition : message/sipfrag 2

3. Exemples 2

3.1 Parties message/sipfrag valides 2

3.2 Parties de message/sipfrag invalides 3

4. Discussion 3

5. Considérations relatives à l'IANA 4

6. Considérations pour la sécurité 4

Références normatives 4

Références non normatives 5

Adresse de l'auteur 5

Déclaration complète de droits de reproduction 5

Le type de support MIME message/sip défini dans la [RFC3261] porte un message SIP bien formé entier. Le paragraphe 23.4 de la [RFC3261] décrit l'utilisation de message/sip de concert avec S/MIME pour améliorer la sécurité de bout en bout. Les concepts de ce paragraphe peuvent être étendus pour permettre aux entités SIP de faire des assertions sur un sous-ensemble d'un message SIP (par exemple, comme décrit dans la [RFC4474]). Le type message/sipfrag défini dans le présent document est utilisé pour représenter ce sous-ensemble.

Un sous-ensemble d'un message SIP est aussi utilisé par la méthode REFER définie dans la [RFC3892] pour porter le statut des demandes référencées. Permettre que seule une portion d'un message SIP soit portée permet que des informations qui pourraient compromettre la vie privée et la confidentialité soient protégées en les retirant.

Le présent document NE FOURNIT PAS de mécanisme permettant de segmenter un message SIP en plusieurs parties pour un transport séparé et un réassemblage ultérieur. Le type message/partial défini dans la [RFC2046] offre une solution à ce problème.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

Une partie message/sipfrag valide est celle qui peut être obtenue en partant d'un message SIP valide et en supprimant un des éléments suivants :

La règle de format Backus-Naur augmenté (ABNF, Augmented Backus-Naur Form) [RFC2234] suivante décrit une partie message/sipfrag en utilisant les éléments de grammaire SIP définis dans la [RFC3261]. L'expansion de tout élément est soumise aux restrictions sur les messages SIP valides qui y sont définis.

Si la partie message/sipfrag contient un corps, il DOIT aussi contenir les champs d'en-tête appropriés qui décrivent ce corps (comme Longueur-de-contenu) comme exigé par le paragraphe 7.4 de la [RFC3261] et la ligne nulle séparant l'en-tête du corps.

Ce paragraphe utilise une barre verticale et une espace à la gauche de chaque exemple pour illustrer l'étendue de l'exemple. Chaque ligne de l'élément message/sipfrag commence au premier caractère après la paire "| ".

Les deux premiers exemples montrent qu'une partie message/sipfrag peut consister seulement en une ligne de début.

Les deux exemple suivants montrent que des sous-ensembles d'un message complet peuvent être représentés.

Une partie message/sipfrag n'a pas à contenir de ligne de début. Cet exemple montre une partie qui pourrait être signée pour faire des assertions sur un message particulier. (Voir [RFC4474].)

Les deux exemples suivants montrent des parties message/sipfrag qui contiennent des corps.

Ce paragraphe utilise le caractère "X" suivi d'une espace à gauche de chaque exemple pour illustrer l'étendue de l'exemple. Chaque ligne de l'élément message/sipfrag invalide commence au premier caractère après la paire "X ".

La ligne de début, si elle est présente, doit être complète et valide selon la [RFC3261].

Si un corps est présent dans la partie message/sipfrag, il DOIT aussi contenir les en-têtes requis par le paragraphe 7.4 de la [RFC3261] et la ligne nulle séparant l'en-tête du corps.

La Section 23 de la [RFC3261], et les mémoires [RFC3892] et [RFC4474] donnent la motivation et des exemples détaillés de transport de tout ou partie d'un message SIP dans une partie MIME. En bref, utiliser cette représentation avec S/MIME permet de protéger et de faire des assertions sur des portions d'un en-tête de message SIP. Cela permet aussi aux applications de décrire l'échange de message impliqué dans une transaction SIP en utilisant des portions des messages eux-mêmes.

La méthode SIP REFER [RFC3892], par exemple, utilise cela pour rapporter le résultat d'une demande SIP à un tiers autorisé. Cependant, comme le précise ce document, il est rarement souhaitable d'inclure le message de réponse SIP entier dans ce rapport comme une partie MIIME message/sip. Le faire a des implications négatives significatives sur la sécurité. D'un autre côté, le type message/sipfrag permet à un envoyeur de choisir les informations qui sont exposées. De plus, il permet d'éluder les informations exigées dans un message SIP complet qui ne sont pas pertinentes pour une description de ce message, réduisant ainsi la taille du message. Par exemple, cela permet à un élément SIP qui répond à un REFER de dire "J'ai un 400 Mauvaise Demande avec ce champ d'en-tête Warning" sans avoir à inclure les champs d'en-tête Via, To, From, Call-ID, CSeq et Content-Length obligatoires dans un message SIP complet.

Le mécanisme de protection de message exposé à la Section 23 de la [RFC3261] suppose qu'un message SIP entier est protégé. Cependant, il y a plusieurs champs d'en-tête dans un message SIP complet qui changent nécessairement durant le transport. La [RFC3261] discute de la façon dont il faut inspecter et ignorer ces changements. Cette idée est précisée dans la [RFC4474] pour permettre la protection d'un sous-ensemble du message entier, évitant le travail supplémentaire et les erreurs potentielles que cela implique en ignorant les parties du message qui peuvent légitimement changer dans le transit. Ce document décrit aussi la construction des assertions cryptographiques sur des sous-ensembles pertinents d'un en-tête de message SIP avant que l'en-tête complet (y compris les informations spécifiques du transport bond par bond) ne soit disponible.

Version : Le numéro de version SIP du message inclus (par exemple, "2.0"). S'il n'est pas présent, la version par défaut est "2.0".

Schéma de codage : Les messages SIP consistent en un en-tête de 8 bits facultativement suivi par un objet de données MIME.À ce titre, les messages SIP doivent être traités comme binaires. Dans des circonstances normales, les messages SIP sont transportés sur des transports à capacité binaire, aucun codage particulier n'est nécessaire.

Une partie MIME message/sipfrag peut contenir des informations sensibles ou des informations utilisées pour affecter des décisions de traitement chez le receveur. Que l'on expose ces informations ou qu'on les modifie durant le transport peut causer des dommages. Son niveau de protection peut être amélioré en utilisant les mécanismes S/MIME décrits à la section 23 de la [RFC3261], avec les limitations décrites à la section 26 de ce document, ainsi que les mécanismes décrits dans la [RFC4474].

Les applications qui utilisent message/sipfrag pour représenter un sous-ensemble des champs d'en-tête provenant d'un message SIP doivent considérer les implications de la capture de la partie message/sipfrag et de sa répétition. Il convient d'y inclure des informations suffisantes pour atténuer le risque. Toute extension SIP qui utilise message/sipfrag DOIT décrire les menaces de répétition et de copié collé particulières à cet utilisation. Par exemple, [RFC4474] expose comment un sous-ensemble de message SIP peut être utilisé pour attester l'identité de l'entité qui fait une demande SIP. Le texte précise quelles informations doivent être contenues dans le sous-ensemble pour lier l'assertion à la demande.

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

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC3892] R. Sparks, "Mécanisme Referred-by du protocole d'initialisation de session (SIP)", septembre 2004.

[RFC4474] J. Peterson et C. Jennings, "Améliorations de la gestion d'identité authentifiée dans le protocole d'initialisation de session (SIP)", août 2006. (P.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 droits de reproduction 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 droits de reproduction définis dans les processus des normes pour l’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éclinent 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.

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

Groupe de travail Réseau	R. Sparks, dynamicsoft
Request for Comments : 3420	novembre 2002
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle