Groupe de travail Réseau

M. Rose

Request For Comments : 3080

Invisible Worlds, Inc.

Catégorie : En cours de normalisation

mars 2001

Traduction Claude Brière de L'Isle

 

 

Cœur du protocole extensible d'échange de blocs (BEEP)

 

Statut du présent mémoire La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

 

Déclaration de copyright

Copyright (C) The Internet Society (2001). Tous droits réservés.

 

Résumé

Le présent mémoire décrit un noyau de protocole d'application générique pour des interactions asynchrones orientées connexion, appelé le cœur de protocole extensible d'échange de blocs (BEEP, Blocks Extensible Exchange Protocol). BEEP permet des échanges simultanés et indépendants au sein d'un contexte d'identité d'utilisateur à application unique, prenant en charge des messages aussi bien textuels que binaires.

 

Table des Matières

 

1.   Introduction

2.   Le cœur de BEEP

2.1   Rôles

2.2   Messages et trames

2.3   Gestion de canal

2.4   Établissement et libération de session

2.5   Transpositions de transport

2.6   Asynchronisme

2.7   Comportement d'homologue à homologue

3.   Sécurité du transport

3.1   Profil TLS de sécurité du transport

4.   Authentification de l'utilisateur

4.1   Famille de profils SASL

5.   Gabarits d'enregistrement

5.1   Gabarits d'enregistrement de profil

5.2   Gabarit d'enregistrement de caractéristique

6.   Enregistrements initiaux

6.1   Enregistrement : Gestion de canal BEEP

6.2   Enregistrement : Profil de sécurité du transport TLS

6.3   Enregistrement : Famille de profils SASL

6.4   Enregistrement : application/beep+xml

7.   DTD

7.1   DTD de gestion de canal BEEP

7.2   DTD de profil de sécurité de transport TLS

7.3   DTD de famille de profils SASL

8.   Codes de réponse

9.   Considérations pour la sécurité

Références

Appendice A.   Remerciements

Appendice B.   Considérations relatives à l'IANA

Déclaration de droits de reproduction

1.   Introduction

 

Le présent mémoire décrit le noyau d'un protocole d'application générique pour les interactions asynchrones orientées connexion appelé BEEP.

 

Au cœur de BEEP se trouve un mécanisme de tramage qui permet des échanges simultanés et indépendants de messages entre des homologues. Les messages sont de contenu MIME [1] arbitraire, mais sont habituellement textuels (structurés en utilisant XML [2]).

 

Tous les échanges surviennent dans le contexte d'un canal -- une liaison avec un aspect bien défini de l'application, tels que la sécurité du transport, l'authentification de l'utilisateur, ou un échange de données.

 

Chaque canal a un "profil" associé qui définit la syntaxe et la sémantique des messages échangés. La notion de gestion du canal est implicite au fonctionnement de BEEP. En plus de la définition du profil de gestion de canal de BEEP, le présent document définit :

o   le profil de sécurité du transport TLS [3] ;

o   la famille de profils SASL [4].

 

D'autres profils, tels que ceux utilisés pour l'échange des données, sont définis par un concepteur de protocole d'application.

 

2.   Le cœur de BEEP

 

Une session BEEP est transposée sur un service de transport sous-jacent. Une série de documents distincte décrit comment un service de transport particulier réalise une session BEEP. Par exemple, [5] décrit comment une session BEEP est transposée sur une seule connexion TCP [6].

 

Lorsque une session est établie, chaque homologue BEEP annonce les profils qu'il prend en charge. Plus tard, durant la création d'un canal, le client fournit un ou plusieurs profils proposés pour ce canal. Si le serveur crée le canal, il choisit un des profils et l'envoie dans une réponse ; autrement, il peut indiquer qu'aucun des profils n'est acceptable, et refuser la création du canal.

 

L'utilisation de canal rentre dans deux catégories :

 

réglage initial :   ils sont utilisés par les profils qui effectuent l'initialisation une fois que la session BEEP est établie (par exemple, en négociant l'utilisation de la sécurité du transport) ; bien que plusieurs échanges puissent être nécessaires pour effectuer l'initialisation, ces canaux deviennent inactifs tôt dans la session BEEP et le restent pour toute sa durée.

 

continu :   ils sont utilisés par des profils qui prennent en charge l'échange des données ; normalement, ces canaux sont créés après que les canaux du réglage initial soient passés au repos.

 

Noter qu'à cause de leur nature particulière, un seul canal de réglage peut être établi à un moment donné ; à l'opposé, BEEP permet plusieurs canaux d'échange de données utilisés simultanément.

 

2.1   Rôles

 

Bien que BEEP soit d'homologue à homologue, il est pratique d'étiqueter chaque homologue dans le contexte du rôle qu'il joue à un moment donné :

 

o   Lorsque une session BEEP est établie, l'homologue qui attend de nouvelles connexions agit dans le rôle de l'écoutant, et l'autre homologue, qui établit une connexion avec l'écoutant, agit dans le rôle d'initiateur. Dans les exemples qui suivent, ils sont appelés respectivement "L:" et "I:".

 

o   Un homologue BEEP qui commence un échange est appelé le client ; de même, l'autre homologue BEEP est appelé le serveur. Dans les exemples qui suivent, ils sont désignés respectivement par "C:" et "S:".

 

Normalement, un homologue BEEP qui joue le rôle de serveur jour aussi le rôle d'écoutant. Cependant, comme BEEP est par nature d'homologue à homologue, une telle exigence n'existe pas.

 

2.1.1   Styles d'échange

BEEP permet trois styles d'échange :

 

MSG/RPY :   le client envoie un message "MSG" qui demande au serveur d'effectuer une tâche, le serveur effectue la tâche et répond par un message "RPY" (appelé une réponse positive).

 

MSG/ERR :   le client envoie un message "MSG", le serveur n'effectue aucune tâche et répond par une message "ERR" (appelé une réponse négative).

 

MSG/ANS :   le client envoie un message "MSG", le serveur, tout en effectuant une certaine tâche, répond par un ou plusieurs messages "ANS", et lorsque la tâche est achevée, envoie un message "NUL", qui signifie la fin de la réponse.

 

Les deux premiers styles sont appelés des échanges d'un à un, alors que le troisième style est appelé un échange de un à plusieurs.

 

2.2   Messages et trames

 

Un message est structuré conformément aux règles de MIME. En conséquence, chaque message peut commencer par des "en-têtes-d'entité" (c.f., MIME Section 3 [1]). Si aucun, ou seulement quelques uns des "en-têtes-d'entité" n'est présent :

o   le "Type-de-contenu" par défaut est "application/flux-d'octet" ;

o   le "Codage-de-Transfert-de-contenu" par défaut est "binaire".

 

Normalement, un message est envoyé dans une seule trame. Cependant, il peut être convenable ou nécessaire de segmenter un message en plusieurs trames (par exemple, si seulement une partie d'un message est prête à l'envoi).

 

Chaque trame consiste en un en-tête, la charge utile, et un en-queue. L'en-tête et l'en-queue sont représentés tous deux en utilisant des caractères ASCII imprimables et sont terminés par une paire CRLF. Entre l'en-tête et l'en-queue se trouve la charge utile, qui consiste en zéro, un ou plusieurs octets.

 

Par exemple, voici un message qui contient une seule trame avec une charge utile de 120 octets répartis sur 5 lignes (chaque ligne est terminée par une paire CRLF) :

 

C: MSG 0 1 . 52 120

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/OTP' />

C: </start>

C: END

 

Dans cet exemple, noter que le message entier est représenté dans une seule trame.

 

2.2.1   Syntaxe de trame

L'ABNF [7] pour une trame est :

frame   = data / mapping

data   = header payload trailer

header   = msg / rpy / err / ans / nul

msg    = "MSG" SP common CR LF

rpy    = "RPY" SP common CR LF

ans    = "ANS" SP common SP ansno CR LF

err    = "ERR" SP common CR LF

nul    = "NUL" SP common CR LF

common   = channel SP msgno SP more SP seqno SP size

channel   = 0..2147483647

msgno   = 0..2147483647

more   = "." / "*"

seqno   = 0..4294967295

size   = 0..2147483647

ansno   = 0..2147483647

payload   = *OCTET

