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 |
Type de support Internet message/sipfrag
Statut de ce mémoire
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.
Notice de copyright
Copyright (C) The Internet Society (2002). Tous droits réservés.
Résumé
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
2. Définition : message/sipfrag
3.1 Parties message/sipfrag valides
3.2 Parties message/sipfrag invalides
5. Considérations relatives à l'IANA
6. Considérations pour la sécurité
Déclaration complète de droits de reproduction
Le type de support MIME message/sip défini dans [1] porte un message SIP bien formé entier. Le paragraphe 23.4 de [1] 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 [6]). 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 en [5] pour porter le statut des demandes référencées. Permettre de ne porter qu'une portion d'un message SIP permet de protéger des informations qui pourraient compromettre la confidentialité 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 en [2] 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 en [4].
2. Définition : message/sipfrag
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 :
o la ligne de début entière
o un ou plusieurs champs d'en-tête entiers
o le corps du message
La règle de forme Backus-Naur augmentée (ABNF, Augmented Backus-Naur Form) [3] suivante décrit une partie message/sipfrag en utilisant les éléments de grammaire SIP définis dans [1]. L'expansion de tout élément est soumise aux restrictions sur les messages SIP valides qui y sont définis.
sipfrag = [ start-line ]
*en-tête de message
[ CRLF [ corps-de-message ] ]
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 [1] et la ligne nulle séparant l'en-tête du corps.
3.1 Parties message/sipfrag valides
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.
| INVITE sip:alice@atlanta.com SIP/2.0
ou
| SIP/2.0 603 Declined
Les deux exemple suivants montrent que des sous-ensembles d'un message complet peuvent être représentés.
| REGISTER sip:atlanta.com SIP/2.0
| To: sip:alice@atlanta.com
| Contact: <sip:alicepc@atlanta.com>;q=0.9,
| <sip:alicemobile@atlanta.com>;q=0.1
| SIP/2.0 400 Bad Request
| Warning: 399 atlanta.com Ton champ d'en-tête Event était mal formé
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 [6].)
| From: Alice <sip:alice@atlanta.com>
| To: Bob <sip:bob@biloxi.com>
| Contact: <sip:alice@pc33.atlanta.com>
| Date: Thu, 21 Feb 2002 13:02:03 GMT
| Call-ID: a84b4c76e66710
| Cseq: 314159 INVITE
Les deux exemples suivants montrent des parties message/sipfrag qui contiennent des corps.
| SIP/2.0 200 OK
| Content-Type: application/sdp
| Content-Length: 247
|
| v=0
| o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
| s=
| c=IN IP4 host.anywhere.com
| t=0 0
| m=audio 49170 RTP/AVP 0
| a=rtpmap:0 PCMU/8000
| m=video 51372 RTP/AVP 31
| a=rtpmap:31 H261/90000
| m=video 53000 RTP/AVP 32
| a=rtpmap:32 MPV/90000
| Content-Type: text/plain
| Content-Length: 11
|
| Coucou !
3.2 Parties message/sipfrag invalides
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 [1].
X INVITE
X INVITE sip:alice@atlanta.com SIP/1.09
X SIP/2.0
X 404 Pas trouvé
Tous les champs d'en-tête doivent être valides selon [1].
X INVITE sip:alice@atlanta.com SIP/2.0
X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a
X To: <>;tag=39234
X To: sip:alice@atlanta.com
X From: sip:bob@biloxi.com;tag=1992312
X Call-ID: c'est invalide
X INVITE sip:alice@atlanta.com SIP/2.0
X From: <sip:bob@biloxi.com>;tag=z9hG4bK2912;tag=z9hG4bK99234
Si un corps est présent dans la partie message/sipfrag, les en-têtes requis par le paragraphe 7.4 de [1] et la ligne nulle séparant l'en-tête du corps. (Désolé, c'est comme cela dans l'original !)
X MESSAGE sip:alice@atlanta.com SIP/2.0
X Coucou !
La Section 23 de [1], et les mémoires [5] et [6] 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 [5], 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 une 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 [1] 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. [1] discute de la façon dont il faut inspecter et ignorer ces changements. Cette idée est précisée dans [6] 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.
5. Considérations relatives à l'IANA
Le type de support message/sipfrag est défini par les informations suivantes :
Nom du type de support : message
Nom du sous-type de support : sipfrag
Paramètres requis : aucun
Paramètres facultatifs : version
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. Comme tels, 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.
Considérations pour la sécurité : voir ci-dessous.
6. Considérations pour la sécurité
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 [1], avec les limitations décrites à la section 26 de ce document, ainsi que les mécanismes décrits dans [6].
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, [6] 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.
Références normatives
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley et E. Schooler, "SIP : Protocole d'initialisation de session", RFC 3261, juin 2002.
[2] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi objets (MIME) Partie 2 : Types de support", RFC 2046, novembre 1996.
[3] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 2234, novembre 1997.
[4] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.
Références non normatives
[5] R. Sparks, "Mécanisme Referred-by du protocole d'initialisation de session (SIP)", RFC 3892, septembre 2004.
[6] J. Peterson et C. Jennings, "Améliorations de la gestion d'identité authentifiée dans le protocole d'initialisation de session (SIP)", RFC 4474 août 2006.
Adresse de l'auteur
Robert J. Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
mél : rsparks@dynamicsoft.com
Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2002). 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.
Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.