2. Overview (Panoramica)

Gli endpoint che intendono impostare una sessione multimediale RTP lo fanno scambiando offerte e risposte in messaggi SDP su SIP. In un caso d'uso tipico, due endpoint negozierebbero di trasportare dati audio su RTP usando il protocollo UDP.

La figura 1 mostra un tipico scambio di messaggi nel trapezio SIP.

          +-----------+            +-----------+
          |SIP        |   SIP/SDP  |SIP        |
  +------>|Proxy      |----------->|Proxy      |-------+
  |       |Server X   | (+finger-  |Server Y   |       |
  |       +-----------+   print,   +-----------+       |
  |                      +auth.id.)                    |
  | SIP/SDP                              SIP/SDP       |
  | (+fingerprint)                       (+fingerprint,|
  |                                       +auth.id.)   |
  |                                                    |
  |                                                    v

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

Legenda: ------>: Traffico di segnalazione <-+-+->: Traffico di gestione delle chiavi <=====>: Traffico dati

          Figura 1: Uso di DTLS nel trapezio SIP

Si consideri Alice che vuole stabilire una sessione audio crittografata con Bob. Sia Bob sia Alice possono usare autenticazione a chiave pubblica per stabilire un canale protetto in riservatezza mediante DTLS.

Poiché l'autenticazione reciproca tra due endpoint arbitrari su Internet con crittografia a chiave pubblica tende a essere problematica, consideriamo alternative più adatte al dispiegamento. Questo documento ne adotta un approccio; altri sono discussi nella sezione 8.

Alice invia un'offerta SDP a Bob tramite SIP. Se Alice usa solo certificati autofirmati per la comunicazione con Bob, nell'scambio offerta/risposta SDP è inclusa un'impronta (fingerprint). Tale impronta lega lo scambio di chiavi DTLS nel piano media al piano di segnalazione.

L'impronta da sola protegge da attacchi attivi sul media, non da attacchi attivi sulla segnalazione. Per impedire attacchi attivi sulla segnalazione si può usare «Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)» [RFC4474]. Quando Bob riceve l'offerta, i peer stabiliscono un certo numero di connessioni DTLS (in funzione del numero di sessioni media) con autenticazione DTLS reciproca (cioè entrambe le parti presentano certificati). A questo punto Bob può verificare che le credenziali di Alice offerte in TLS corrispondano all'impronta nell'offerta SDP e Bob può iniziare a inviare media ad Alice. Una volta che Bob accetta l'offerta di Alice e invia una risposta SDP ad Alice, Alice può iniziare a inviare media riservati a Bob sui flussi appropriati. Alice e Bob verificheranno che le impronte dei certificati ricevuti durante gli handshake DTLS coincidano con le impronte ricevute nel SDP della segnalazione SIP. Ciò fornisce la proprietà di sicurezza per cui Alice sa che il traffico media va a Bob e viceversa, senza richiedere necessariamente certificati PKI globali per Alice e Bob. (Analisi di sicurezza dettagliata nella sezione 8.)