trailer   = "END" CR LF

mapping   = ;; chaque transposition de transport peut définir des trames supplémentaires

 

2.2.1.1   En-tête de trame

L'en-tête de trame consiste en un mot-clé de trois caractères ("MSG", "RPY", "ERR", "ANS" ou"NUL") suivi par zéro, un ou plusieurs paramètres. Un seul caractère espace (code décimal 32, " ") sépare chaque composant. L'en-tête est terminé par une paire CRLF.

 

Le numéro de canal ("channel") doit être un entier non négatif (dans la gamme 0 à 2 147 483 647).

 

Le numéro de message ("msgno") doit être un entier non négatif (dans la gamme 0 à 2 147 483 647) et avoir une valeur différente de tous les autres messages "MSG" sur le même canal pour lequel une réponse n'a pas été complètement reçue.

 

L'indicateur de continuation ("more", avec le code décimal 42, "*", ou 46, ".") spécifie si c'est la trame finale du message :

intermediate ("*") : au moins une autre trame suit pour le message ;

complete (".") : cette trame termine le message.

 

Le numéro de séquence ("seqno") doit être un entier non négatif (dans la gamme 0 à 4 294 967 295) et spécifie le numéro de séquence du premier octet de la charge utile, pour le canal associé (voir au paragraphe 2.2.1.2).

 

La taille de charge utile ("size") doit être un entier non négatif (dans la gamme 0 à 2 147 483 647) et spécifie le nombre exact d'octets de la charge utile. (Cela n'inclut ni l'en-tête ni l'en-queue.)

 

Noter qu'une trame peut avoir une charge utile vide, par exemple,

 

S: RPY 0 1 * 287 20

S: ...

S: ...

S: END

S: RPY 0 1 . 307 0

S: END

 

Le numéro de réponse ("ansno") doit être un entier non négatif (dans la gamme 0 à 4 294 967 295) et doit avoir une valeur différente de celle de toutes les autres réponses en cours pour le message auquel il est répondu.

 

Il y a deux sortes de trames : données et transposition Chaque transposition de transport (voir au paragraphe 2.5) peut définir ses propres trames. Par exemple, [5] définit la trame SEQ. Le reste de cette section discute des trames de données.

 

Lorsque un message est segmenté et envoyé en plusieurs trames, ces trames doivent être envoyées en séquence, sans aucune trame provenant d'autres messages sur le même canal. Cependant, il y a deux exceptions : d'abord, aucune restriction n'est faite par rapport à l'entrelacement de trames pour d'autres canaux ; et ensuite, dans un échange de un à plusieurs, plusieurs réponses peuvent être simultanément en cours. En conséquence, des trames pour des messages "ANS" peuvent être entrelacées sur le même canal -- le numéro de réponse est utilisé pour leur collationnement, par exemple,

 

S: ANS 1 0 * 0 20 0

S: ...

S: ...

S: END

S: ANS 1 0 * 20 20 1

S: ...

S: ...

S: END

S: ANS 1 0 . 40 10 0

S: ...

S: END

 

qui montre deux messages "ANS" entrelacés sur le canal 1 au titre d'une réponse au message numéro 0. Noter que le numéro de séquence est augmenté pour chaque trame envoyée sur le canal, et est indépendant des messages envoyés dans ces trames.

 

Il y a plusieurs règles pour identifier les trames mal formées :

o   si l'en-tête ne commence pas par "MSG", "RPY", "ERR", "ANS", ou "NUL" ;

o   si un des paramètres de l'en-tête ne peut être déterminé ou est invalide (c'est-à-dire, syntaxiquement incorrect);

o   si la valeur du numéro de canal ne se réfère pas à un canal existant ;

o   si l'en-tête commence par "MSG", et si le numéro de message se réfère à un message "MSG" qui a été complètement reçu mais pour lequel une réponse n'a pas été complètement envoyée ;

o   si l'en-tête ne commence pas par "MSG", et se réfère à un numéro de message pour lequel une réponse a déjà été complètement reçue ;

