Internet Engineering Task Force (IETF)
Yorum Talebi (Request for Comments): 5764
Kategori: Standartlar İzleği
ISSN: 2070-1721
Yazarlar: D. McGrew, Cisco Systems E. Rescorla, RTFM, Inc.
Mayıs 2010
#Özet
Bu belge, Güvenli RTP (SRTP) ve Güvenli RTP Kontrol Protokolü (SRTCP) akışları için anahtarların kurulmasına yönelik bir Datagram Taşıma Katmanı Güvenliği (DTLS) uzantısını tanımlar. DTLS anahtarlama, mevcut olabilecek herhangi bir bant dışı sinyalleşme kanalından bağımsız olarak, ortam yolu üzerinde gerçekleşir.
#1. Giriş
Güvenli RTP (SRTP) profili [RFC3711], RTP verileri ve RTP Kontrol (RTCP) trafiği için gizlilik, mesaj kimlik doğrulaması ve tekrar oynatma koruması sağlayabilir. SRTP, anahtar yönetimi işlevselliği sağlamaz; bunun yerine gizli ana anahtarların değişimi ve bu anahtarlarla birlikte kullanılacak algoritmaların ve parametrelerin müzakere edilmesi için harici anahtar yönetimine dayanır.
Datagram Taşıma Katmanı Güvenliği (DTLS) [RFC4347], bütünleşik anahtar yönetimi, parametre müzakeresi ve güvenli veri aktarımı sunan bir kanal güvenliği protokolüdür. DTLS veri aktarım protokolü genel amaçlı olduğundan, bu amaç için özel olarak ayarlanmış olan SRTP'ye kıyasla RTP ile kullanım için daha az derecede optimize edilmiştir.
Bu belge, SRTP'nin performans ve şifreleme esnekliği avantajlarını, DTLS'nin bütünleşik anahtar ve ilişkilendirme yönetiminin esnekliği ve kullanım kolaylığıyla birleştiren, DTLS için bir SRTP uzantısı olan DTLS-SRTP'yi tanımlar. DTLS-SRTP iki eşdeğer şekilde değerlendirilebilir: SRTP için yeni bir anahtar yönetim yöntemi olarak ve DTLS için RTP'ye özgü yeni bir veri biçimi olarak.
DTLS-SRTP'nin temel noktaları şunlardır:
- uygulama verileri SRTP kullanılarak korunur,
- DTLS el sıkışması, SRTP için anahtarlama materyalini, algoritmaları ve parametreleri kurmak için kullanılır,
- SRTP algoritmalarını müzakere etmek için bir DTLS uzantısı kullanılır ve
- diğer DTLS kayıt-katmanı içerik türleri, olağan DTLS kayıt biçimi kullanılarak korunur.
Bu notun geri kalanı şu şekilde yapılandırılmıştır. Bölüm 2, normatif gereksinimleri belirtmek için kullanılan kuralları açıklar. Bölüm 3, DTLS-SRTP işleyişine genel bir bakış sunar. Bölüm 4 DTLS uzantılarını belirtirken, Bölüm 5 RTP ve RTCP'nin DTLS-SRTP kanalı üzerinden nasıl taşındığını ele alır. Bölüm 6, çok taraflı oturumlarla kullanımını açıklar. Bölüm 7 ve Bölüm 9, Güvenlik ve IANA hususlarını açıklar.
#2. Bu Belgede Kullanılan Kurallar
Bu belgede geçen "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, [RFC2119]'da açıklandığı şekilde yorumlanacaktır.
#3. DTLS-SRTP İşleyişine Genel Bakış
DTLS-SRTP, tam olarak iki katılımcının bulunduğu noktadan noktaya ortam oturumları için tanımlanmıştır. Her DTLS-SRTP oturumu, tek bir DTLS ilişkilendirmesi (TLS terminolojisinde "connection" olarak adlandırılır) ve ya iki SRTP bağlamı (ortam trafiği aynı ana bilgisayar/port dörtlüsü üzerinde her iki yönde de akıyorsa) ya da bir SRTP bağlamı (ortam trafiği yalnızca tek yönde akıyorsa) içerir. Belirli bir yönde bu çift üzerinden akan tüm SRTP trafiği tek bir SRTP bağlamı kullanır. Tek bir DTLS-SRTP oturumu, yalnızca tek bir UDP kaynak ve hedef port çifti üzerinden taşınan verileri korur.
DTLS-SRTP'nin genel deseni şu şekildedir. Her bir RTP veya RTCP akışı için eşler, bir DTLS ilişkilendirmesi kurmak üzere aynı kaynak ve hedef port çifti üzerinde bir DTLS el sıkışması gerçekleştirir. Hangi tarafın DTLS istemcisi ve hangi tarafın DTLS sunucusu olduğu, SDP gibi bant dışı bir mekanizma aracılığıyla belirlenmelidir. Bu el sıkışmasından elde edilen anahtarlama materyali SRTP yığınına aktarılır. Bu ilişkilendirme kurulduktan sonra, RTP paketleri bu anahtarlama materyali kullanılarak korunur (SRTP hâline gelir).
RTP ve RTCP trafiği genellikle iki ayrı UDP portu üzerinden gönderilir. Simetrik RTP [RFC4961] kullanıldığında, biri RTP portu, diğeri RTCP portu için olmak üzere iki adet çift yönlü DTLS-SRTP oturumu gereklidir. RTP akışları simetrik olmadığında, dört adet tek yönlü DTLS-SRTP oturumu gereklidir (gelen ve giden RTP ile gelen ve giden RTCP için).
Simetrik RTP [RFC4961], kaynak ve hedef portları ile adresleri tersine çevrilmiş iki RTP oturumunun bulunduğu durumdur; bu, bir TCP bağlantısının portlarını kullanma şekline benzer. Her katılımcının bir gelen RTP oturumu ve bir giden RTP oturumu vardır. Simetrik RTP kullanıldığında, tek bir DTLS-SRTP oturumu her iki RTP oturumunu da koruyabilir. DTLS-SRTP ile birlikte simetrik RTP kullanılması ÖNERİLİR.
RTP ve RTCP trafiği tek bir UDP portu üzerinde çoklanabilir [RFC5761]. Bu durumda, hem RTP hem de RTCP paketleri aynı DTLS-SRTP oturumu üzerinden gönderilebilir; bu da gereken DTLS-SRTP oturumlarının sayısını yarıya indirir. Bu, DTLS'nin kriptografik performansını iyileştirir; ancak RTCP ve RTP'nin farklı ağ muamelesine tabi olduğu durumlarda (örneğin bant genişliği ayırma veya zamanlama nedenleriyle) sorunlara yol açabilir.
Tek bir katılımcı çifti arasında birden fazla ortam oturumu bulunabilir. Bir ortam oturumu tarafından kullanılan her farklı kaynak ve hedef port çifti için ayrı bir DTLS-SRTP oturumu OLMALIDIR (ancak bu oturumlar tek bir DTLS oturumunu paylaşabilir ve böylece başlangıçtaki açık anahtar el sıkışmasının maliyetini amorti edebilir).
Bir DTLS-SRTP oturumu, SIP gibi harici bir sinyalleşme protokolü tarafından belirtilebilir. Sinyalleşme değişimi bütünlük korumalı olduğunda (örneğin dijital imzalar yoluyla SIP Kimlik koruması kullanıldığında), DTLS-SRTP bu bütünlük güvencesinden yararlanarak ortam akışının tam güvenliğini sağlayabilir. DTLS-SRTP oturumlarının SIP ve SDP [RFC4566] içinde nasıl belirtileceğine ve uç noktaların parmak izleri kullanılarak nasıl doğrulanacağına dair bir açıklama [RFC5763]'te bulunabilir.
Naif bir uygulamada, birden fazla ortam oturumu olduğunda, her ortam kanalı için yeni bir DTLS oturumu kurulumu (açık anahtar kriptografisi dâhil) yapılır. Örneğin, bir görüntülü telefon hem bir ses akışı hem de bir video akışı gönderiyor olabilir ve bunların her biri ayrı bir DTLS oturumu kurulum değişimini kullanır; bu değişimler paralel olarak ilerler. Bir optimizasyon olarak, DTLS-SRTP uygulaması aşağıdaki stratejiyi KULLANMALIDIR: tek bir DTLS ilişkilendirmesi kurulur ve diğer tüm DTLS ilişkilendirmeleri, bu bağlantı kurulana kadar el sıkışmalarına başlamadan bekler. Bu strateji, sonraki oturumların DTLS oturum devam ettirmeyi kullanmasına olanak tanır; bu da pahalı açık anahtar kriptografisi işlemlerinin maliyetinin birden fazla DTLS el sıkışması arasında amorti edilmesini sağlar.
İstemci tarafından başlatılan paketleri korumak için kullanılan SRTP anahtarları, sunucu tarafından başlatılan paketleri korumak için kullanılan SRTP anahtarlarından farklıdır. Aynı kanal için istemciden kaynaklanan tüm RTP kaynakları aynı SRTP anahtarlarını kullanır ve benzer şekilde, aynı kanal için sunucudan kaynaklanan tüm RTP kaynakları da aynı SRTP anahtarlarını kullanır. SRTP uygulaması, aynı cihazdan aynı kanal üzerinden kaynaklanan tüm RTP kaynakları için tüm senkronizasyon kaynağı (SSRC) değerlerinin birbirinden farklı olmasını SAĞLAMALIDIR; böylece "iki kez kullanılan ped" problemi (RFC 3711'in Bölüm 9.1'inde açıklandığı gibi) önlenir. Ayrı anahtarlama materyali kullanan ayrı ortam akışları (farklı ana bilgisayar/port dörtlülerinde) için, bir SSRC çakışması meydana gelse bile bunun bir sorun olmadığını unutmayın.
#4. SRTP Anahtar Kurulumu için DTLS Uzantıları
4.1. use_srtp Uzantısı
SRTP veri korumasının kullanımını müzakere etmek amacıyla, istemciler DTLS genişletilmiş istemci selamlamasına "use_srtp" türünde bir uzantı ekler. Bu uzantı YALNIZCA taşınan verinin RTP veya RTCP [RFC3550] olduğu durumlarda kullanılmalıdır. Bu uzantının "extension_data" alanı, aşağıda belirtildiği üzere kabul edilebilir SRTP koruma profillerinin listesini içerir.
"use_srtp" uzantısını içeren bir genişletilmiş selamlama alan sunucular, genişletilmiş sunucu selamlamasında seçilen koruma profilini içeren "use_srtp" türünde bir uzantı ekleyerek SRTP kullanımını kabul edebilir. Bu süreç aşağıda gösterilmiştir.
İstemci ve sunucu el sıkışmasına genel bakış:
- ClientHello + use_srtp →
- ← ServerHello + use_srtp
- Certificate*
- ServerKeyExchange*
- CertificateRequest*
- ← ServerHelloDone
- Certificate*
- ClientKeyExchange
- CertificateVerify*
- [ChangeCipherSpec]
- Finished →
- ← [ChangeCipherSpec]
- ← Finished
- SRTP paketleri ↔ SRTP paketleri
Burada *, DTLS'de her zaman gönderilmeyen iletileri gösterir. CertificateRequest, istemci ve sunucu Sertifikaları ile CertificateVerify, DTLS-SRTP'de gönderilecektir.
"use_srtp" uzantısı müzakere edildikten sonra, RTP veya RTCP uygulama verileri yalnızca SRTP kullanılarak korunur. Uygulama verileri hiçbir zaman DTLS kayıt-katmanı "application_data" paketleri içinde gönderilmez. Bunun yerine, tam RTP veya RTCP paketleri DTLS yığınına aktarılır; DTLS yığını bunları SRTP yığınına iletir ve SRTP yığını bunları uygun şekilde korur. RTP/RTCP çoklaması [RFC5761] kullanılıyorsa, bunun RTP ve RTCP paketlerinin her ikisinin de DTLS yığınına aktarılabileceği anlamına geldiğini unutmayın. DTLS katmanı paketleri işlemediğinden, bunları ayırt etmesine gerek yoktur. SRTP yığını, RTP'yi RTCP'den ayırt etmek için [RFC5761]'deki yordamları kullanabilir.
"use_srtp" uzantısı etkin olduğunda, uygulamalar her datagram başına birden fazla uygulama verisi "kayıt" yerleştirmemelidir. (Bu, yalnızca DTLS açısından anlamlıdır; çünkü SRTP doğası gereği paket başına tek bir yük yönelimlidir, ancak bu ifade yalnızca açıklık sağlamak amacıyla belirtilmiştir.)
RTP/RTCP dışındaki veriler (yani TLS kontrol iletileri), olağan DTLS çerçevelemesini KULLANMALIDIR ve SRTP verilerinden ayrı datagramlara yerleştirilmelidir.
Bir DTLS-SRTP el sıkışması bir veya daha fazla SRTP kripto bağlamı kurar; ancak bunların tümü aynı SRTP Koruma Profili ve varsa aynı Ana Anahtar Tanımlayıcısını (MKI) paylaşır. MKI'ler yalnızca, örneğin yeniden anahtarlama nedeniyle, farklı el sıkışmalar arasındaki anahtarlama materyalini ve koruma profillerini ayırt etmek için kullanılır. Bir DTLS-SRTP oturumunda bir MKI kurulduğunda, bu MKI o oturum içindeki tüm SSRC'ler için geçerli OLMALIDIR — ancak tek bir uç nokta, örneğin çatallanma (forking) nedeniyle birden fazla DTLS-SRTP oturumu müzakere edebilir. (RFC 3711, aynı oturum içindeki ancak farklı SSRC'lere sahip paketlerin MKI'leri farklı şekilde kullanmasına izin verir; buna karşılık, DTLS-SRTP, MKI'lerin ve bunlarla ilişkili anahtarların tüm SRTP oturumu genelinde aynı anlama sahip olmasını ve tekdüze olmasını gerektirir.)
4.1.1. use_srtp Uzantısı Tanımı
İstemci, "use_srtp" uzantısının extension_data alanını bir UseSRTPData değeri ile doldurmak ZORUNDADIR (kayıt için Bölüm 9'a bakınız):
uint8 SRTPProtectionProfile[2];
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;SRTPProtectionProfiles listesi, istemcinin desteklemeye istekli olduğu SRTP koruma profillerini tercih sırasına göre azalan biçimde belirtir. srtp_mki değeri, istemcinin SRTP paketleri için kullanacağı SRTP Ana Anahtar Tanımlayıcısı (MKI) değerini (varsa) içerir. Bu alanın uzunluğu sıfır ise, MKI kullanılmayacaktır.
Not: TLS sözdizimine aşina olmayanlar için, `srtp_mki<0..255>`, uzunluğu 0 ile 255 (dahil) arasında olan değişken uzunluklu bir değeri ifade eder. Dolayısıyla MKI en fazla 255 bayt uzunluğunda olabilir.
Sunucu use_srtp uzantısını kabul etmeye istekliyse, ExtendedServerHello içinde kendi "use_srtp" uzantısıyla yanıt VERMELİDİR. extension_data alanı, sunucunun bu bağlantı için kullanmayı seçtiği tek bir SRTPProtectionProfile değerini içeren bir UseSRTPData değeri içermelidir. Sunucu, istemcinin sunmadığı bir değeri SEÇMEMELİDİR. Ortak bir profil yoksa, sunucu use_srtp uzantısını geri döndürMEMELİDİR; bu durumda bağlantı, müzakere edilen DTLS şifreleme paketine geri döner. Bu kabul edilebilir değilse, sunucu uygun bir DTLS uyarısı döndürMELİDİR.
4.1.2. SRTP Koruma Profilleri
Bir DTLS-SRTP SRTP Koruma Profili, SRTP işlemesi için geçerli olan parametreleri ve seçenekleri tanımlar. Bu belge aşağıdaki SRTP koruma profillerini tanımlar:
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};Aşağıdaki liste, her bir koruma profili için SRTP dönüşüm parametrelerini belirtir. cipher_key_length, cipher_salt_length, auth_key_length ve auth_tag_length parametreleri, atıfta bulundukları değerlerdeki bit sayısını ifade eder. maximum_lifetime parametresi, parametre profili kullanımdayken her bir anahtar kümesiyle korunabilecek en yüksek paket sayısını belirtir. Bu parametrelerin tümü, RTCP parametreleri ayrıca belirtilmedikçe, hem RTP hem de RTCP için geçerlidir.
Bu profillerdeki tüm kriptografik algoritmalar [RFC3711]'den alınmıştır.
SRTP_AES128_CM_HMAC_SHA1_80
- cipher: AES_128_CM
- cipher_key_length: 128
- cipher_salt_length: 112
- maximum_lifetime: 2^31
- auth_function: HMAC-SHA1
- auth_key_length: 160
- auth_tag_length: 80
SRTP_AES128_CM_HMAC_SHA1_32
- cipher: AES_128_CM
- cipher_key_length: 128
- cipher_salt_length: 112
- maximum_lifetime: 2^31
- auth_function: HMAC-SHA1
- auth_key_length: 160
- auth_tag_length: 32
- RTCP auth_tag_length: 80
SRTP_NULL_HMAC_SHA1_80
- cipher: NULL
- cipher_key_length: 0
- cipher_salt_length: 0
- maximum_lifetime: 2^31
- auth_function: HMAC-SHA1
- auth_key_length: 160
- auth_tag_length: 80
SRTP_NULL_HMAC_SHA1_32
- cipher: NULL
- cipher_key_length: 0
- cipher_salt_length: 0
- maximum_lifetime: 2^31
- auth_function: HMAC-SHA1
- auth_key_length: 160
- auth_tag_length: 32
- RTCP auth_tag_length: 80
Bu SRTP Parametre profillerinin tümü için aşağıdaki SRTP seçenekleri geçerlidir:
- TLS Sahte Rastgele Fonksiyonu (PRF), SRTP Anahtar Türetme Fonksiyonuna (KDF) girdi sağlayacak anahtarları üretmek için kullanılır. DTLS 1.2 [DTLS1.2] kullanımdayken PRF, şifre paketiyle ilişkili olandır. Bu belirtimin DTLS 1.0 veya DTLS 1.2 ile uyumlu olduğunu unutmayın.
- Anahtar Türetme Oranı (KDR) sıfıra eşittir. Dolayısıyla, anahtarlar SRTP sıra numarasına dayalı olarak yeniden türetilmez.
- RFC 3711'deki AES-CM PRF ile Bölüm 4.3'teki anahtar türetme yordamları kullanılır.
- Diğer tüm parametreler için (özellikle SRTP tekrar oynatma pencere boyutu ve FEC sırası) varsayılan değerler kullanılır.
Bu parametreler için varsayılanlardan farklı değerlere ihtiyaç duyulursa, bunlar SDP sözdizimiyle işaretlenmesini belirten ayrı bir belirtim yazılarak etkinleştirilebilir.
DTLS-SRTP kullanan uygulamalar, bir RTP akışını koruyan DTLS-SRTP oturumu ile ilişkili RTCP akışını koruyan DTLS-SRTP oturumu arasında SRTP Koruma Profillerini eşgüdümlü hale getirmelidir (RTP ve RTCP'nin ortak bir port üzerinden çoklanmadığı durumlarda). Özellikle, özdeş şifreler kullanılmalıdır.
Yeni SRTPProtectionProfile değerleri, RFC 5226 [RFC5226] tarafından tanımlanan "Specification Required" ilkesine göre tanımlanmalıdır. IANA Hususları için Bölüm 9'a bakınız.
4.1.3. srtp_mki değeri
srtp_mki değeri, SRTP ve SRTCP paketlerindeki SRTP Anahtar Tanımlayıcı (MKI) alanını kullanma yeteneğini ve isteğini belirtmek için kullanılabilir. MKI alanı, bir SRTP alıcısına, bu alanı içeren paketin korunmasında hangi anahtarın kullanıldığını gösterir.
srtp_mki alanı, bu el sıkışmasından türetilen SRTP ana anahtarlarıyla ilişkili SRTP MKI değerini içerir. Her SRTP oturumu, herhangi bir zamanda paketleri korumak için kullanılan tam olarak bir ana anahtara sahip olmalıdır. İstemci, MKI değerini, daha önce kullanılan son MKI değerinden farklı olacak şekilde seçmelidir ve bu değerleri TLS oturumu süresince benzersiz yapması önerilir.
"srtp_mki" alanını içeren bir "use_srtp" uzantısı alındığında, sunucu (uzantıyı kabul ettiği varsayılarak) aşağıdakilerden birini yapmak zorundadır:
- MKI'yi kullanacağını belirtmek için kendi "use_srtp" uzantısında eşleşen bir "srtp_mki" değeri eklemek veya
- MKI'yi kullanamayacağını belirtmek için boş bir "srtp_mki" değeri döndürmek.
İstemci, sunucu yanıtında, istemcinin sunduğundan farklı ve sıfır olmayan uzunlukta bir MKI tespit ederse, el sıkışmayı sonlandırmak zorundadır ve bir invalid_parameter uyarısı göndermesi önerilir. İstemci ve sunucu bir MKI üzerinde anlaştığında, yeni güvenlik parametreleri altında korunan tüm SRTP paketleri bu MKI'yi içermek zorundadır.
Herhangi bir DTLS-SRTP oturumunun yalnızca tek bir etkin MKI'si olduğunu (varsa) unutmayın. Dolayısıyla, herhangi bir zamanda bir uç nokta kümesi genellikle yalnızca bir MKI kullanır (başlıca istisna, yeniden el sıkışmalar sırasında ortaya çıkar).
4.2. Anahtar Türetme
SRTP modu etkinken, sıradan DTLS kayıt koruması ile SRTP paket koruması için farklı anahtarlar kullanılır. Bu anahtarlar, aşağıdakileri üretmek üzere bir TLS dışa aktarıcısı [RFC5705] kullanılarak üretilir:
2 * (SRTPSecurityParams.master_key_len +
SRTPSecurityParams.master_salt_len) bayt verive aşağıda gösterildiği gibi atanır. Birlik başına bağlam değeri boştur.
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];Bu kullanım için dışa aktarıcı etiketi "EXTRACTOR-dtls_srtp"dir. ("EXTRACTOR" öneki tarihsel uyumluluk içindir.)
Dört anahtarlama malzemesi değeri (her yön için ana anahtar ve ana tuz), Şekil 1'de gösterildiği ve aşağıda ayrıntılandırıldığı üzere SRTP anahtar türetme mekanizmasına girdi olarak sağlanır. Varsayılan olarak, bir SRTP Koruma Profilinin parçası olarak başka bir anahtar türetme mekanizması belirtilmedikçe, [RFC3711] Bölüm 4.3'te tanımlanan mekanizma kullanılır.
client_write_SRTP_master_key ve client_write_SRTP_master_salt, istemci tarafından gönderilen paketleri şifrelemek ve doğrulamak için kullanılan SRTP anahtarlarını üretmek üzere SRTP anahtar türetme fonksiyonunun bir çağrısına sağlanır. Sunucu bu anahtarları yalnızca gelen paketlerin şifresini çözmek ve özgünlüğünü denetlemek için kullanmak zorundadır.
server_write_SRTP_master_key ve server_write_SRTP_master_salt, sunucu tarafından gönderilen paketleri şifrelemek ve doğrulamak için kullanılan SRTP anahtarlarını üretmek üzere SRTP anahtar türetme fonksiyonunun bir çağrısına sağlanır. İstemci bu anahtarları yalnızca gelen paketlerin şifresini çözmek ve özgünlüğünü denetlemek için kullanmak zorundadır.
TLS master
secret label
| |
v v
+---------------+
| TLS extractor |
+---------------+
| +------+ SRTP
+-> client_write_SRTP_master_key ----+--->| SRTP |-> client
| | +->| KDF | write
| | | +------+ keys
| | |
+-> server_write_SRTP_master_key -- | | +------+ SRTCP
| \ \--->| SRTCP|-> client
| \ +->| KDF | write
| | | +------+ keys
+-> client_write_SRTP_master_salt ---|-+
| |
| | +------+ SRTP
| +--->| SRTP |-> server
+-> server_write_SRTP_master_salt -+-|--->| KDF | write
| | +------+ keys
| |
| | +------+ SRTCP
| +--->| SRTCP|-> server
+----->| KDF | write
+------+ keysŞekil 1: SRTP anahtarlarının türetilmesi.
RTCP ve RTP aynı kaynak ve hedef portları kullandığında, hem SRTP hem de SRTCP anahtarlarına ihtiyaç vardır. Aksi halde, iki DTLS-SRTP oturumu bulunur; bunlardan biri RTP paketlerini, diğeri ise RTCP paketlerini korur. Her DTLS-SRTP oturumu, hangi SSRC'lerin bu çift üzerinde kullanıldığından bağımsız olarak, tek bir kaynak/hedef taşıma adresi çifti üzerinden geçen bir SRTP oturumunun bölümünü korur. Bir DTLS-SRTP oturumu RTP'yi koruduğunda, DTLS el sıkışmasından türetilen SRTCP anahtarlarına gerek yoktur ve bunlar atılır. Bir DTLS-SRTP oturumu RTCP'yi koruduğunda ise, DTLS el sıkışmasından türetilen SRTP anahtarlarına gerek yoktur ve bunlar atılır.
Client Server
(Sender) (Receiver)
(1) <----- DTLS ------> src/dst = a/b and b/a
------ SRTP ------> src/dst = a/b, uses client write keys
(2) <----- DTLS ------> src/dst = c/d and d/c
------ SRTCP -----> src/dst = c/d, uses client write keys
<----- SRTCP ------ src/dst = d/c, uses server write keysŞekil 2: RTP'yi koruyan bir DTLS-SRTP oturumu (1) ve RTCP'yi koruyan başka bir oturum (2); kullanılan taşıma adreslerini ve anahtarları göstermektedir.
4.3. Anahtar Kapsamı
Paketlerin yeniden sıralanabilmesi olasılığı nedeniyle, DTLS-SRTP uygulamalarının, alıcıların anahtarı bulunmayan paketleri düşürme ihtiyacını ortadan kaldırmak için bir yeniden anahtarlama sırasında birden fazla SRTP anahtar kümesini saklaması önerilir.
4.4. Anahtar Kullanım Sınırlamaları
SRTP koruma profilindeki maximum_lifetime parametresi, her bir tekil şifreleme ve kimlik doğrulama anahtarıyla korunabilecek en yüksek paket sayısını belirtir. (RTP ve RTCP'nin bağımsız anahtarlarla korunduğu göz önüne alındığında, bir anahtarın ömrünün sonuna ulaşıp ulaşmadığını belirleme amacıyla bu protokoller ayrı ayrı sayılır.) Her profil kendi sınırını tanımlar. Bu sınıra ulaşıldığında, yedek anahtarları kurmak için yeni bir DTLS oturumu kullanılmalıdır ve SRTP uygulamaları mevcut anahtarları ne giden ne de gelen trafiğin işlenmesi için kullanmamalıdır.
#5. DTLS-SRTP Kanalı Üzerinden RTP ve RTCP Kullanımı
5.1. Veri Koruması
DTLS el sıkışması tamamlandıktan sonra, eşler yeni oluşturulan kanal üzerinden RTP veya RTCP gönderebilir. Önce iletim sürecini, ardından alım sürecini açıklarız.
Her RTP oturumu içinde, DTLS el sıkışması tamamlanmadan önce SRTP işlemesi yapılmamalıdır.
5.1.1. İletim
DTLS ve TLS, bir dizi kayıt içerik türü tanımlar. Sıradan TLS/DTLS'de tüm veriler aynı kayıt kodlaması ve mekanizmaları kullanılarak korunur. Bu belgede tanımlanan mekanizma etkinken, bu durum değiştirilir ve DTLS'nin üst seviye protokol istemcileri tarafından yazılan verilerin RTP/RTCP olduğu varsayılır ve standart TLS kayıt kodlaması yerine SRTP kullanılarak şifrelenir.
DTLS kullanan bir taraf, SRTP modunda bir RTP paketi göndermek istediğinde, bunu DTLS uygulamasına sıradan bir uygulama verisi yazımı olarak iletir (örneğin SSL_write()). DTLS uygulaması daha sonra RFC 3711, Bölüm 3 ve 4'te açıklanan işlemeyi çağırır. Ortaya çıkan SRTP paketi, DTLS çerçevesi olmaksızın tek bir datagram olarak doğrudan hatta gönderilir. Bu, SRTP ile uyumlu ve birlikte çalışabilir bir veri kapsüllemesi sağlar. Bu paketler için DTLS sıra numarası yerine RTP sıra numarasının kullanıldığına dikkat edin.
5.1.2. Alım
DTLS-SRTP bir RTP oturumunu korumak için kullanıldığında, RTP alıcısının RTP portuna gelen paketleri çoğullamadan ayırması gerekir. Gelen paketler RTP, DTLS veya STUN [RFC5389] türlerinde olabilir. Yalnızca bu paket türleri mevcutsa, bir paketin türü ilk baytına bakılarak belirlenebilir.
Bir paketi çoğullamadan ayırma süreci aşağıdaki gibidir. Alıcı, paketin ilk baytına bakar. Bu baytın değeri 0 veya 1 ise paket STUN'dur. Değer 128 ile 191 (dahil) arasındaysa paket RTP'dir (veya RTCP, RTCP ve RTP'nin aynı hedef port üzerinden çoklandığı durumlarda). Değer 20 ile 63 (dahil) arasındaysa paket DTLS'dir. Bu süreç Şekil 3'te özetlenmiştir.
+----------------+
| 127 < B < 192 -+--> RTP'ye ilet
| |
paket --> | 19 < B < 64 -+--> DTLS'ye ilet
| |
| B < 2 -+--> STUN'a ilet
+----------------+Şekil 3: DTLS-SRTP alıcısının paket çoğullamadan ayırma algoritması. Burada B alanı, paketin baştaki baytını ifade eder.
Başka paket türleri de çoklanacaksa, uygulayıcıların ve/veya tasarımcıların bunların bu üç paket türünden ayrıştırılabildiğinden emin olmaları önerilir.
Bazı durumlarda, belirli bir SRTP uç noktası için birden fazla DTLS-SRTP birlikteliği bulunur. Örneğin, Alice'in SIP çatallanmasıyla hem Bob'a hem de Charlie'ye yönlendirilen bir çağrı yaptığı durumda, Şekil 4'te gösterildiği gibi her ikisi için de aynı yerel ana makine/port çiftini kullanacaktır; burada XXX ve YYY farklı DTLS-SRTP birlikteliklerini temsil eder. (Gösterilen SSRC'ler Alice'e doğru akan veriler içindir.)
Bob (192.0.2.1:6666)
/
/
/ SSRC=1
/ DTLS-SRTP=XXX
/
v
Alice (192.0.2.0:5555)
^
\
\ SSRC=2
\ DTLS-SRTP=YYY
\
\
Charlie (192.0.2.2:6666)Şekil 4: SIP çatallanmasıyla RTP oturumları.
DTLS, ana makine/port dörtlüsü üzerinde çalıştığından, DTLS birlikteliği, yabancı ana makine/port çifti birliktelikleri ayırt etmek için kullanılarak yine de doğru şekilde tamamlanır. Ancak RTP'de kaynak ana makine/port kullanılmaz ve oturumlar hedef ana makine/port ve SSRC ile tanımlanır. Bu nedenle, hangi SSRC'lerin hangi DTLS birlikteliklerine karşılık geldiğini belirlemek için bir mekanizmaya ihtiyaç vardır. Aşağıdaki yöntem kullanılmalıdır.
Her yerel ana makine/port çifti için, DTLS-SRTP uygulaması, bildiği tüm SSRC'leri ve bunların karşılık geldiği DTLS-SRTP birlikteliklerini listeleyen bir tablo tutar. Başlangıçta bu tablo boştur. Belirli bir RTP uç noktası (hedef IP/port çifti) için bir SRTP paketi alındığında, aşağıdaki yordam kullanılır:
- Eğer SSRC bu uç nokta için zaten biliniyorsa, ilgili DTLS-SRTP ilişkilendirmesi ve ona ait anahtarlama materyali paketin şifresini çözmek ve doğrulamak için kullanılır.
- Eğer SSRC bilinmiyorsa, alıcı paketi, bu uç noktaya karşılık gelen her bir DTLS-SRTP ilişkilendirmesine ait anahtarlama materyali ile çözmeyi dener.
- Şifre çözme ve doğrulama başarılı olursa (kimlik doğrulama etiketi doğrulanırsa), SSRC’yi ilgili ilişkilendirme ile eşleyen bir kayıt tabloya eklenir.
- Şifre çözme ve doğrulama başarısız olursa, paket sessizce atılır.
- Bir DTLS-SRTP ilişkilendirmesi kapatıldığında (örneğin, çatallama terk edildiğinde), bu ilişkilendirmeye ait girdiler eşleme tablosundan KALDIRILMALIDIR.
Bu algoritmanın tek bir SSRC için ortalama maliyeti, tek bir paketin şifre çözme ve doğrulama süresinin, ana bilgisayardaki tek bir alıcı porta karşılık gelen geçerli DTLS-SRTP ilişkilendirmelerinin sayısı ile çarpımına eşittir. Pratikte bu, çatallama sayısı anlamına gelir; dolayısıyla Şekil 4’te gösterilen durumda bu sayı iki olacaktır. Bu maliyet, belirli bir SSRC için yalnızca bir kez oluşur; çünkü sonrasında bu SSRC eşleme tablosuna yerleştirilir ve doğrudan bulunur. Normal RTP’de olduğu gibi, bu algoritma kaynak tarafından herhangi bir zamanda yeni SSRC’lerin tanıtılmasına izin verir. Bunlar otomatik olarak doğru DTLS ilişkilendirmesine eşlenecektir.
Bu algoritmanın, aynı adres/port çiftinden birden fazla SSRC gönderilmesine açıkça izin verdiğine dikkat edilmelidir. Bunun gerçekleşebileceği durumlardan biri bir RTP çeviricisidir. Bu algoritma SSRC’leri otomatik olarak doğru ilişkilendirmelere atayacaktır. SRTP paketleri kriptografik olarak korunduğundan, böyle bir çevirici ya bir uç nokta ile anahtarlama materyalini paylaşmalı ya da bütünlük denetiminin başarısız olmasına neden olacak şekilde paketleri değiştirmekten kaçınmalıdır. Bu, SRTP’nin genel bir özelliğidir ve DTLS-SRTP’ye özgü değildir.
Dikkate alınması gereken iki hata durumu vardır. Birincisi, bir SSRC çakışması meydana gelirse, yalnızca ilk kaynaktan gelen paketler işlenecektir. İkinci kaynaktan gelen paketler ulaştığında, ilk kaynakla olan DTLS ilişkilendirmesi şifre çözme ve doğrulama için kullanılacak, bu işlem başarısız olacak ve paket atılacaktır. Bu durum, alıcının bir kaynaktan gelen paketleri tutmasına ve diğerinden gelenleri atmasına izin veren [RFC3550] ile uyumludur. Elbette, RFC 3550’de tanımlanan SSRC çakışması algılama ve ele alma prosedürleri de KESİNLİKLE izlenmelidir.
İkinci olarak, hatalı çalışan bir kaynağın çözülemeyen ve doğrulanamayan bozuk paketler göndermesi söz konusu olabilir. Bu durumda, şifre çözme ve doğrulama her zaman başarısız olduğundan SSRC hiçbir zaman eşleme tablosuna girmez. Alıcılar, sürekli olarak şifre çözme ve doğrulamada başarısız olan eşlenmemiş SSRC’lerin kayıtlarını tutabilir ve belirli bir sınıra ulaşıldığında bunları işleme girişimlerini terk EDEBİLİR. Bu sınır, iletim hatalarının etkilerini hesaba katacak kadar büyük OLMALIDIR. İlgili SRTP uç noktası silindiğinde (örneğin, çağrı sona erdiğinde) bu tablodaki girdiler KESİNLİKLE budanmalıdır ve eş uygulamanın düzeltilmiş olma olasılığına izin vermek için bundan daha hızlı zaman aşımına uğraması TAVSİYE EDİLİR (kesin bir öneri sunmuyoruz ancak 10 ila 30 saniye uygun görünmektedir).
5.2. Yeniden El Sıkışma ve Yeniden Anahtarlama
DTLS’te yeniden anahtarlama, mevcut DTLS kanalı üzerinden yeni bir el sıkışma gerçekleştirilerek yapılır. Yani el sıkışma mesajları mevcut DTLS şifre takımı tarafından korunur. Bu el sıkışma, veri aktarımıyla paralel olarak gerçekleştirilebilir; dolayısıyla veri akışında bir kesinti gerekmez. El sıkışma tamamlandığında, yeni türetilen anahtar kümesi hem DTLS hem de SRTP olmak üzere tüm giden paketleri korumak için kullanılır.
Paketlerin yeniden sıralanması nedeniyle, önceki anahtar kümesiyle korunan paketler el sıkışma tamamlandıktan sonra hatta görünebilir. Bu durumu telafi etmek için, alıcılar eski paketleri çözebilmek ve doğrulayabilmek amacıyla her iki anahtar kümesini de bir süre boyunca tutmalıdır. Anahtarlar, maksimum segment ömrü (MSL) süresince muhafaza edilmelidir.
Eğer bir MKI kullanılıyorsa, alıcı gelen paketi işlemek için ilgili anahtar kümesini kullanmalıdır. Eşleşen bir MKI yoksa, paket KESİNLİKLE reddedilmelidir. Aksi takdirde, el sıkışma tamamlandıktan sonra bir paket geldiğinde, alıcı MKI yoksa bu paketi işlemek için yeni türetilen anahtar kümesini KULLANMALIDIR. (Paket eski anahtar kümesiyle korunmuşsa, bu durum alıcı için kimlik doğrulama hatası oluşmasıyla anlaşılır.) Paketin kimlik doğrulama denetimi başarısız olursa ve MKI kullanılmıyorsa, alıcı paketi eski anahtar kümesiyle işlemeyi TERCİH EDEBİLİR. Bu kimlik doğrulama denetimi paketin geçerli olduğunu gösterirse paket kabul edilmelidir; aksi halde paket KESİNLİKLE atılmalı ve reddedilmelidir.
Alıcılar, anahtar seçiminde yardımcı olmak için SRTP paket sıra numarasını KULLANABİLİR. Yeni anahtar kümesiyle bir paket alınıp doğrulandıktan sonra, sıra numarası daha büyük olan tüm paketler de yeni anahtar kümesiyle korunmuş olacaktır.
#6. Çok Taraflı RTP Oturumları
DTLS nokta-noktaya bir protokol olduğundan, DTLS-SRTP yalnızca tekil yayın (unicast) RTP oturumlarını korumak üzere tasarlanmıştır. Bu durum, RTP mikserleriyle kullanımını engellemez. Örneğin, bir konferans köprüsü, konferanstaki her bir katılımcıya gidiş ve dönüş iletişimini güvence altına almak için DTLS-SRTP kullanabilir. Ancak, bir uç nokta ile bir mikser arasındaki her akışın kendine ait bir anahtarı olduğundan, mikser her alıcı için trafiğin şifresini çözmek ve ardından yeniden şifrelemek zorundadır.
Gelecekteki bir teknik belge, birden fazla DTLS-SRTP ilişkilendirmesi arasında tek bir anahtarın paylaşılmasına yönelik yöntemleri tanımlayabilir; böylece konferans sistemlerinin şifre çözme/yeniden şifreleme aşamasından kaçınması sağlanabilir. Ancak, ortamın değiştirildiği (örneğin seviye dengeleme veya kod dönüştürme için) herhangi bir sistem genellikle açık metin üzerinde işlem yapmak zorunda kalacaktır ve kesinlikle kimlik doğrulama etiketini bozacaktır; dolayısıyla şifre çözme/yeniden şifreleme aşamasını gerektirecektir.
#7. Güvenlik Hususları
Aynı el sıkışmada müzakere edilen birden fazla veri koruma çerçevesinin kullanımı bazı karmaşıklıklar ortaya çıkarır; bunlar burada ele alınmaktadır.
7.1. Müzakerenin Güvenliği
Buradaki bir endişe, saldırganların eşleri SRTP yerine sıradan DTLS kullanmaya zorlayan bir aşağıya çekme saldırısı uygulayabilmesidir. Ancak, bu uzantının müzakeresi DTLS el sıkışması içinde gerçekleştirildiğinden, Finished mesajlarıyla korunur. Dolayısıyla herhangi bir aşağıya çekme saldırısı otomatik olarak tespit edilir ve bu durum, kanalı kontrol edebilen herhangi bir saldırganın gerçekleştirebileceği bir hizmet reddi saldırısına indirgenmiş olur.
7.2. Çerçeve Karışıklığı
İki farklı çerçeveleme biçimi kullanıldığından, bir saldırganın alıcıyı SRTP çerçeveli bir RTP paketini bir DTLS kaydı (örneğin bir el sıkışma mesajı) olarak veya tam tersini ele almaya ikna edebileceği endişesi vardır. Bu saldırı, her veri türü için Mesaj Kimlik Doğrulama Kodu (MAC) doğrulamasında farklı anahtarlar kullanılarak önlenir. Dolayısıyla bu tür bir saldırı, geçerli bir MAC’e sahip bir paket uydurabilmeye indirgenir ki bu, hem DTLS hem de SRTP’nin temel bir güvenlik değişmezini ihlal eder.
DTLS el sıkışma kanalına enjeksiyona karşı ek bir savunma olarak, DTLS kayıt türü MAC içine dahil edilmiştir. Bu nedenle, bir SRTP kaydı bilinmeyen bir tür olarak ele alınacak ve yok sayılacaktır. ([RFC5246] Bölüm 6’ya bakınız.)
7.3. Sıra Numarası Etkileşimleri
Bölüm 5.1.1’de açıklandığı üzere, SRTP ve DTLS sıra numarası uzayları birbirinden ayrıdır. Bu, belirli bir DTLS kontrol kaydının bir SRTP paketine göre kesin olarak sıralanmasının mümkün olmadığı anlamına gelir. Genel olarak bu durum iki senaryoda önemlidir: uyarılar ve yeniden el sıkışma.
7.3.1. Uyarılar
DTLS el sıkışması ve change_cipher_spec mesajları, uyarılarla aynı sıra numarası uzayını paylaştığından, doğru şekilde sıralanabilirler. DTLS uyarıları doğası gereği güvenilir olmadığından ve veri paketlerine yanıt olarak ÜRETİLMEMESİ GEREKTİĞİNDEN, SRTP paketleri ile DTLS uyarıları arasında güvenilir sıralama önemli bir özellik değildir. Bununla birlikte, SRTP kodlamasıyla ilgili sorunları bildirmek için DTLS uyarılarını kullanmak isteyen uygulamalar, uyarıları alındıkları anda işlemeli ve bunların zamansal olarak bitişik akışa ait olduğunu varsaymalıdır. Bu tür uygulamalar, yeniden oynatma saldırılarına aşırı tepki vermekten kaçınmak için uyarıların yeniden iletimini denetlemeli ve yeniden iletilmiş uyarıları atmalıdır.
7.3.2. Yeniden Müzakere
Bölüm 5.2’de tanımlanan yeniden el sıkışma geçiş algoritması, MKI kullanılmadığında birden fazla anahtar kümesini denemeyi gerektirdiğinden, kimlik doğrulamayı bir miktar zayıflatır. Örneğin, n bitlik bir MAC kullanılıyorsa ve k farklı anahtar kümesi mevcutsa, MAC gücü log_2(k) bit kadar azalarak n - log_2(k) olur. Pratikte, kullanılan anahtar sayısı çok küçük olacağından ve kullanılan MAC’ler genellikle güçlü olduğundan (SRTP için varsayılan 80 bittir), buradaki güvenlik azalması asgari düzeydedir.
Bir diğer endişe, bu algoritmanın alıcı üzerindeki iş yükünü bir miktar artırmasıdır; çünkü birden fazla doğrulama denemesi yapması gerekir. Ancak yine, potansiyel anahtar sayısı çok küçük olacaktır (ve saldırgan bunu daha büyük olmaya zorlayamaz) ve bu teknik zaten rollover sayaç yönetimi için kullanılmaktadır; bu nedenle yazarlar bunu ciddi bir kusur olarak değerlendirmemektedir.
7.4. Şifre Çözme Maliyeti
Bir saldırgan, yüzeysel olarak geçerli görünen ancak doğru şekilde çözülemeyen SRTP paketleri göndererek alıcıya hesaplama maliyeti yükleyebilir. Genel olarak, şifreleme algoritmaları o kadar hızlıdır ki bu maliyet, tüketilen bant genişliğine kıyasla son derece küçüktür. Bölüm 5.1.2’de açıklanan SSRC-DTLS eşleme algoritması, saldırgana burada küçük bir avantaj sağlar; çünkü alıcıyı paket başına birden fazla şifre çözme yapmaya zorlayabilir. Ancak bu avantaj sınırlıdır; çünkü alıcının yaptığı şifre çözme sayısı, belirli bir hedef ana bilgisayar/port için sahip olduğu ilişkilendirme sayısıyla sınırlıdır ve bu sayı genellikle oldukça küçüktür. Karşılaştırma yapmak gerekirse, tek bir 1024 bitlik RSA özel anahtar işlemi (bir DTLS-SRTP ilişkilendirmesi kurmanın tipik asgari maliyeti) bir SRTP paketinin şifresini çözmekten yüzlerce kat daha pahalıdır.
Uygulamalar, bilinmeyen SSRC’lere sahip ve kimlik doğrulama etiketi denetiminde başarısız olan SRTP paketlerinin sayısını izleyerek bu tür bir saldırıyı tespit edebilir. Böyle bir saldırı altında, uygulamalar ya bilinen SSRC’lere sahip olan ya da DTLS-SRTP ilişkilendirmeleri bulunan eşlerin kaynak adresleriyle eşleşen adreslerden gelen paketlerin şifre çözme ve doğrulamasına öncelik VERMELİDİR.
#8. DTLS Üzerinden RTP/SAVP için Oturum Tanımı
Bu teknik belge, SDP ortam tanımlarında ("m=" satırları ve bunlara bağlı parametreler) kullanılan protokolü tanımlamak için yeni belirteçler tanımlar. Proto alanı için tanımlanan yeni değerler şunlardır:
- Bir RTP/SAVP veya RTP/SAVPF [RFC5124] akışı, Datagram Congestion Control Protocol (DCCP) ile birlikte DTLS üzerinden taşınıyorsa, belirteç sırasıyla
DCCP/TLS/RTP/SAVPveyaDCCP/TLS/RTP/SAVPFOLACAKTIR. - Bir RTP/SAVP veya RTP/SAVPF akışı UDP ile birlikte DTLS üzerinden taşınıyorsa, belirteç sırasıyla
UDP/TLS/RTP/SAVPveyaUDP/TLS/RTP/SAVPFOLACAKTIR.
"fmt" parametresi, RTP/SAVP için tanımlandığı şekilde OLACAKTIR.
DTLS-SRTP ile teklif/yanıt kullanımına ilişkin bilgiler için [RFC5763]’e bakınız.
Bu belge, TCP üzerinden taşınan RTP verilerinin nasıl korunacağını belirtmez. Olası yaklaşımlar arasında RTP’nin TCP üzerinden TLS içinde taşınması ([SRTP-NOT-MAND]’e bakınız) veya bu belgede açıklanana benzer bir mekanizmanın TCP üzerinde, TLS veya DTLS aracılığıyla kullanılması yer alır; tutarlı güvenilir ve güvenilmez aktarım sağlamak için DTLS tercih edilebilir. İkinci durumda, parçalama ve yeniden iletimlerin artık gerçekleşmemesi için DTLS’in profillenmesi gerekirdi. Her iki durumda da yeni bir belgeye ihtiyaç duyulacaktır.
#9. IANA Hususları
Bu belge, [RFC5246] uyarınca DTLS için yeni bir uzantı ekler:
enum { use_srtp (14) } ExtensionType;Bu uzantı yalnızca DTLS ile kullanılmalıdır ve RTP/SAVP için TCP’yi ele almayan, TLS’in TCP üzerinden kullanılabileceğini belirten TLS [RFC4572] ile kullanılmamalıdır.
Bölüm 4.1.2, tüm SRTPProtectionProfile değerlerinin RFC 5226 "Specification Required" ile tanımlanmasını gerektirir. IANA, başlangıçta bu belgenin Bölüm 4.1.2’sindeki değerlerle doldurulmuş bir DTLS SRTPProtectionProfile kaydı oluşturmuştur. Gelecekteki değerler, [RFC5226]’nın "Specification Required" profili aracılığıyla tahsis EDİLMELİDİR.
Bu teknik belge, [RFC4566] Bölüm 8.2.2’de tanımlanan "Session Description Protocol (SDP) Parameters" kaydını günceller. Özellikle, "proto" alanı tablosuna aşağıdaki değerleri ekler.
| Tür | SDP Adı | Referans | |------|------------------------|-----------| | proto| UDP/TLS/RTP/SAVP | [RFC5764] | | proto| DCCP/TLS/RTP/SAVP | [RFC5764] | | proto| UDP/TLS/RTP/SAVPF | [RFC5764] | | proto| DCCP/TLS/RTP/SAVPF | [RFC5764] |
IANA, TLS Extractor Label Registry’de bu teknik belgeye karşılık gelmesi için EXTRACTOR-dtls_srtp değerini kaydetmiştir.
#10. Teşekkürler
Katkıları, tartışmaları ve rehberlikleri için Flemming Andreasen, Francois Audet, Pasi Eronen, Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing ve Ben Campbell’a özel teşekkürler. Şekil 1, Pasi Eronen tarafından sağlanmıştır.
#11. Referanslar
11.1. Normatif Referanslar
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Mart 1997.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, Mart 2004.
- [RFC4347] Rescorla, E. ve N. Modadugu, "Datagram Transport Layer Security", RFC 4347, Nisan 2006.
- [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, Temmuz 2007.
- [RFC5246] Dierks, T. ve E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, Ağustos 2008.
- [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, Mart 2010.
- [RFC5761] Perkins, C. ve M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, Nisan 2010.
11.2. Bilgilendirici Referanslar
- [DTLS1.2] Rescorla, E. ve N. Modadugu, "Datagram Transport Layer Security version 1.2", Çalışma Taslağı, Ekim 2009.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. ve V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Temmuz 2003.
- [RFC4566] Handley, M., Jacobson, V. ve C. Perkins, "SDP: Session Description Protocol", RFC 4566, Temmuz 2006.
- [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, Temmuz 2006.
- [RFC5124] Ott, J. ve E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, Şubat 2008.
- [RFC5226] Narten, T. ve H. Alvestrand, "RFC'lerde IANA Değerlendirmeleri Bölümü Yazımı için Kılavuzlar", BCP 26, RFC 5226, Mayıs 2008.
- [RFC5389] Rosenberg, J., Mahy, R., Matthews, P. ve D. Wing, "NAT için Oturum Geçiş Yardımcıları (STUN)", RFC 5389, Ekim 2008.
- [RFC5763] Fischl, J., Tschofenig, H. ve E. Rescorla, "Datagram Taşıma Katmanı Güvenliği (DTLS) Kullanarak Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) Güvenlik Bağlamı Oluşturma Çerçevesi", RFC 5763, Mayıs 2010.
- [SRTP-NOT-MAND] Perkins, C. ve M. Westerlund, "RTP Neden Tek Bir Güvenlik Mekanizmasını Zorunlu Kılmaz", Devam Eden Çalışma, Ocak 2010.
#Ek A. DTLS'ye Genel Bakış
Bu bölüm, Datagram TLS (DTLS) ile aşina olmayanlar için kısa bir genel bakış sunar. DTLS, iyi bilinen Taşıma Katmanı Güvenliği (TLS) [RFC5246] protokolüne dayanan bir kanal güvenliği protokolüdür. TLS güvenilir bir taşıma kanalına (genellikle TCP) bağlıyken, DTLS UDP gibi güvenilmez taşımaları destekleyecek şekilde uyarlanmıştır. Bunun dışında, DTLS neredeyse TLS ile aynıdır ve genel olarak aynı kriptografik mekanizmaları destekler.
Her DTLS ilişkilendirmesi, eşlerin birbirlerini doğruladığı, algoritmaları, kipleri ve diğer parametreleri müzakere ettiği ve paylaşılan anahtarlama malzemesini tesis ettiği bir el sıkışma değişimiyle (aşağıda gösterilmiştir) başlar. Güvenilmez taşımayı desteklemek için, her iki taraf da bu iletilerin güvenilir teslimini sağlamak amacıyla yeniden iletim zamanlayıcıları tutar. El sıkışma tamamlandıktan sonra, şifrelenmiş veriler gönderilebilir.
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data* her zaman gönderilmeyen iletileri belirtir.
Şekil 5: Temel DTLS El Sıkışma Değişimi ([RFC4347]'den sonra).
Uygulama verileri, bir dizi DTLS "kayıt"ı olarak gönderilerek korunur. Bu kayıtlar bağımsızdır ve kayıp ya da yeniden sıralama durumlarında bile doğru şekilde işlenebilir. DTLS-SRTP'de, bu kayıt protokolü SRTP [RFC3711] ile değiştirilir.
#Ek B. Birden Fazla DTLS El Sıkışmasının Performansı
TLS, DTLS ve SSH gibi, satır içi anahtar yönetimi yapan güvenlik protokolleri için standart uygulama, her bir altta yatan ağ kanalı (TCP bağlantısı, UDP ana bilgisayar/port dörtlüsü vb.) için ayrı bir güvenlik ilişkilendirmesi tesis etmektir. Bunun, her kanal için güvenlik bağlamlarının sadeliği ve bağımsızlığı olmak üzere iki yönlü avantajı vardır.
RTP güvenliği bağlamında bu stratejinin ek yükü hakkında üç endişe dile getirilmiştir. İlk endişe, her kanal için ayrı bir açık anahtar işlemi yapılmasının getirdiği ek performans yüküdür. Buradaki geleneksel prosedür (TLS ve DTLS'de kullanılan), yeni ilişkilendirmeler için taze trafik anahtarları türetmekte kullanılabilecek bir ana bağlam tesis etmektir. TLS/DTLS'de buna "oturumun sürdürülmesi" denir ve eşler arasında şeffaf bir şekilde müzakere edilebilir.
İkinci endişe, sonraki bağlantıların kurulması ve mevcut bağlantılar için yeniden el sıkışma (yeniden anahtarlama için) sırasında oluşan ağ bant genişliği yüküdür. Özellikle, kanalların tamamen medyaya ayrılmış çok dar kapasite gereksinimlerine sahip olacağı ve yeniden el sıkışma tarafından taşırılacağı yönünde bir kaygı vardır. TLS'de yeniden el sıkışmanın (sürdürme ile) boyutuna ilişkin ölçümler, tam bir şifre takımı seçimi sunulursa bunun yaklaşık 300–400 bayt olduğunu göstermektedir. Tam bir el sıkışmanın boyutu ise sertifika ve anahtarlama malzemesi değişimi nedeniyle yaklaşık 1–2 kilobayt daha büyüktür.
Üçüncü endişe, ikinci, üçüncü ve sonraki kanalların tesis edilmesiyle ilişkili ek gidiş-dönüşlerdir. TLS/DTLS'de bunların tümü paralel olarak yapılabilir, ancak oturumun sürdürülmesinden yararlanmak için ilk kanal tesis edildikten sonra yapılmaları gerekir. İki kanal için bu, aşağıdakine benzer bir merdiven diyagramı sağlar (parantez içindeki sayılar medya kanal numaralarıdır):
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec (2)->
Finished (2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 readyŞekil 6: Paralel DTLS-SRTP müzakereleri.
Dolayısıyla, Kanal 1 hazır olduktan sonra Kanal 2'nin hazır olmasına kadar ek 1 RTT (gidiş-dönüş süresi) vardır. Eşler potansiyel olarak sürdürmeden vazgeçmeye istekliyse, el sıkışmaları aşağıdaki gibi iç içe geçirebilirler:
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
<- ClientHello (2)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 readyŞekil 7: İç içe geçmiş DTLS-SRTP müzakereleri.
Bu durumda, kanallar eşzamanlı olarak hazırdır; ancak el sıkışma (1) içindeki bir ileti kaybolursa, el sıkışma (2) ya tam bir yeniden el sıkışma gerektirir ya da Alice'in akıllıca davranıp sürdürme girişimini ilk el sıkışma tamamlanana kadar kuyruklamasını gerektirir. Not edilmelidir ki, paketi doğrudan düşürmek de işe yarar; çünkü Bob yeniden iletim yapacaktır.