5. Establishing a Secure Channel (Sicherer Kanal)
Die beiden Endpunkte des Austauschs präsentieren ihre Identitäten im Rahmen des DTLS-Handshakes mittels Zertifikaten. Dieses Dokument nutzt Zertifikate im gleichen Stil wie in „Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)“ [RFC4572] beschrieben.
Bei selbstsignierten Zertifikaten MAY der Inhalt des Attributs subjectAltName im Zertifikat die URI des Nutzers verwenden. Dies dient nur Debugging-Zwecken und ist nicht erforderlich, um das Zertifikat an einen der Kommunikationsendpunkte zu binden. Die Integrität des Zertifikats wird über das Fingerprint-Attribut im SDP sichergestellt. Das subjectAltName ist kein wesentlicher Bestandteil der Zertifikatsprüfung.
Die Erzeugung öffentlicher/privater Schlüsselpaare ist relativ teuer. Endpunkte müssen nicht für jede Sitzung Zertifikate erzeugen.
Das Offer/Answer-Modell aus [RFC3264] wird von Protokollen wie dem Session Initiation Protocol (SIP) [RFC3261] zum Aufbau von Multimedia-Sitzungen genutzt. Zusätzlich zum üblichen Inhalt einer SDP-[RFC4566]-Nachricht enthält jede Medienbeschreibung („m=“-Zeile und zugehörige Parameter) mehrere Attribute gemäß [RFC5764], [RFC4145] und [RFC4572].
Wenn ein Endpunkt eine sichere Mediensitzung mit einem anderen aufbauen will, sendet er ein Angebot in einer SIP-Nachricht an den anderen Endpunkt. Dieses Angebot enthält in der SDP-Nutzlast den Fingerprint des Zertifikats, das der Endpunkt nutzen will. Der Endpunkt SHOULD die SIP-Nachricht mit dem Angebot an den SIP-Proxy des Offerers über einen integritätsgeschützten Kanal senden. Der Proxy SHOULD ein Identity-Kopffeld gemäß [RFC4474] hinzufügen. Die SIP-Nachricht mit dem Angebot SHOULD an den SIP-Proxy des Offerers über einen integritätsgeschützten Kanal gesendet werden. Wenn der entfernte Endpunkt die SIP-Nachricht erhält, kann er die Identität des Absenders über das Identity-Kopffeld prüfen. Da das Identity-Kopffeld eine digitale Signatur über mehrere SIP-Kopffelder sowie den SIP-Nachrichtenkörper ist, kann der Empfänger auch sicher sein, dass die Nachricht nach Anwendung der digitalen Signatur und Hinzufügen zur SIP-Nachricht nicht manipuliert wurde.
Der entfernte Endpunkt (Answerer) kann nun eine DTLS-Assoziation mit dem Offerer aufbauen. Alternativ kann er in seiner Antwort angeben, dass der Offerer die TLS-Assoziation initiiert. In beiden Fällen wird gegenseitige DTLS-Zertifikatsauthentifizierung genutzt. Nach Abschluss des DTLS-Handshakes werden Informationen über die authentifizierten Identitäten, einschließlich der Zertifikate, der Endpunktanwendung zur Verfügung gestellt. Der Answerer kann dann prüfen, dass das für die Authentifizierung im DTLS-Handshake verwendete Zertifikat des Offerers mit dem im SDP-Angebot enthaltenen Zertifikatsfingerprint verknüpft werden kann. Zu diesem Zeitpunkt kann der Answerer dem Endnutzer mitteilen, dass die Medien gesichert sind. Der Offerer kann das Zertifikat des Answerers nur vorläufig akzeptieren, da er den Fingerprint des Answerer-Zertifikats noch nicht haben kann.
Wenn der Answerer das Angebot annimmt, liefert er eine Antwort an den Offerer zurück, die den Fingerprint des Answerer-Zertifikats enthält. Jetzt kann der Offerer das Peer-Zertifikat annehmen oder ablehnen und dem Endnutzer mitteilen, dass die Medien gesichert sind.
Die gesamte Authentifizierung und der Schlüsselaustausch zum Schutz des Medienverkehrs laufen im Medienpfad über DTLS ab. Der Signalisierungspfad dient nur dazu, die Zertifikatsfingerprints der Peers zu prüfen.
Angebot und Antwort MUST folgende Anforderungen erfüllen.
o Der Endpunkt MUST das in [RFC4145] definierte setup-Attribut verwenden. Der Offerer-Endpunkt MUST den setup-Wert setup:actpass nutzen und darauf vorbereitet sein, ein client_hello zu empfangen, bevor die Antwort eintrifft. Der Answerer MUST entweder setup:active oder setup:passive verwenden. Wenn der Answerer setup:passive nutzt, beginnt der DTLS-Handshake erst nach Eingang der Antwort des Answerers, was zusätzliche Latenz bedeutet. setup:active erlaubt parallele Antwort und DTLS-Handshake. Daher ist setup:active RECOMMENDED. Die aktive Seite MUST den DTLS-Handshake initiieren, indem sie über jeden Fluss (Host-/Port-Quartett) ein ClientHello sendet.
o Der Endpunkt MUST NOT das in [RFC4145] definierte connection-Attribut verwenden.
o Der Endpunkt MUST das Zertifikats-Fingerprint-Attribut wie in [RFC4572] spezifiziert verwenden.
o Das während des DTLS-Handshakes präsentierte Zertifikat MUST mit dem über den Signalisierungspfad im SDP ausgetauschten Fingerprint übereinstimmen. Die Sicherheitseigenschaften dieses Mechanismus sind in Abschnitt 8 beschrieben.
o Stimmt der Fingerprint nicht mit dem gehashten Zertifikat überein, MUST der Endpunkt die Mediensitzung sofort abbauen. Es ist zulässig, mit dem Verbindungsaufbau zu warten, bis der Fingerprint der Gegenseite eingegangen ist; dies kann jedoch unerwünschte Latenz bewirken.