o   si l'en-tête ne commence pas par "MSG", et se réfère à un numéro de message qui n'a jamais été envoyé (excepté durant l'établissement de session, voir au paragraphe 2.3.1.1);

o   si l'en-tête commence par "MSG", "RPY", "ERR", ou "ANS" et se réfère à un numéro de message pour lequel au moins une autre trame a été reçue, et si le mot-clé de trois caractères qui commence cette trame et celui de la trame immédiatement précédente reçue pour ce numéro de message ne sont pas identiques ;

o   si l'en-tête commence par "NUL" et se réfère à un numéro de message pour lequel au moins une autre trame a été reçue, et si le mot-clé de la trame immédiatement précédente reçue pour cette réponse n'est pas "ANS" ;

o   si l'indicateur de continuation de la trame précédente reçue sur le même canal était intermediate ("*"), et si son numéro de message n'est pas identique au numéro de message de cette trame ;

o   si la valeur du numéro de séquence ne correspond pas à la valeur attendue pour le canal associé (c.f., § 2.2.1.2) :

o   si l'en-tête commence par "NUL", et si l'indicateur de continuation est intermediate ("*") ou si la taille de charge utile est différente de zéro.

 

Si une trame est mal formée, la session est alors terminée sans générer de réponse, et il est recommandé qu'une entrée de diagnostic soit enregistrée.

 

2.2.1.2   Charge utile de trame

La charge utile de trame consiste en zéro, un ou plusieurs octets.

 

Chaque octet de charge utile envoyé dans chaque direction sur un canal a un numéro de séquence associé. Le numérotage des octets de charge utile au sein d'une trame est tel que le premier octet de charge utile a le numéro le plus faible, et les octets de charge utile suivants sont numérotés en conséquence. (Lorsque un canal est créé, le numéro de séquence associé au premier octet de charge utile de la première trame est 0.)

 

L'espace réel de numéros de séquence est fini, bien que très grand, allant de 0 à 4 294 967 295 (2**32 - 1). Comme l'espace est fini, toute l'arithmétique qui traite des numéros de séquence est effectuée modulo 2**32. Cette arithmétique sans signe préserve les relations des numéros de séquence lorsque ils déroulent à nouveau le cycle de 2**32 - 1 à 0. Consulter les Sections 2 à 5 de [8] pour un exposé sur les propriétés arithmétiques des numéros de séquence.

 

Lors de la réception d'une trame, la somme de ses numéros de séquence et de la taille de charge utile, modulo 4 294 967 296 (2**32) donne le numéro de séquence associé attendu avec le premier octet de charge utile de la prochaine trame reçue. En conséquence, lors de la réception d'une trame, si le numéro de séquence n'est pas la valeur attendue pour ce canal, l'homologue BEEP a alors perdu la synchronisation ; la session se termine sans générer de réponse, et il est recommandé d'enregistrer une entrée de diagnostic.

 

2.2.1.3   En-queue de trame

L'en-queue de trame consiste en "END" suivi par une paire CRLF.

 

Lors de la réception d'une trame, si les caractères qui suivent immédiatement la charge utile ne correspondent pas à un en-queue, la session se termine sans générer de réponse, et il est recommandé d'enregistrer une entrée de diagnostic.

 

2.2.2   Sémantique de trame

La sémantique de chaque message est spécifique du canal. En conséquence, le profil associé à un canal doit définir :

o   les messages d'initialisation, si il en est, échangés durant la création du canal ;

o   les messages qui peuvent être échangés dans la charge utile du canal ;

o   la sémantique de ces messages.

 

Un gabarit d'enregistrement de profil (paragraphe 5.1) organise ces informations.

 

2.2.2.1   Messages mal formés

Lors de la définition du comportement du profil, le gabarit doit spécifier comment il est répondu aux messages "MSG" mal formés. Par exemple, le profil de gestion de canal envoie une réponse négative contenant un message d'erreur (voir au paragraphe 2.3.1.5).

 

Si une réponse mal formée est reçue sur le canal zéro, la session se termine sans générer de réponse, et il est recommandé d'enregistrer une entrée de diagnostic.

 

Si une réponse mal formée est reçue sur un autre canal, celui-ci doit être fermé en utilisant la procédure du paragraphe 2.3.1.3.

 

2.3   Gestion de canal

 

Lorsque commence une session BEEP, seul le numéro de canal zéro est défini, qui est utilisé pour la gestion de canal. Le paragraphe 6.1 contient l'enregistrement de profil pour la gestion de canal BEEP.

 

La gestion de canal permet à chaque homologue BEEP d'annoncer les profils qu'il prend en charge (voir au paragraphe 2.3.1.1), de lier une instance d'un de ces profils à un canal (voir au paragraphe 2.3.1.2) puis de clore ultérieurement tous les canaux ou libèrer la session BEEP (voir au paragraphe 2.3.1.3).

 

Un homologue BEEP devrait prendre en charge au moins 257 canaux simultanés.

 

2.3.1   Sémantique des messages

 

2.3.1.1   Message d'accueil

Lorsque une session BEEP est établie, chaque homologue BEEP signifie sa disponibilité en envoyant immédiatement une réponse positive avec un numéro de message de zéro qui contient un élément "greeting", par exemple,

 

L: <attente d'une connexion entrante>

I: <connexion ouverte>

L: RPY 0 0 . 0 110

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/TLS' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

 

Noter que cet exemple implique que l'homologue BEEP dans le rôle d'initiateur attend que l'homologue BEEP dans le rôle d'écoutant envoie son accueil – c'est un artifice de la présentation ; en fait, les deux homologues BEEP envoient leur réponse indépendamment.

 

L'élément "greeting" a deux attributs facultatifs ("features" et "localize") et zéro, un ou plusieurs éléments "profile", un pour chaque profil pris en charge par l'homologue BEEP agissant dans un rôle de serveur :

 

o   l'attribut "features", si il est présent, contient un ou plusieurs jetons de caractéristiques, indiquant chacun une caractéristique facultative du profil de gestion du canal prise en charge par l'homologue BEEP;

 

o   l'attribut "localize", si il est présent, contient un ou plusieurs jetons de langage (définis dans [9]), identifiant chacun une étiquette de langage désirable à utiliser par l'homologue BEEP distant lors de la génération de diagnostics textuels pour les éléments "close" et "error" (les jetons sont ordonnés du plus au moins désirable) ;

 

o   chaque élément "profile" contenu au sein de l'élément "greeting" identifie un profil, et à la différence des éléments "profile" qui surviennent au sein de l'élément "start", le contenu de chaque élément "profile" ne peut pas contenir de message d'initialisation facultatif.

 

Le paragraphe 5.2 définit un gabarit d'enregistrement pour les caractéristiques facultatives.

 

2.3.1.2   Message Start

Lorsque un homologue BEEP veut créer un canal, il envoie un élément "start" sur le canal zéro, par exemple,

 

C: MSG 0 1 . 52 120

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/OTP' />

C: </start>

C: END

 

L'élément "start" a un attribut "number", un attribut "serverName" facultatif, et un ou plusieurs éléments "profile" :

o   l'attribut "number" indique le numéro de canal (dans la gamme 1 à 2 147 483 647) utilisé pour identifier le canal dans les messages futurs;

o   l'attribut "serverName" est une chaîne arbitraire qui indique le nom de serveur désiré pour cette session BEEP ;

o   chaque élément "profile" contenu avec l'élément "start" a un attribut "uri", un attribut "encoding" facultatif, et des données de caractères arbitraires comme contenu :

*   l'attribut "uri" identifie le profil ;

*   l'attribut "encoding", si présent, spécifie si le contenu de l'élément "profile" est représenté comme une chaîne codée en base64 ;

*   le contenu de l'élément "profile", si présent, ne doit pas dépasser 4 koctets et il spécifie un message d'initialisation donné au canal aussitôt qu'il est créé.

Pour éviter des conflits dans l'allocation des numéros de canal lors d'une demande de création d'un canal, les homologues BEEP qui agissent dans le rôle d'initiateur utilisent seulement des entiers positifs qui sont impairs ; de même, les homologues BEEP qui agissent dans le rôle d'écoutant utilisent seulement des entiers positifs pairs.

 

L'attribut "serverName" pour le premier élément "start" réussi reçu par un homologue BEEP a une signification pour la durée de la session BEEP. S'il est présent, l'homologue BEEP décide si il va fonctionner comme le "serverName" indiqué ; sinon, un élément "error" est envoyé dans une réponse négative.

 

Lorsque un homologue BEEP reçoit un élément "start" sur le canal zéro, il examine chacun des profils proposés, et décide s'il va utiliser l'un d'eux pour créer le canal. S'il en est ainsi, l'élément "profile" approprié est envoyé dans une réponse positive ; autrement, un élément "erreur" est envoyé dans une réponse négative.

 

Lors de la création du canal, la valeur de l'attribut "serverName" provenant du premier élément "start" réussi est consultée pour fournir les informations de configuration, par exemple, le certificat désiré côté serveur lors du démarrage du profil de sécurité du transport TLS (paragraphe 3.1).

 

Par exemple, une création de canal réussie pourrait ressembler à ceci :

 

C: MSG 0 1 . 52 178

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/OTP' />

C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />

C: </start>

C: END

S: RPY 0 1 . 221 87

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/SASL/OTP' />

S: END

 

De même une création de canal infructueuse pourrait ressembler à ceci :

 

C: MSG 0 1 . 52 120

C: Content-Type: application/beep+xml

C:

C: <start number='2'>

C: <profile uri='http://iana.org/beep/SASL/OTP' />

C: </start>

C: END

S: ERR 0 1 . 221 127

S: Content-Type: application/beep+xml

S:

S: <error code='501'>number attribute

S: in &lt;start&gt; element must be odd-valued</error>

S: END

 

Finalement, voici un exemple dans lequel un élément d'initialisation est échangé durant la création du canal :

 

C: MSG 0 1 . 52 158

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/TLS'>

C: <![CDATA[<ready />]]>

C: </profile>

C: </start>

C: END

S: RPY 0 1 . 110 121

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/TLS'>

S: <![CDATA[<proceed />]]>

S: </profile>

S: END

 

2.3.1.3   Message Close

Lorsque un homologue BEEP veut clore un canal, il envoie un élément "close" sur le canal zéro, par exemple,

 

C: MSG 0 2 . 235 71

C: Content-Type: application/beep+xml

C:

C: <close number='1' code='200' />

C: END

 

L'élément "close" a un attribut "number", un attribut "code", un attribut facultatif "xml:lang" et un diagnostic textuel facultatif comme contenu :

o   l'attribut "number" indique le numéro de canal ;

o   l'attribut "code" est un code de réponse de trois chiffres qui a une signification pour les programmes (voir la Section 8) ;

o   l'attribut "xml:lang" identifie le langage dans lequel est écrit le contenu de l'élément (la valeur est suggérée, mais pas obligatoire, par l'attribut "localize" de l'élément "greeting" envoyé par l'homologue BEEP distant ) ;

o   le diagnostic textuel (qui peut être multi ligne) est significatif pour les mises en œuvre, peut être pour les administrateurs, et éventuellement les usagers, mais jamais pour les programmes.

 

Noter que si le diagnostic textuel est présent, l'attribut "xml:lang" n'est alors absent que si le langage indiqué comme premier choix de l'homologue BEEP distant est utilisé.

 

Si la valeur de l'attribut "number" est zéro, l'homologue BEEP veut alors libérer la session BEEP (voir au paragraphe 2.4) – autrement la valeur de l'attribut "number" se réfère à un canal existant, et le reste de la présente section s'applique.

 

Un homologue BEEP peut envoyer un message "close" pour un canal chaque fois que tous les messages "MSG" qu'il a envoyés sur ce canal ont reçu un accusé de réception. (Pour l'homologue BEEP qui a envoyé le message "MSG" , l'accusé de réception consiste à recevoir la première trame d'une réponse.)

 

Après l'envoi du message "close", cet homologue BEEP ne doit plus envoyer de messages "MSG" sur ce canal qui va être fermé jusqu'à ce que la réponse au message "close" ait été reçue (par un message "error" rejetant la demande de fermeture du canal, ou par un message "ok" suivi ultérieurement par la réussite du lancement du canal).

 

NOTER BIEN : jusqu'à réception d'une réponse positive à la demande de fermeture du canal, l'homologue BEEP doit être prêt à traiter tout message "MSG" qu'il recevra sur ce canal.

 

Lorsque un homologue BEEP reçoit un message "close" pour un canal, il peut, à tout moment, rejeter la demande de clôture du canal en envoyant un message "error" dans une réponse négative.

 

Autrement, avant d'accepter la demande de clôture du canal, et d'envoyer un message "ok" dans une réponse positive, il doit :

o   finir d'envoyer tous les messages "MSG" en file d'attente de son fait sur ce canal ;

o   attendre les réponses complètes à tout message "MSG" en instance qu'il aurait envoyé sur ce canal ;

o   finir d'envoyer les réponses complètes à tout message "MSG" en cours reçu sur ce canal et s'assurer que les trames finales de ces réponses ont bien été livrées, c'est-à-dire,

*   pour les transpositions de transport qui garantissent l'ordre des messages entre les canaux, les réponses doivent être envoyées avant d'envoyer le message "ok" dans une réponse positive ; autrement,

*   les réponses doivent être envoyées et recevoir ensuite un accusé de réception par le service de transport sous-jacent avant d'envoyer le message "ok" dans une réponse positive.

 

En bref, une clôture de canal réussi pourrait ressembler à ceci :

 

C: MSG 0 2 . 235 71

C: Content-Type: application/beep+xml

C:

C: <close number='1' code='200' />

C: END

S: RPY 0 2 . 392 46

S: Content-Type: application/beep+xml

S:

S: <ok />

S: END

 

De même, un échec de clôture de canal pourrait ressembler à ceci :

 

C: MSG 0 2 . 235 71

C: Content-Type: application/beep+xml

C:

C: <close number='1' code='200' />

C: END

S: ERR 0 2 . 392 79

S: Content-Type: application/beep+xml

S:

S: <error code='550'>still working</error>

S: END

 

2.3.1.4   Message OK

Lorsque un homologue BEEP est d'accord pour clore un canal (ou libérer la session BEEP) il envoie un élément "ok" dans une réponse positive.

 

L'élément "ok" n'a pas d'attribut et pas de contenu.

 

2.3.1.5   Message Error

Lorsque un homologue BEEP refuse la création d'un canal, il envoie un élément "error" dans une réponse négative, par exemple,

 

I: MSG 0 1 . 52 115

I: Content-Type: application/beep+xml

I:

I: <start number='2'>

I: <profil uri='http://iana.org/beep/FOO' />

I: </start>

I: END

L: ERR 0 1 . 221 105

L: Content-Type: application/beep+xml

L:

L: <code d'erreur ='550'> tous les profils demandés sont des </error> non prises en charge

L: END

 

L'élément "error" a un attribut "code", un attribut "xml:lang" facultatif, et un diagnostic textuel facultatif comme contenu :

o   l'attribut "code" est un code de réponse de trois chiffres qui a une signification pour les programmes (voir la Section 8) ;

o   l'attribut "xml:lang" identifie le langage dans laquelle est écrit le contenu de l'élément (la valeur est suggérée, mais pas obligatoire, par l'attribut "localize" de l'élément "greeting" envoyé par l'homologue BEEP distant ) ;

o   le diagnostic textuel (qui peut être sur plusieurs lignes) est significatif pour les développeurs, peut-être pour les administrateurs, et éventuellement même pour les usagers, mais jamais pour les programmes.

 

Noter que si le diagnostic textuel est présent, l'attribut "xml:lang" n'est absent que si le langage indiqué comme premier choix de l'homologue BEEP distant est utilisé.

 

De plus, un homologue BEEP envoie un élément "error" chaque fois que :

o   il reçoit un message "MSG" qui contient un élément mal formé ou inattendu ;

o   il reçoit un message "MSG" demandant de clore un canal (ou de libérer la session BEEP) et qu'il refuse de le faire ; ou

o   une session BEEP est établie, l'homologue BEEP jour le rôle de l'écoutant, et cet homologue BEEP est indisponible (dans ce cas, le BEEP qui jour le rôle d'écoutant n'envoie pas d'élément "greeting").

 

Dans le dernier cas, les deux homologues BEEP terminent la session, et il est recommandé qu'une entrée de diagnostic soit enregistrée par les deux homologues BEEP.

 

2.4   Établissement et libération de session

 

Lorsque une session BEEP est établie, chaque homologue BEEP signifie sa disponibilité en envoyant immédiatement une réponse positive avec un numéro de message de zéro sur le canal zéro qui contient un élément "greeting", par exemple,

 

L: <attente d'une connexion entrante>

I: <connexion ouverte>

L: RPY 0 0 . 0 110

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/TLS' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

 

Autrement, si l'homologue BEEP qui joue le rôle d'écoutant est indisponible, il envoie une réponse négative, par exemple,

 

L: <attente d'une connexion entrante>

I: <connexion ouverte>

L: ERR 0 0 . 0 60

L: Content-Type: application/beep+xml

L:

L: <error code='421' />

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

I: <clore la connexion>

L: <clore la connexion>

L: <attente de la prochaine connexion>

 

et l'élément "greeting" envoyé par l'homologue BEEP qui joue le rôle d'écoutant est ignoré. Il est recommandé d'enregistrer une entrée de diagnostic pour les deux homologues BEEP.

 

Noter que ces deux exemples impliquent que l'homologue BEEP qui joue le rôle d'initiateur attende que l'homologue BEEP qui joue le rôle d'écoutant envoie son accueil – ceci est un artifice de la présentation ; en fait, les deux homologues BEEP envoient indépendamment leur réponse.

 

Lorsque un homologue BEEP veut libérer la session BEEP, il envoie un élément "close" avec un attribut "number" de valeur zéro sur le canal zéro. L'autre homologue BEEP indique son accord par l'envoi d'un élément "ok" dans une réponse positive, par exemple,

 

C: MSG 0 1 . 52 60

C: Content-Type: application/beep+xml

C:

C: <code de clôture ='200' />

C: END

S: RPY 0 1 . 264 46

S: Content-Type: application/beep+xml

S:

S: <ok />

S: END

I: <clore la connexion>

L: <clore la connexion>

L: <attende de la prochaine connexion>

 

Autrement, si l'autre BEEP ne veut pas libérer la session BEEP, l'échange pourrait ressembler à ceci :

 

C: MSG 0 1 . 52 60

C: Content-Type: application/beep+xml

C:

C: <code de clôture ='200' />

C: END

S: ERR 0 1 . 264 79

S: Content-Type: application/beep+xml

S:

S: <code d'erreur ='550'>toujours active </error>

S: END

 

Si la libération de session est refusée, la session BEEP ne devrait pas se terminer, si possible.

 

2.5   Transpositions de transport

 

Toutes les interactions de transport surviennent dans le contexte d'une session -- une transposition sur un service de transport particulier. En conséquence, le présent mémoire définit les exigences qui doivent être satisfaites par tout document qui décrit comment un service de transport particulier réalise une session BEEP.

 

2.5.1   Gestion de session

Une session BEEP est orientée connexion. Un document de transposition doit définir :

o   comment est établie une session BEEP ;

o   comment un homologue BEEP est identifié comme jouant le rôle d'écoutant ;

o   comment un homologue BEEP est identifié comme jouant le rôle d'initiateur ;

o   comment une session BEEP est libérée ;

o   comment une session BEEP se termine.

 

2.5.2   Échange de messages

Une session BEEP est orientée message. Un document de transposition doit définir :

o   comment les messages sont envoyés et reçus de façon fiable ;

o   comment les messages sur le même canal sont reçus dans le même ordre que celui dans lequel ils ont été envoyés ;

o   comment les messages sur des canaux différents sont envoyés sans contrainte d'ordre.

 

2.6   Asynchronisme

 

BEEP s'accommode d'interactions asynchrones, aussi bien au sein d'un seul canal qu'entre des canaux séparés. Cette caractéristique permet le traitement en parallèle intra canal et inter canal.

 

2.6.1   Au sein d'un seul canal

Un homologue BEEP jouant le rôle de client peut envoyer plusieurs messages "MSG" sur le même canal sans attendre de recevoir les réponses correspondantes. Cela donne un traitement en parallèle au sein d'un seul canal.

 

Un homologue BEEP qui joue le rôle de serveur doit traiter tous les messages "MSG" pour un canal donné dans le même ordre que celui dans lequel ils ont été reçus. Par conséquent, l'homologue BEEP doit générer les réponses dans le même ordre que celui des messages "MSG" correspondant reçus sur un canal donné.

 

Noter que dans les échanges de un à plusieurs (voir au paragraphe 2.1.1) la réponse au message "MSG" consiste en zéro, un ou plusieurs messages "ANS" suivis d'un message "NUL". Dans ce style d'échange, les messages "ANS" comportant la réponse peuvent être entrelacés. Lorsque l'homologue BEEP qui jour le rôle de serveur signifie la fin de la réponse en générant le message "NUL", il peut alors traiter le message "MSG" suivant reçu pour ce canal.

 

2.6.2   Entre des canaux différents

Un homologue BEEP jouant le rôle de client peut envoyer plusieurs messages "MSG" sur différents canaux sans attendre de recevoir les réponses correspondantes. Les canaux fonctionnent indépendamment, en parallèle.

 

Un homologue BEEP qui joue le rôle de serveur peut traiter les messages "MSG" reçus sur différents canaux dans l'ordre de son choix. Par conséquent, bien que les réponses pour un canal donné apparaissent comme générées dans le même ordre que celui dans lequel les messages "MSG" correspondants sont reçus, il n'y a pas de contrainte d'ordre pour les réponses sur des canaux différents.

 

2.6.3   Réponses préemptives

Un homologue BEEP jouant le rôle de serveur peut envoyer une réponse négative avant d'avoir reçu la trame finale du message "MSG". S'il fait ainsi, cet homologue BEEP est obligé d'ignorer toutes les trames suivantes pour ce message "MSG", jusque et y compris la trame "MSG" finale.

 

Si un homologue BEEP jouant le rôle de client reçoit une réponse négative avant qu'il envoie la trame "MSG" finale pour un message, il est alors obligé d'envoyer une trame "MSG" avec un statut de continuation de complete (".") et ayant une charge utile de longueur zéro.

2.6.4   Interférence

Si le traitement d'un message particulier a un impact sur le séquencement d'autres messages (intra canal ou inter canal), le profil correspondant devrait alors définir ce comportement, par exemple, un profil dont les messages altèrent la transposition de transport sous-jacente.

 

2.7   Comportement d'homologue à homologue

 

BEEP est d'homologue à homologue – et comme tels, les deux homologues doivent être prêts à recevoir tous les messages définis dans le présent mémoire. En conséquence, un homologue BEEP initiateur capable de ne jouer que le rôle de client doit se comporter avec bienveillance si il reçoit un message "MSG". Conformément à cela, tous les profils doivent fournir un message d'erreur approprié pour répondre à des messages "MSG" inattendus.

 

Une conséquence de la nature d'homologue à homologue de BEEP est que les numéros de message n'ont une signification qu'unidirectionnelle. C'est à dire que les numéros de message dans les messages "MSG" envoyés par un homologue BEEP jouant le rôle d'initiateur sont sans relation avec les numéros de message dans les messages "MSG" envoyés par un homologue BEEP jouant le rôle d'écoutant.

 

Par exemple, ces deux messages

 

I: MSG 0 1 . 52 120

I: Content-Type: application/beep+xml

I:

I: <start number='1'>

I: <profile uri='http://iana.org/beep/SASL/OTP' />

I: </start>

I: END

L: MSG 0 1 . 221 116

L: Content-Type: application/beep+xml

L:

L: <start number='2'>

L: <profile uri='http://iana.org/beep/APEX' />

L: </start>

L: END

 

se réfèrent à des messages différents envoyés sur le canal zéro.

 

3.   Sécurité du transport

 

Lorsque une session BEEP est établie, le transfert du texte en clair, sans confidentialité, est fourni. En conséquence, la sécurité du transport est réalisée dans BEEP en utilisant un profil de réglage initial.

 

Le présent document définit un profil : le profil de sécurité de transport TLS, fondé sur TLS version un [3].

 

D'autres profils peuvent être définis et développés de façon bilatérale. Noter qu'à cause de leur relation intime avec le service de transport, un profil de sécurité du transport donné tend à n'être pertinent que pour une seule transposition de transport (voir au paragraphe 2.5).

 

Lorsque un canal associé à la sécurité du transport commence le processus de négociation sous-jacent, tous les canaux (y compris le canal zéro) sont clos sur la session BEEP. En conséquence, à l'achèvement du processus de négociation, sans considération de son résultat, un nouvel accueil est produit par les deux homologues BEEP. (Si le processus de négociation échoue, l'un ou l'autre homologue BEEP peut plutôt terminer la session, et il est recommandé d'enregistrer une entrée de diagnostic.)

 

Un homologue BEEP peut choisir de produire un accueil différent selon que la confidentialité est utilisée, par exemple,

 

L: <attente d'une connexion entrante>

I: <connexion ouverte>

L: RPY 0 0 . 0 110

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/TLS' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

I: MSG 0 1 . 52 158

I: Content-Type: application/beep+xml

I:

I: <start number='1'>

I: <profile uri='http://iana.org/beep/TLS'>

I: <![CDATA[<ready />]]>

I: </profile>

I: </start>

I: END

L: RPY 0 1 . 110 121

L: Content-Type: application/beep+xml

L:

L: <profile uri='http://iana.org/beep/TLS'>

L: <![CDATA[<proceed />]]>

L: </profile>

L: END

 

... négociation réussie de sécurité du transport ...

 

L: RPY 0 0 . 0 221

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />

L: <profile uri='http://iana.org/beep/SASL/OTP' />

L: <profile uri='http://iana.org/beep/APEX' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

 

Bien sûr, il n'est pas nécessaire que tous les homologues BEEP soient stupides :

 

L: <attente d'une connexion entrante>

I: <connexion ouverte>

L: RPY 0 0 . 0 268

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />

L: <profile uri='http://iana.org/beep/SASL/OTP' />

L: <profile uri='http://iana.org/beep/APEX' />

L: <profile uri='http://iana.org/beep/TLS' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

I: MSG 0 1 . 52 158

I: Content-Type: application/beep+xml

I:

I: <start number='1'>

I: <profile uri='http://iana.org/beep/TLS'>

I: <![CDATA[<ready />]]>

I: </profile>

I: </start>

I: END

L: RPY 0 1 . 268 121

L: Content-Type: application/beep+xml

L:

L: <profile uri='http://iana.org/beep/TLS'>

L: <![CDATA[<proceed />]]>

L: </profile>

L: END

 

...échec de négociation de sécurité du transport ...

 

L: RPY 0 0 . 0 268

L: Content-Type: application/beep+xml

L:

L: <greeting>

L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />

L: <profile uri='http://iana.org/beep/SASL/OTP' />

L: <profile uri='http://iana.org/beep/APEX' />

L: <profile uri='http://iana.org/beep/TLS' />

L: </greeting>

L: END

I: RPY 0 0 . 0 52

I: Content-Type: application/beep+xml

I:

I: <greeting />

I: END

 

3.1   Profil TLS de sécurité du transport

 

Le paragraphe 6.2 contient l'enregistrement de ce profil.

 

3.1.1   Identification et initialisation de profil

Le profil de sécurité du transport TLS est identifié par :

 

http://iana.org/beep/TLS

 

dans l'élément BEEP "profile" durant la création de canal.

 

Durant la création de canal, l'élément "profile" correspondant dans l'élément BEEP "start" peut contenir un élément "ready". Si la création de canal réussit, avant d'envoyer la réponse correspondante, l'homologue BEEP traite alors l'élément "ready" et inclut la réponse résultante dans la réplique, par exemple,

 

C: MSG 0 1 . 52 158

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/TLS'>

C: <![CDATA[<ready />]]>

C: </profile>

C: </start>

C: END

S: RPY 0 1 . 110 121

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/TLS'>

S: <![CDATA[<proceed />]]>

S: </profile>

S: END

 

Noter qu'il est possible que le canal soit créé, mais que l'opération encapsulée échoue, par exemple,

 

C: MSG 0 1 . 52 173

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/TLS'>

C: <![CDATA[<ready version="oops" />]]>

C: </profile>

C: </start>

C: END

S: RPY 0 1 . 110 193

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/TLS'>

S: <![CDATA[<error code='501'>version attribute poorly formed in &lt;ready&gt; element</error>]]>

S: </profile>

S: END

 

Dans ce cas, une réponse positive est envoyée (car la création du canal a réussi) mais la réponse encapsulée contient une indication de la raison de l'échec de l'opération.

 

3.1.2   Syntaxe de message

Le paragraphe 7.2 définit les messages qui sont utilisés dans le profil de sécurité du transport TLS.

 

3.1.3   Sémantique de message

3.1.3.1   Message Ready

L'élément "ready" a un attribut "version" facultatif et pas de contenu :

o   l'élément "version" définit la plus ancienne version de TLS dont l'utilisation est acceptable.

 

Lorsque un homologue BEEP envoie l'élément "ready", il ne doit pas envoyer d'autre trafic sur le service de transport sous-jacent jusqu'à ce que la réponse correspondante ("proceed" ou "error") soit reçue ; de même, l'homologue BEEP qui reçoit doit attendre que toutes les réponses en cours aient été générées et envoyées avant de traiter un élément "ready".

 

3.1.3.2   Message Proceed

L'élément "proceed" n'a pas d'attribut et pas de contenu. Il est envoyé en réponse à l'élément "ready".

 

Lorsque un homologue BEEP reçoit l'élément "ready", il ne doit pas envoyer d'autre trafic sur le service de transport sous-jacent jusqu'à ce qu'il génère une réponse correspondante. Si l'homologue BEEP décide de permettre la négociation de la sécurité du transport, il clôt implicitement tous les canaux (y compris le canal zéro) et envoie l'élément "proceed", puis attend le processus de négociation sous-jacent pour la sécurité du transport.

 

Lorsque un homologue BEEP reçoit un élément "proceed" en réponse à son message "ready", il clôt implicitement tous les canaux (y compris le canal zéro) et commence immédiatement le processus de négociation sous-jacent pour la sécurité du transport.

 

4.   Authentification de l'utilisateur

 

Lorsque une session BEEP est établie, un accès anonyme, sans information de traçage, est fourni. En conséquence, l'authentification de l'utilisateur est réalisée dans BEEP en utilisant un profil de réglage initial.

 

Le présent document définit une famille de profils fondés sur les mécanismes de SASL :

o   chaque mécanisme du registre SASL de l'IANA [15] a un profil associé.

 

D'autres profils peuvent être définis et déployés de façon bilatérale.

 

Chaque fois que survient une authentification réussie, sur tout canal, l'identité authentifiée est mise à jour pour tous les canaux existants et futurs de la session BEEP ; de plus, aucune tentative d'authentification supplémentaire n'est permise.

 

Noter que sans considération de la sécurité du transport et de l'authentification de l'utilisateur, l'autorisation est une affaire interne à chaque homologue BEEP. À ce titre, chaque homologue peut choisir de restreindre les opérations qu'il permet sur la base des accréditifs d'authentification fournis (c'est-à-dire que des opérations non autorisées peuvent être rejetées avec le code d'erreur 530).

 

4.1   Famille de profils SASL

 

Le paragraphe 6.3 contient l'enregistrement pour ce profil.

 

Noter que SASL peut fournir à la fois l'authentification de l'utilisateur et la sécurité du transport. Une fois que la sécurité du transport a été négociée avec succès pour une session BEEP, une couche de sécurité SASL ne doit plus être négociée ; de même, une fois qu'une négociation SASL a réussi, un profil de sécurité du transport ne doit pas commencer son processus de négociation sous-jacente.

 

La Section 4 de la spécification SASL [4] exige que les informations suivantes soient fournies par une définition de protocole :

 

nom de service : "beep"

 

séquence d'initialisation : La création d'un canal utilisant un profil BEEP correspondant à un mécanisme SASL débute l'échange. Un paramètre facultatif correspondant à la "réponse initiale" envoyée par le client est porté dans un élément "blob" durant la création du canal.

 

séquence d'échange : Les "mises en cause" (challenge) et les "réponses" sont portées dans les échanges d'élément "blob". L'attribut "status" de l'élément "blob" est utilisé à la fois par un serveur qui indique l'achèvement réussi de l'échange, et par un client qui abandonne l'échange. Le serveur indique l'échec de l'échange en envoyant un élément "error".

 

négociation de couche de sécurité : Lorsque une couche de sécurité commence la négociation, tous les canaux (y compris le canal zéro) sont clos sur la session BEEP. En conséquence, à l'achèvement du processus de négociation, sans considération de son résultat, un nouvel accueil est produit par les deux homologues BEEP.

 

Si une couche de sécurité réussit sa négociation, elle prend effet immédiatement après le message qui conclut la réponse d'achèvement réussi du serveur.

 

utilisation de l'identité d'autorisation : Elle est rendue disponible à tous les canaux pour la durée de la session BEEP.

 

4.1.1   Identification et initialisation du profil

Chaque mécanisme SASL enregistré auprès de l'IANA est identifié par :

 

http://iana.org/beep/SASL/mechanism

 

où "MECHANISM" est le jeton alloué à ce mécanisme par l'IANA.

 

Noter que durant la création de canal, un homologue BEEP peut fournir plusieurs profils à l'homologue distant, par exemple,

 

C: MSG 0 1 . 52 178

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />

C: <profile uri='http://iana.org/beep/SASL/OTP' />

C: </start>

C: END

S: RPY 0 1 . 221 87

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/SASL/OTP' />

S: END

 

Durant la création de canal, l'élément "profile" correspondant dans l'élément BEEP "start" peut contenir un élément "blob". Noter qu'il est possible que le canal soit créé, mais que l'opération encapsulée échoue, par exemple,

 

C: MSG 0 1 . 52 183

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/OTP'>

C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>

C: </profile>

C: </start>

C: END

S: RPY 0 1 . 221 178

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/SASL/OTP'>

S: <![CDATA[<error code='534'>mécanisme d'authentification trop faible</error>]]>

S: </profile>

S: END

 

Dans ce cas, une réponse positive est envoyée (car la création du canal a réussi) mais la réponse encapsulée contient une indication de la raison de l'échec de l'opération.

 

Autrement, le serveur envoie une mise en cause (ou signifie le succès) par exemple,

 

C: MSG 0 1 . 52 183

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/OTP'>

C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>

C: </profile>

C: </start>

C: END

S: RPY 0 1 . 221 171

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/SASL/OTP'>

S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=

</blob>]]>

S: </profile>

S: END

 

Noter que cet exemple implique que l'élément "blob" dans la réplique du serveur apparaît sur deux lignes – c'est un artifice de présentation ; en fait, une seule ligne est utilisée.

 

Si une mise en cause est reçue, le client répond alors et attend une autre réplique, par exemple,

 

C: MSG 1 0 . 0 97

C: Content-Type: application/beep+xml

C:

C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>

C: END

S: RPY 1 0 . 0 66

S: Content-Type: application/beep+xml

S:

S: <blob status='complete' />

S: END

 

Bien sûr, le client pourrait interrompre le processus d'authentification en envoyant à la place "<blob status='abort' />".

 

Autrement, le serveur pourrait rejeter la réponse avec une erreur. par exemple,

 

C: MSG 1 0 . 0 97

C: Content-Type: application/beep+xml

C:

C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>

C: END

S: ERR 1 0 . 0 60

S: Content-Type: application/beep+xml

S:

S: <error code='535' />

S: END

 

Finalement, selon le mécanisme SASL, un élément d'initialisation peut être échangé en unidirectionnel durant la création de canal, par exemple,

 

C: MSG 0 1 . 52 125

C: Content-Type: application/beep+xml

C:

C: <start number='1'>

C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />

C: </start>

C: END

S: RPY 0 1 . 221 185

S: Content-Type: application/beep+xml

S:

S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>

S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+</blob>]]>

