2. Vue d'ensemble

Les extrémités qui souhaitent établir une session média RTP le font en échangeant des offres et des réponses dans des messages SDP sur SIP. Dans un cas d'usage typique, deux extrémités négocieraient pour transporter des données audio sur RTP en utilisant le protocole UDP.

La figure 1 illustre un échange de messages typique dans le trapèze SIP.

          +-----------+            +-----------+
          |SIP        |   SIP/SDP  |SIP        |
  +------>|Proxy      |----------->|Proxy      |-------+
  |       |Server X   | (+emprein- |Server Y   |       |
  |       +-----------+   te,      +-----------+       |
  |                      +auth.id.)                    |
  | SIP/SDP                              SIP/SDP       |
  | (+empreinte)                         (+empreinte,  |
  |                                       +auth.id.)   |
  |                                                    |
  |                                                    v

+-----------+ Datagram TLS +-----------+ |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | |User Agent | Media |User Agent | |Alice@X | <=================================> |Bob@Y | +-----------+ +-----------+

Légende: ------>: Trafic de signalisation <-+-+->: Trafic de gestion des clés <=====>: Trafic de données

          Figure 1: Utilisation de DTLS dans le trapèze SIP

Imaginons qu'Alice souhaite établir une session audio chiffrée avec Bob. Bob et Alice peuvent tous deux utiliser une authentification à clé publique afin d'établir un canal protégé en confidentialité au moyen de DTLS.

Comme l'authentification mutuelle entre deux extrémités arbitraires sur Internet par cryptographie à clé publique tend à poser problème, nous envisageons des alternatives plus faciles à déployer. Ce document en adopte une approche; d'autres sont discutées à la section 8.

Alice envoie une offre SDP à Bob via SIP. Si Alice n'utilise que des certificats auto-signés pour communiquer avec Bob, une empreinte (fingerprint) est incluse dans l'échange d'offre/réponse SDP. Cette empreinte lie l'échange de clés DTLS dans le plan média au plan de signalisation.

L'empreinte seule protège contre les attaques actives sur le média, pas contre les attaques actives sur la signalisation. Pour empêcher les attaques actives sur la signalisation, on peut utiliser « Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) » [RFC4474]. Lorsque Bob reçoit l'offre, les pairs établissent un certain nombre de connexions DTLS (selon le nombre de sessions média) avec authentification DTLS mutuelle (c'est-à-dire que les deux côtés présentent des certificats). À ce stade, Bob peut vérifier que les informations d'identité d'Alice offertes dans TLS correspondent à l'empreinte dans l'offre SDP, et Bob peut commencer à envoyer du média à Alice. Une fois que Bob accepte l'offre d'Alice et envoie une réponse SDP à Alice, Alice peut commencer à envoyer du média confidentiel à Bob sur les flux appropriés. Alice et Bob vérifieront que les empreintes des certificats reçues lors des poignées de main DTLS correspondent aux empreintes reçues dans le SDP de la signalisation SIP. Cela fournit la propriété de sécurité suivante: Alice sait que le trafic média va à Bob et inversement, sans nécessiter de certificats d'infrastructure à clés publiques (PKI) globaux pour Alice et Bob. (Voir la section 8 pour une analyse de sécurité détaillée.)