8. Considérations de sécurité
Le média DTLS ou TLS signalé avec SIP exige un moyen de garantir que les certificats des pairs sont corrects.
La stratégie TLS/DTLS standard pour authentifier les parties est de doter le serveur (et optionnellement le client) d'un certificat PKIX [RFC5280]. Le client vérifie le certificat et contrôle que le nom correspond au nom de domaine du serveur. Cela fonctionne car il y a relativement peu de serveurs aux noms bien définis; ce n'est généralement pas le cas en contexte VoIP.
La conception de ce document entend tirer parti de l'authenticité du canal de signalisation (sans exiger la confidentialité). Tant que chaque côté peut vérifier l'intégrité du SDP reçu de l'autre, la poignée de main DTLS ne peut pas être détournée par une attaque de l'homme du milieu. Cette protection d'intégrité est aisément fournie de l'appelant vers l'appelé (Alice vers Bob, section 7) via SIP Identity [RFC4474]. D'autres mécanismes, comme S/MIME dans la RFC 3261, ou de futurs mécanismes, pourraient aussi jouer ce rôle.
Sans de tels mécanismes d'intégrité, la sécurité se limite à la défense contre une attaque passive des intermédiaires. Une attaque active sur la signalisation combinée à une attaque active sur le plan média peut permettre d'attaquer la connexion (R-SIG-MEDIA dans la notation de [RFC5479]).
8.1. Identité du répondant
SIP Identity ne prend pas en charge les signatures dans les réponses. Idéalement, Alice voudrait savoir que le SDP de Bob n'a pas été altéré et d'où il provient, pour que l'UA d'Alice indique un appel sécurisé vers Bob. [RFC4916] définit une approche par laquelle un UA fournit son identité à l'UA pair, signée par un service d'authentification. Par exemple, Bob envoie une réponse puis un UPDATE immédiat avec l'empreinte et SIP Identity pour affirmer que le message provient de [email protected]. L'inconvénient est le aller-retour supplémentaire de l'UPDATE. C'est toutefois simple et sûr même si tous les proxys ne sont pas de confiance; Bob n'a qu'à faire confiance à son proxy. Les offreurs SHOULD prendre en charge ce mécanisme et les répondants SHOULD l'utiliser.
Dans certains cas les répondants n'envoient pas d'UPDATE et, dans de nombreux appels, du média est envoyé avant la réception de l'UPDATE. Alors l'intégrité de l'empreinte de Bob vers Alice n'est pas assurée. Un attaquant sur le chemin de signalisation pourrait altérer l'empreinte et s'insérer en MITM sur le média. Alice saurait qu'elle a un appel sécurisé avec quelqu'un, pas si c'est Bob ou un MITM. Bob saurait qu'une attaque se produit. Le fait qu'un côté détecte l'attaque fait qu'en général, si Alice et Bob veulent le chiffrement, il n'y a pas de problème. Rappel: Bob pourrait toujours révéler le média reçu. On suppose que Bob veut aussi des communications sécurisées. Sans action, Bob sait que le média n'a pas été altéré ou intercepté par un tiers et qu'il provient d'[email protected]. Alice sait parler à quelqu'un qui a probablement vérifié l'absence d'interception ou d'altération. C'est imparfait mais utilisable dans beaucoup de cas.
8.2. SIPS
Sans SIP Identity mais avec signalisation protégée par SIPS, les garanties sont plus faibles. Une certaine sécurité subsiste si tous les proxys sont de confiance, avec intégrité de l'empreinte dans un modèle chaîne de confiance. Si les proxys ne sont pas de confiance, le niveau de sécurité reste limité.
8.3. S/MIME
La RFC 3261 [RFC3261] définit S/MIME pour SIP, utilisable pour signer que l'empreinte provient de Bob. Ce serait sûr.
8.4. Continuité de l'authentification
Une propriété souhaitable est la continuité de l'authentification: garantir cryptographiquement que l'on parle à la même personne qu'avant. Avec DTLS, on l'obtient en réutilisant la même clé publique/certificat auto-signé pour chaque connexion (au moins avec un pair donné). On peut mettre en cache l'identifiant (ou son hachage) et vérifier qu'il ne change pas. Après une première connexion sûre, un canal futur peut être établi même avec une signalisation ultérieure non sûre.
Pour la continuité, les implémentations SHOULD viser une clé à long terme stable. Les implémentations qui vérifient SHOULD conserver un cache de la clé par identité de pair et alerter l'utilisateur si elle change.
8.5. Chaîne d'authentification courte (Short Authentication String)
Alternative: Alice et Bob utilisent la parole pour vérifier l'identité puis comparent les empreintes à l'oral. Si imiter la voix et modifier l'audio de l'appel est difficile, l'approche est relativement sûre. Elle serait inefficace pour vidéo ou messagerie instantanée. DTLS permet ce mode. La longueur minimale d'empreinte sûre est d'environ 64 bits.
ZRTP [AVT-ZRTP] inclut le mode Short Authentication String (SAS) avec une chaîne de bits propre à chaque connexion issue de la poignée de main. Le SAS peut faire seulement 25 bits et est plus facile à lire. DTLS ne le supporte pas nativement. Selon l'intérêt de déploiement, une extension TLS [RFC5246] pourrait l'ajouter. Les schémas SAS supposent souvent que les extrémités se reconnaissent à la voix, ce qui n'est pas vrai partout (p. ex. centres d'appels).
8.6. Limites des assertions d'identité
Avec la RFC 4474 pour lier le matériel de clé média à la signalisation SIP, les garanties sur la provenance et la sécurité du média ne sont pas meilleures que celles de la signalisation. Deux cas importants:
o La RFC 4474 suppose que le proxy avec le certificat « example.com » contrôle l'espace de noms « example.com ». Le service d'authentification autoritatif pour un espace de noms peut donc décider quel utilisateur porte quel nom. Il peut transférer une adresse d'Alice vers Bob: c'est une caractéristique voulue de la RFC 4474 et une conséquence de l'architecture d'espace de noms SIP.
o Avec des URI de numéro de téléphone (p. ex. « sip:[email protected] » ou « sip:[email protected];user=phone »), il n'y a pas de raison structurelle de croire que le domaine est autoritatif pour le numéro, même si des proxys et UA peuvent avoir des accords privés. C'est structurel: le PSTN est supposé assert correctement les numéros sans notion claire d'entité autoritative pour un espace numérique.
Dans les deux cas, les assurances DTLS-SRTP sur l'intégrité d'origine et la confidentialité ne peuvent pas dépasser celles de SIP pour l'intégrité de signalisation avec la RFC 4474. Les implémentations ne doivent pas indiquer une identité de pair trompeuse dans l'UI. Si l'identité est sip:[email protected], afficher seulement +17005551008 ne suffit pas sans politique indiquant que « chicago.example.com » est autorisé à assert ces numéros E.164. Si l'UA conclut clairement à un numéro E.164, il peut être moins confus d'indiquer un appel chiffré vers un pair inconnu.
De plus, certaines middleboxes (B2BUA, SBC) modifient des parties du message SIP incluses dans le calcul de signature RFC 4474, cassant la signature. C'est précisément ce que RFC 4474 doit détecter. Si la middlebox peut produire des signatures RFC 4474 valides (même domaine administratif que le service d'authentification), elle peut signer le message modifié, ou une autre identité qu'elle peut assert. Sinon, le destinataire ne peut pas se fier à l'assertion Identity et l'UA MUST NOT indiquer un appel sécurisé vers l'identité revendiquée. Les implémentations configurées pour n'accepter que des appels sécurisés SHOULD raccrocher dans ce cas.
Sans SIP Identity ou équivalent, on n'a que la protection contre les attaquant qui ne peuvent pas modifier activement la signalisation. C'est mieux qu'avant, mais inférieur à une signalisation à intégrité assurée.
8.7. Certificats tiers
Cette spécification n'exige pas que les certificats des extrémités soient vérifiables indépendamment (p. ex. par une tierce partie de confiance). Rien n'interdit de tels certificats. Mis à part la difficulté à les obtenir, les identités qu'ils porteraient ne sont pas claires: la RFC 3261 fixe une convention S/MIME peu déployée. Dans des contextes fermés ou semi-fermés où une convention existe, les certificats tiers peuvent réduire la dépendance vis-à-vis même des proxys du domaine de l'extrémité.
8.8. Secret parfait en avant (Perfect Forward Secrecy)
Une clé à long terme compromise pourrait exposer les communications passées. Pour l'éviter, DTLS offre des modes avec PFS via des suites Diffie-Hellman et courbes elliptiques. Avec ces modes, le système résiste à de telles attaques. La compromission d'une clé à long terme peut toutefois permettre des attaques actives futures. Si c'est un problème, utiliser un canal d'authentification de secours (empreinte manuelle ou chaîne d'authentification courte).