S: </profile>

S: END

 

Noter que cet exemple implique que l'élément "blob" dans la réplique du serveur apparaît sur deux lignes – c'est un artifice de la présentation ; en fait, une seule ligne est utilisée.

 

4.1.2   Syntaxe du message

Le paragraphe 7.3 définit les messages qui sont utilisés pour chaque profil dans la famille SASL.

 

Noter que parce que beaucoup de mécanismes SASL échangent des données binaires, le contenu de l'élément "blob" est toujours une chaîne codée en base64.

 

4.1.3   Sémantique du message

L'élément "blob" a un attribut "status" facultatif, et un nombre arbitraire d'octets en contenu :

o   l'attribut "status", si présent, prend une des trois valeurs :

abort : utilisée par un client pour indiquer qu'il interrompt le processus d'authentification ;

complete : utilisé par un serveur pour indiquer que l'échange est achevé et réussi ;

continue : utilisé autrement par un client ou serveur.

 

Finalement, noter que les mécanismes EXTERNAL de SASL fonctionnent avec un service "d'authentification externe", qui est fourni par :

o   un profil de sécurité du transport, capable de fournir des informations d'authentification (par exemple, paragraphe 3.1), qui est actif sur la connexion ;

o   un service réseau, capable de fournir une authentification forte (par exemple, IPSec [12]) sous-jacente à la connexion ;

