5. Établissement d'un canal sécurisé
Les deux extrémités de l'échange présentent leurs identités dans la procédure de poignée de main DTLS au moyen de certificats. Ce document utilise des certificats sur le même modèle que « Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) » [RFC4572].
Si des certificats auto-signés sont utilisés, le contenu de l'attribut subjectAltName dans le certificat MAY utiliser l'URI (uniform resource identifier) de l'utilisateur. Cela sert uniquement au débogage et n'est pas requis pour lier le certificat à l'une des extrémités de communication. L'intégrité du certificat est assurée par l'attribut fingerprint dans le SDP. Le subjectAltName n'est pas un composant important de la vérification du certificat.
La génération de paires de clés publique/privée est relativement coûteuse. Les extrémités ne sont pas tenues de générer des certificats pour chaque session.
Le modèle offre/réponse, défini dans [RFC3264], est utilisé par des protocoles comme le Session Initiation Protocol (SIP) [RFC3261] pour établir des sessions multimédias. En plus du contenu habituel d'un message SDP [RFC4566], chaque description de média (ligne « m= » et paramètres associés) contiendra également plusieurs attributs comme spécifié dans [RFC5764], [RFC4145] et [RFC4572].
Lorsqu'une extrémité souhaite établir une session média sécurisée avec une autre, elle envoie une offre dans un message SIP à l'autre extrémité. Cette offre inclut, dans la charge utile SDP, l'empreinte du certificat que l'extrémité entend utiliser. L'extrémité SHOULD envoyer le message SIP contenant l'offre au proxy SIP de l'offreur sur un canal protégé en intégrité. Le proxy SHOULD ajouter un champ d'en-tête Identity selon les procédures de [RFC4474]. Le message SIP contenant l'offre SHOULD être envoyé au proxy SIP de l'offreur sur un canal protégé en intégrité. Lorsque l'extrémité distante reçoit le message SIP, elle peut vérifier l'identité de l'émetteur grâce au champ d'en-tête Identity. Comme le champ Identity est une signature numérique sur plusieurs champs d'en-tête SIP, en plus du corps du message SIP, le récepteur peut aussi être certain que le message n'a pas été altéré après l'application de la signature numérique et son ajout au message SIP.
L'extrémité distante (répondant) peut maintenant établir une association DTLS avec l'offreur. Sinon, elle peut indiquer dans sa réponse que l'offreur doit initier l'association TLS. Dans les deux cas, l'authentification mutuelle DTLS par certificat sera utilisée. Après la fin de la poignée de main DTLS, des informations sur les identités authentifiées, y compris les certificats, sont mises à disposition de l'application de l'extrémité. Le répondant peut alors vérifier que le certificat de l'offreur utilisé pour l'authentification dans la poignée de main DTLS peut être associé à l'empreinte du certificat contenue dans l'offre SDP. À ce stade, le répondant peut indiquer à l'utilisateur final que le média est sécurisé. L'offreur ne peut accepter que provisoirement le certificat du répondant car il peut ne pas encore disposer de l'empreinte du certificat du répondant.
Lorsque le répondant accepte l'offre, il renvoie une réponse à l'offreur contenant l'empreinte du certificat du répondant. À ce moment, l'offreur peut accepter ou rejeter le certificat du pair et indiquer à l'utilisateur final que le média est sécurisé.
Notez que l'ensemble de l'authentification et de l'échange de clés pour sécuriser le trafic média est traité dans le chemin média via DTLS. Le chemin de signalisation sert uniquement à vérifier les empreintes des certificats des pairs.
L'offre et la réponse MUST respecter les exigences suivantes.
o L'extrémité MUST utiliser l'attribut setup défini dans [RFC4145]. L'extrémité qui est l'offreur MUST utiliser la valeur d'attribut setup:actpass et être prête à recevoir un client_hello avant de recevoir la réponse. Le répondant MUST utiliser soit setup:active soit setup:passive. Notez que si le répondant utilise setup:passive, la poignée de main DTLS ne commence pas avant réception de la réponse du répondant, ce qui ajoute de la latence. setup:active permet la réponse et la poignée de main DTLS en parallèle. Ainsi, setup:active est RECOMMENDED. La partie active MUST initier une poignée de main DTLS en envoyant un ClientHello sur chaque flux (quartet hôte/port).
o L'extrémité MUST NOT utiliser l'attribut connection défini dans [RFC4145].
o L'extrémité MUST utiliser l'attribut d'empreinte de certificat tel que spécifié dans [RFC4572].
o Le certificat présenté pendant la poignée de main DTLS MUST correspondre à l'empreinte échangée via le chemin de signalisation dans le SDP. Les propriétés de sécurité de ce mécanisme sont décrites à la section 8.
o Si l'empreinte ne correspond pas au certificat haché, l'extrémité MUST immédiatement démanteler la session média. Notez qu'il est permis d'attendre la réception de l'empreinte de l'autre côté avant d'établir la connexion; cela peut toutefois avoir des effets de latence indésirables.