Aller au contenu principal

12. Considérations de sécurité (Security Considerations)

Étant donné que les fonctionnalités d'apparence de ligne multiple sont mises en œuvre à l'aide de la sémantique fournie par SIP [RFC3261], le package d'événements SIP pour l'état de dialogue [RFC4235], et le framework d'événements SIP [RFC6665] et [RFC3903], les considérations de sécurité de ces documents s'appliquent également à ce document.

Pour assurer la confidentialité, les corps de messages NOTIFY ou PUBLISH qui fournissent les informations d'état de dialogue et les identificateurs de dialogue PEUVENT (MAY) être chiffrés de bout en bout en utilisant les mécanismes standard tels que S/MIME décrit dans [RFC3261]. Alternativement, l'envoi des requêtes NOTIFY et PUBLISH via TLS fournit également la confidentialité, bien que sur une base de saut par saut. Tous les SUBSCRIBE et PUBLISH entre les UA et l'agent d'apparence DOIVENT (MUST) être authentifiés. Sans authentification et confidentialité appropriées, un tiers pourrait apprendre des informations sur les dialogues associés à un AOR et pourrait essayer d'utiliser ces informations pour détourner ou manipuler ces dialogues en utilisant des primitives de contrôle d'appel SIP.

Cette fonctionnalité repose sur des primitives de contrôle d'appel SIP standard telles que Replaces et Join. Des contrôles d'accès appropriés sur leur utilisation DOIVENT (MUST) être utilisés afin que seuls les membres du groupe d'apparence partagée puissent utiliser ces mécanismes. Tous les INVITE avec des champs d'en-tête Replaces ou Join NE DOIVENT (MUST) être acceptés que si le pair demandant le remplacement ou la jonction du dialogue a été correctement authentifié à l'aide d'un mécanisme SIP standard (tel que Digest ou S/MIME) et autorisé à demander un remplacement. Sinon, un tiers pourrait perturber ou détourner les dialogues existants dans le groupe d'apparence partagée.

Pour un appel d'urgence, un UA NE DOIT PAS (MUST NOT) attendre une saisie confirmée d'une apparence avant d'envoyer un INVITE. Attendre la confirmation pourrait par inadvertance retarder ou bloquer l'appel d'urgence, qui par sa nature doit être placé aussi rapidement que possible. Au lieu de cela, un appel d'urgence DOIT (MUST) se poursuivre quel que soit le statut de la transaction PUBLISH.