o   un service de sécurité à définition locale.

 

Pour que l'authentification réussisse, deux conditions doivent être satisfaites :

o   un service d'authentification externe doit être actif ;

o   si elle est présente, l'identité d'authentification doit être cohérente avec les accréditifs fournis par le service externe d'authentification (si l'identité d'authentification est vide, une identité d'autorisation est automatiquement déduite des accréditifs fournis par le service externe d'authentification).

 

5.   Gabarits d'enregistrement

5.1   Gabarits d'enregistrement de profil

 

Lorsque un profil est enregistré, les informations suivantes sont fournies :

-   Identification du profil : spécifie un URI [10] qui a autorité pour identifier ce profil.

-   Messages échangés durant la création du canal : spécifie les types de données qui peuvent être échangés durant la création du canal.

-   Messages commençant les échanges de un à un : spécifie les types de données qui peuvent être présents lorsque commence un échange.

-   Messages dans les réponses positives : spécifie les types de données qui peuvent être présents dans une réponse positive.

-   Messages dans les réponses négatives : spécifie les types de données qui peuvent être présents dans une réponse négative.

-   Messages dans les échanges de un à plusieurs : spécifient les types de données qui peuvent être présents dans un échange de un à plusieurs.

-   Syntaxe de message : spécifie la syntaxe des types de données échangées par le profil.

