5. Establishing a Secure Channel (Canale sicuro)

I due endpoint dello scambio presentano le proprie identità nella procedura di handshake DTLS usando certificati. Questo documento usa certificati nello stesso stile descritto in «Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)» [RFC4572].

Se si usano certificati autofirmati, il contenuto dell'attributo subjectAltName nel certificato MAY usare l'URI (uniform resource identifier) dell'utente. Ciò serve solo a fini di debug e non è richiesto per legare il certificato a uno degli endpoint di comunicazione. L'integrità del certificato è garantita dall'attributo fingerprint nell'SDP. Il subjectAltName non è un componente importante della verifica del certificato.

La generazione di coppie di chiavi pubblica/privata è relativamente onerosa. Gli endpoint non sono tenuti a generare certificati per ogni sessione.

Il modello offer/answer, definito in [RFC3264], è usato da protocolli come il Session Initiation Protocol (SIP) [RFC3261] per impostare sessioni multimediali. Oltre al contenuto usuale di un messaggio SDP [RFC4566], ogni descrizione media (riga « m= » e parametri associati) conterrà anche diversi attributi come specificato in [RFC5764], [RFC4145] e [RFC4572].

Quando un endpoint desidera impostare una sessione media sicura con un altro endpoint, invia un'offerta in un messaggio SIP all'altro endpoint. L'offerta include, nel payload SDP, l'impronta del certificato che l'endpoint intende usare. L'endpoint SHOULD inviare il messaggio SIP contenente l'offerta al proxy SIP dell'offerente su un canale protetto in integrità. Il proxy SHOULD aggiungere un campo intestazione Identity secondo le procedure di [RFC4474]. Il messaggio SIP contenente l'offerta SHOULD essere inviato al proxy SIP dell'offerente su un canale protetto in integrità. Quando l'endpoint remoto riceve il messaggio SIP, può verificare l'identità del mittente tramite il campo intestazione Identity. Poiché il campo Identity è una firma digitale su diversi campi intestazione SIP, oltre al corpo del messaggio SIP, il ricevente può anche essere certo che il messaggio non sia stato manomesso dopo l'applicazione della firma digitale e il suo inserimento nel messaggio SIP.

L'endpoint remoto (answerer) può ora stabilire un'associazione DTLS con l'offerente. In alternativa può indicare nella propria risposta che l'offerente deve iniziare l'associazione TLS. In ogni caso si userà autenticazione DTLS reciproca basata su certificati. Completato l'handshake DTLS, informazioni sulle identità autenticate, inclusi i certificati, sono rese disponibili all'applicazione dell'endpoint. L'answerer può quindi verificare che il certificato dell'offerente usato per l'autenticazione nell'handshake DTLS sia associabile all'impronta del certificato contenuta nell'offerta SDP. A questo punto l'answerer può indicare all'utente finale che il media è protetto. L'offerente può accettare solo provvisoriamente il certificato dell'answerer poiché potrebbe non avere ancora l'impronta del certificato dell'answerer.

Quando l'answerer accetta l'offerta, fornisce una risposta all'offerente contenente l'impronta del certificato dell'answerer. A questo punto l'offerente può accettare o rifiutare il certificato del peer e indicare all'utente finale che il media è protetto.

Si noti che l'intera autenticazione e lo scambio di chiavi per proteggere il traffico media avvengono nel percorso media tramite DTLS. Il percorso di segnalazione serve solo a verificare le impronte dei certificati dei peer.

L'offerta e la risposta MUST soddisfare i seguenti requisiti.

o L'endpoint MUST usare l'attributo setup definito in [RFC4145]. L'endpoint offerente MUST usare il valore di attributo setup:actpass ed essere pronto a ricevere un client_hello prima di ricevere la risposta. L'answerer MUST usare setup:active oppure setup:passive. Si noti che se l'answerer usa setup:passive, l'handshake DTLS non inizia finché non è stata ricevuta la risposta dell'answerer, con latenza aggiuntiva. setup:active consente risposta e handshake DTLS in parallelo. Pertanto setup:active è RECOMMENDED. La parte attiva MUST avviare un handshake DTLS inviando un ClientHello su ogni flusso (quartetto host/porta).

o L'endpoint MUST NOT usare l'attributo connection definito in [RFC4145].

o L'endpoint MUST usare l'attributo fingerprint del certificato come specificato in [RFC4572].

o Il certificato presentato durante l'handshake DTLS MUST corrispondere all'impronta scambiata tramite il percorso di segnalazione nell'SDP. Le proprietà di sicurezza di questo meccanismo sono descritte nella sezione 8.

o Se l'impronta non corrisponde al certificato sottoposto a hash, l'endpoint MUST smantellare immediatamente la sessione media. È lecito attendere la ricezione dell'impronta dell'altra parte prima di stabilire la connessione; ciò può però avere effetti di latenza indesiderati.