-   Sémantique de message : spécifie la sémantique des types de données échangées par le profil.

-   Informations de contact : spécifient les informations de contact postales et électroniques de l'auteur du profil.

 

5.2   Gabarit d'enregistrement de caractéristique

 

Lorsque on enregistre une caractéristique pour le profil de gestion de canal, on fournit les informations suivantes :

-   Identification de caractéristique : spécifie une chaîne qui identifie cette caractéristique. Sauf si la caractéristique est enregistrée auprès de l'IANA, l'identification de la caractéristique doit commencer par "x-".

-   Sémantique de caractéristique : spécifie la sémantique de la caractéristique.

-   Informations de contact : spécifient les informations de contact postales et électroniques de l'auteur de la caractéristique.

 

6.   Enregistrements initiaux

6.1   Enregistrement : Gestion de canal BEEP

 

-   Identification du profil : non applicable

-   Messages échangés durant la création de canal : non applicable

-   Messages commençant les échanges d'un à un : "start" ou "close"

-   Messages dans les réponses positives : "greeting", "profile", ou "ok"

-   Messages dans les réponses négatives : "error"

-   Messages dans les échanges de un à plusieurs : aucun

-   Syntaxe de message : voir au paragraphe 7.1

-   Sémantique de message : voir au paragraphe 2.3.1

-   Informations de contact : voir au paragraphe "Adresse de l'auteur" du présent mémoire.

 

6.2   Enregistrement : Profil de sécurité du transport TLS

 

-   Identification du profil : http://iana.org/beep/TLS

-   Messages échangés durant la création du canal : "ready"

-   Messages commençant les échanges d'un à un : "ready"

-   Messages dans les réponses positives : "proceed"

-   Messages dans les réponses négatives : "error"

-   Messages dans les échanges de un à plusieurs : aucun

-   Syntaxe de message : voir au paragraphe 7.2

-   Sémantique de message : voir au paragraphe 3.1.3

-   Informations de contact : voir au paragraphe "Adresse de l'auteur" du présent mémoire.

 

6.3   Enregistrement : Famille de profils SASL

 

-   Identification du profil : http://iana.org/beep/SASL/mechanism, où "mechanism" est un jeton enregistré à l'IANA

-   Messages échangés durant la création du canal : "blob"

-   Messages commençant les échanges d'un à un : "blob"

-   Messages dans les réponses positives : "blob"

-   Messages dans les réponses négatives : "error"

-   Messages dans les échanges de un à plusieurs : aucun

-   Syntaxe de message : voir au paragraphe 7.3

-   Sémantique de message : voir au paragraphe 4.1.3

-   Informations de contact : voir au paragraphe "Adresse de l'auteur" du présent mémoire.

 

6.4   Enregistrement : application/beep+xml

 

-   Type de support MIME : application

-   Nom de sous-type MIME : beep+xml

-   Paramètres exigés : aucun

-   Paramètres facultatifs : charset (jeu de caractères) (par défaut "UTF-8" [13])

-   Considérations sur le codage : Ce type de support peut avoir un contenu en binaire ; en conséquence, lorsque utilisé sur un transport qui ne permet pas le transfert en binaire, un codage approprié doit être appliqué.

-   Considérations pour la sécurité : aucune, en soi ; cependant, tout profil BEEP qui utilise ce type de support doit décrire ses considérations pertinentes pour la sécurité.

-   Considérations d'interopérabilité : non disponibles

-   Spécification publiée : Ce type de support est un sous-ensemble de la spécification XML 1.0 [2]. Deux restrictions sont apportées :

   aucune référence d'entité autre que les cinq références d'entité générales prédéfinies ("&amp;", "&lt;", "&gt;", "&apos;", et "&quot;") et les références d'entité numérique ne doit être présente.

   ni la déclaration "XML" (par exemple, <?xml version="1.0" ?>) ni la déclaration "DOCTYPE" (par exemple, <!DOCTYPE ...>) ne doit être présente. (Par conséquent, si on souhaite un autre jeu de caractères que UTF-8, le paramètre "charset"doit être présent.)

   Toutes les autres instructions XML 1.0 (par exemple, blocs CDATA, instructions de traitement, et ainsi de suite) sont permises.

-   Applications qui utilisent ce type de support : tout profil BEEP souhaitant utiliser ce sous-ensemble XML 1.0

-   Informations supplémentaires : aucune

-   Contact pour des informations supplémentaires : voir au paragraphe "Adresse de l'auteur" du présent mémoire.

-   Utilisation prévue : utilisation limitée

-   Contrôle d'auteur/modifications : IESG

 

7.   DTD

7.1   DTD de gestion de canal BEEP

 

<!-- DTD pour la gestion de canal BEEP, état au 29-10-2000

Référence à ce DTD :

<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN""http://xml.resource.org/profiles/BEEP/beep.dtd">

%BEEP;

-->

 

<!—Types de données DTD :

 

entité

syntaxe/référence

exemple

un numéro de canal : CHAN

1 à 2 147 483 647

1

identification de profil d'autorité : URI

voir [RFC-2396]

http://invisible.net/

un ou plusieurs jetons de caractéristique, séparés par une espace : FTRS

NMTOKENS

"magic"

étiquette de langue : LANG

voir [RFC-1766]

"fr", "en-US", etc.

zéro, une ou plusieurs étiquettes de langue : LOCS

NMTOKENS

"en-US"

code de réponse à trois chiffres : XYZ

[1-5][0-9][0-9]

500

-->

 

<!ENTITY % CHAN    "CDATA">

<!ENTITY % URI    "CDATA">

<!ENTITY % FTRS    "NMTOKENS">

<!ENTITY % LANG    "NMTOKEN">

<!ENTITY % LOCS   "NMTOKEN">

<!ENTITY % XYZ    "CDATA">

 

<!—messages BEEP échangés comme application/beep+xml

 

rôle

MSG

RPY

ERR

I et L

 

greeting

error

I ou L

start

profile

error

I ou L

close

ok

error

-->

 

<!ELEMENT greeting    (profile)*>

<!ATTLIST greeting

features    %FTRS;    #IMPLIED

localize    %LOCS;    "i-default">

 

<!ELEMENT start    (profile)+>

<!ATTLIST start

number    %CHAN;    #REQUIRED

serverName    CDATA    #IMPLIED>

 

<!—l'élément profile est vide si il est contenu dans l'accueil -->

<!ELEMENT profile    (#PCDATA)>

<!ATTLIST profile

uri    %URI;    #REQUIRED

encoding    (none|base64)    "none">

 

<!ELEMENT close    (#PCDATA)>

<!ATTLIST close

number   %CHAN;    "0"

code    %XYZ;    #REQUIRED

xml:lang    %LANG;    #IMPLIED>

 

<!ELEMENT ok    EMPTY>

 

<!ELEMENT error   (#PCDATA)>

<!ATTLIST error

code    %XYZ;    #REQUIRED

xml:lang    %LANG;    #IMPLIED>

 

7.2   DTD de profil de sécurité de transport TLS

 

<!-- DTD pour le profil de sécurité du transport TLS, état au 04-09-2000

Référence à ce DTD :

 

<!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN" "http://xml.resource.org/profiles/TLS/tls.dtd">

%TLS;

-->

 

<!—Messages TLS échangés comme application/beep+xml

 

rôle   MSG   RPY   ERR

I ou L   ready   proceed   error

-->

 

<!ELEMENT ready    EMPTY>

<!ATTLIST ready

version   CDATA   "1">

 

<!ELEMENT proceed    EMPTY>

 

7.3   DTD de famille de profils SASL

 

<!-- DTD pour la famille de profils SASL, état au 04-09-2000

 

Référence de ce DTD :

<!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN" "http://xml.resource.org/profiles/sasl/sasl.dtd">

%SASL;

-->

 

<!—Messages SASL échangés comme application/beep+xml

 

rôle   MSG   RPY   ERR

I ou L   blob   blob   error

-->

 

<!ELEMENT blob   (#PCDATA)>

<!ATTLIST blob

   xml:space    (default|preserve)    "preserve"

   status   (abort|complete|continue)    "continue">

 

8.   Codes de réponse

 

code   signification

200   réussite

421   service non disponible

450   action demandée non effectuée (par exemple, verrouillage déjà utilisé)

451   action demandée interrompue (par exemple, erreur locale de traitement)

454   échec temporaire d'authentification

500   erreur générale de syntaxe (par exemple, XML mal formé)

501   erreur de syntaxe dans les paramètres (par exemple, XML non valide)

504   paramètre non mis en œuvre

530   authentification exigée

534   mécanisme d'authentification insuffisant (par exemple, trop faible, débordement de séquence, etc.)

535   échec d'authentification

537   action non autorisée pour l'utilisateur

538   le mécanisme d'authentification exige le chiffrement

550   action demandée non effectuée (par exemple, aucun des profils demandés n'est acceptable)

553   paramètre invalide

554   échec de transaction (par exemple, violation de politique)

 

9.   Considérations pour la sécurité

 

Le mécanisme de mise en trame BEEP ne fournit par lui-même aucune protection contre les attaques ; cependant, une utilisation judicieuse des profils de réglage initial procure des degrés d'assurance variés :

 

1.   Si un des profils de la famille SASL est utilisé, se reporter à la Section 9 de [4] pour un exposé sur les considérations sur la sécurité.

2.   Si le profil de sécurité du transport TLS est utilisé (ou si une couche de sécurité SASL est négociée) alors :

1.   Une attaque par interposition peut retirer les profils en rapport avec la sécurité de l'accueil BEEP ou générer une réplique négative à l'élément "ready" du profil de sécurité du transport TLS . Un homologue BEEP peut être configurable à refuser de continuer sans un niveau de confidentialité acceptable.

2.   Une attaque par interposition peut être cause qu'une négociation aboutisse à la plus faible suite de chiffrement disponible. Un homologue BEEP devrait être configurable à refuser les suites de chiffrement faibles.

3.   Une attaque par interposition peut modifier tout échange de protocole avant une négociation réussie. À l'achèvement de la négociation, un homologue BEEP doit éliminer les informations sur la session BEEP mises antérieurement en antémémoire.

 

Comme les différentes suites de chiffrement TLS fournissent des niveaux de sécurité variés, les administrateurs devraient faire attention au choix des suites de chiffrement qui leur sont proposées.

 

Comme BEEP est par nature d'homologue à homologue, avant d'effectuer aucune tâche associée à un message, chaque canal devrait appliquer le contrôle d'accès approprié sur la base de l'identité authentifiée et du niveau de confidentialité associés à la session BEEP.

 

Références

(Les liens dans le corps du titre pointent sur la version française, ceux du numéro sur la version anglaise.)

[1]   N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", RFC 2045, novembre 1996.

[2]   World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, février 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.

[3]   T. Dierks et C. Allen, "Protocole TLS version 1.0", RFC 2246, janvier 1999. (Obsolète, voir RFC4346)

[4]   J. Myers, "Authentification simple et couche de sécurité (SASL)",) RFC 2222, octobre 1997. (Obsolète, voirRFC4422, RFC4752) (MàJ parRFC2444) (P.S.).

[5]   M. Rose, "Transposition du cœur BEEP en TCP", RFC 3081, mars 2001. (P.S.)

[6]   J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", RFC 793, (STD 7), septembre 1981.

[7]   D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 2234, novembre 1997.

[8]   R. Elz, R. Bush, "Arithmétique des numéros de série ", RFC 1982, août 1996. (MàJ RFC1034, RFC1035) (P.S.)

[9]   H. Alvestrand, "Étiquettes pour l'identification des langues", RFC 3066, BCP 47, janvier 2001. (Obsolète, voir 4646)

[10]   T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", RFC 2396, août 1998. (Obsolète, voir RFC3986,)

[11]   C. Newman, "Mécanisme SASL de mot de passe à utilisation unique", RFC 2444, octobre 1998. (P.S.)

[12]   S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", RFC 2401, novembre 1998.

[13]   F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", RFC 2279, janvier 1998. (Obsolète, voirRFC3629) (D.S.)

[14]   J. Linn, "Interface générique de programme d'application de service de sécurité, version 2", RFC 2078, janvier 1997. (Rendue obsolète par la RFC 2743.)

[15]   <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>

 

Adresse de l'auteur

 

Marshall T. Rose

Invisible Worlds, Inc.

1179 North McDowell Boulevard

Petaluma, CA 94954-6559

USA

téléphone : +1 707 789 3700

mél : mrose@invisible.net

URI : http://invisible.net/

 

Appendice A.   Remerciements

 

L'auteur remercie chaleureusement de leurs contributions David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods et James Woodyatt. En particulier, Dave Crocker a fourni des suggestions utiles sur la nature de la segmentation dans le mécanisme de tramage.

 

Appendice B.   Considérations relatives à l'IANA

 

L'IANA enregistre "beep" comme un nom de service GSSAPI [14], comme spécifié au paragraphe 4.1.

 

L'IANA tient une liste de :

o   profils BEEP en cours de normalisation, voir au paragraphe 5.1 ;

o   des caractéristiques en cours de normalisation pour le profil de gestion de canal, voir au paragraphe 5.2.

 

Pour chaque liste, l'IESG est chargé de désigner un expert pour revoir la spécification avant que l'IANA n'effectue l'allocation. Par courtoisie à l'égard des développeurs de profils et caractéristiques de gestions de canal BEEP qui ne sont pas en cours de normalisation, la liste de diffusion bxxpwg@invisible.net peut être utilisée pour solliciter des commentaires.

 

L'IANA effectue les enregistrements spécifiés aux paragraphes 6.2 et 6.3. Il est recommandé que l'IANA enregistre ces profils en utilisant "IANA" comme préfixe d'URI, et remplisse ces URI avec les profils d'enregistrement respectifs.

 

Déclaration de droits de reproduction

 

Copyright (C) The Internet Society (2000). Tous droits réservé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 copyright ci-dessus et le présent paragraphe soient inclus dans toutes 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 copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de copyright 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 y contenues sont fournies 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 ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

 

Remerciement

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