Internet Engineering Task Force (IETF)

Yorum İsteği (Request for Comments): 8827

Kategori: Standartlar Yolu

ISSN: 2070-1721

Yazar: E. Rescorla (Mozilla)

Tarih: Ocak 2021

#Özet

Bu belge, tarayıcılarda dağıtılabilen gerçek zamanlı uygulamalarla kullanım için tasarlanmış bir protokol kümesi olan WebRTC için güvenlik mimarisini tanımlar — "Web üzerinde gerçek zamanlı iletişim".

#1. Giriş

Web Üzerinde Gerçek Zamanlı İletişim (RTCWEB) Çalışma Grubu, Web tarayıcıları arasında gerçek zamanlı iletişim için protokolleri standartlaştırmıştır; bunlar genel olarak "WebRTC" olarak adlandırılır [RFC8825]. WebRTC teknolojisinin başlıca kullanım senaryoları gerçek zamanlı ses ve/veya görüntü aramaları, Web konferansları ve doğrudan veri aktarımıdır. Çoğu geleneksel gerçek zamanlı sistemden (ör. SIP tabanlı [RFC3261] yazılım telefonları) farklı olarak, WebRTC iletişimleri Şekil 1'de gösterildiği gibi bir JavaScript (JS) API aracılığıyla doğrudan bir Web sunucusu tarafından denetlenir.

+----------------+
|                |
|   Web Server   |
|                |
+----------------+
    ^        ^
   /          \
HTTP         HTTP
 /            \
/              \
v                v
JS API         JS API
+-----------+  +-----------+
|           |  |           |
|  Browser  |<>|  Browser  |
|           |  |           |
+-----------+  +-----------+

Şekil 1: Basit bir WebRTC Sistemi

Daha karmaşık bir sistem, Şekil 2'de gösterildiği gibi alanlar arası aramalara izin verebilir. Alanlar arasında kullanılacak protokol WebRTC tarafından standartlaştırılmamıştır; ancak kurulu taban ve WebRTC API'sinin biçimi göz önüne alındığında, muhtemelen SIP gibi SDP tabanlı bir şey ya da Extensible Messaging and Presence Protocol (XMPP) [RFC6120] gibi bir protokol olacaktır.

+--------------+                +--------------+
|              | SIP, XMPP, ... |              |
|  Web Server  |<-------------->|  Web Server  |
|              |                |              |
+--------------+                +--------------+
       ^                                ^
       |                                |
     HTTP                             HTTP
       |                                |
       v                                v
    JS API                           JS API
+-----------+                     +-----------+
|           |        Media        |           |
|  Browser  |<------------------->|  Browser  |
|           |                     |           |
+-----------+                     +-----------+

Şekil 2: Çok Alanlı Bir WebRTC Sistemi

Bu sistem, [RFC8826]'da analiz edilen bir dizi yeni güvenlik zorluğu sunar. Bu belge, söz konusu belgede tanımlanan tehditleri ve gereksinimleri ele alan WebRTC için bir güvenlik mimarisini açıklar.

#2. Terminoloji

Bu belgede geçen "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, yalnızca ve ancak burada gösterildiği gibi tümü büyük harflerle göründüklerinde, BCP 14 [RFC2119] [RFC8174]'te tanımlandığı şekilde yorumlanacaktır.

#3. Güven Modeli

Bu mimarinin temel varsayımı, ağ kaynaklarının, kullanıcının Güvenilir Hesaplama Tabanı (TCB) olarak hizmet veren tarayıcıya köklenen bir güven hiyerarşisi içinde var olduğudur. Kullanıcının uygulanmasını istediği herhangi bir güvenlik özelliği nihai olarak tarayıcı tarafından (ya da tarayıcının doğruladığı bir özelliğin geçişli etkisiyle) garanti edilmelidir. Tersine, tarayıcı ele geçirilirse, hiçbir güvenlik garantisi mümkün değildir. Kullanıcının tarayıcıya gerçekten fazla güvenemediği durumlar (ör. İnternet kioskları) olduğunu unutmayın. Bu durumlarda sağlanan güvenlik düzeyi, tarayıcıya ne kadar güvendikleriyle sınırlıdır.

İdeal olarak, tarayıcı dışındaki herhangi bir varlığa güvenmeye dayanmak istemeyiz. Ancak, işlevsel bir sistem istiyorsak bu ne yazık ki mümkün değildir. Diğer ağ öğeleri iki kategoriye ayrılır: tarayıcı tarafından kimliği doğrulanabilen ve bu nedenle hassas kaynaklara erişim izinleri verilebilenler ile kimliği doğrulanamayan ve bu nedenle güvenilmeyenler.

3.1. Kimliği Doğrulanmış Varlıklar

Sistemde iki ana kimliği doğrulanmış varlık sınıfı vardır:

• Arama hizmetleri: Kökenini doğrulayabildiğimiz Web siteleri (tercihen HTTPS aracılığıyla; ancak bazı durumlarda, bir güvenlik duvarının arkasında olmak gibi topolojik olarak kısıtlı bir ağda bulunduğumuz için, kimlik doğrulamayı güvenlik duvarı davranışından çıkarım yoluyla yapabiliriz).
• Diğer kullanıcılar: Kökenini kriptografik olarak doğrulayabildiğimiz WebRTC eşleri (tercihen DTLS-SRTP aracılığıyla).

Yalnızca kimliği doğrulanmış olmak, bu varlıkları güvenilir yapmaz. Örneğin, https://www.example.org/ sitesinin Dr. Evil'e ait olduğunu doğrulayabilmemiz, Dr. Evil'in kameramıza ve mikrofonumuza erişmesine güvenebileceğimiz anlamına gelmez. Ancak bu, kullanıcıya Dr. Evil'e güvenip güvenmek istemediğini belirleme fırsatı verir; sonuçta, Dr. Evil ile iletişim kurmak istiyorlarsa (belki fidye ödemesini ayarlamak için), arama amacıyla kameraya ve mikrofona geçici olarak erişim vermek güvenlidir, ancak Dr. Evil'in arama dışında kameraya ve mikrofona erişebilmesini istemezler. Buradaki nokta, diğer öğelere ne kadar ve nasıl güveneceğimizi belirleyebilmemiz için önce onları tanımlamamız gerektiğidir. Ayrıca, bazen hangi politikaların uygulanacağını bilmeden önce iletişim kuran eşin kimliğini belirlememiz gerekir.

3.2. Kimliği Doğrulanmamış Varlıklar

Yukarıdaki varlıklar dışında, diğer ağ öğelerini genellikle tanımlayamayız; dolayısıyla onlara güvenemeyiz. Bu, onlarla herhangi bir etkileşimin mümkün olmadığı anlamına gelmez; ancak kötü niyetli davranacaklarını varsaymamız ve böyle davransalar bile güvenli olan bir sistem tasarlamamız gerektiği anlamına gelir.

#4. Genel Bakış

Bu bölüm, tipik bir WebRTC oturumunu tanımlar ve çeşitli güvenlik öğelerinin nasıl etkileştiğini ve kullanıcıya hangi garantilerin sağlandığını gösterir. Bu bölümdeki örnek, arama hizmetine asgari düzeyde güven duyarken, kullanıcı kimlik doğrulaması ve medya gizliliğinin azami düzeyde sağlandığı bir "en iyi durum" senaryosudur. Daha düşük güvenlik düzeylerine sahip daha basit sürümler de mümkündür ve uygun yerlerde metinde belirtilmiştir. Güvenlik (veya performans) ile gizlilik arasındaki gerilimi de kabul etmek önemlidir. Burada gösterilen örnek, gizlilikten ziyade güvenli aramaya daha fazla önem verilen ayarlara yöneliktir; ancak göreceğimiz gibi, farklı ödünleşimler yapmak isteyebileceğimiz ayarlar da vardır — bu mimari bu ayarlarla da uyumludur.

Bu örneğin amaçları doğrultusunda, aşağıdaki şekillerde gösterilen topolojiyi varsayıyoruz. Bu topoloji, Şekil 1'de gösterilen topolojiden türetilmiştir, ancak Alice ve Bob'un kimliklerini sinyalleşme sürecinden ayırır. Özellikle, Alice ve Bob, kimliklerini diğer taraflara göstermek için kullanılabilecek bir protokolü (örneğin OpenID Connect) destekleyen bir Kimlik Sağlayıcı (IdP) ile ilişkilere sahiptir. Örneğin, Alice bir sosyal ağda hesaba sahip olabilir ve bunu, bu sitelerde açıkça bir hesabı olmadan diğer Web sitelerinde kimlik doğrulamak için kullanabilir; bu, Web'de oldukça yaygın bir kalıptır. Bölüm 7.1, IdP'lere ve ilgili terminolojiye genel bir bakış sunar. Alice ve Bob'un farklı IdP'lerle ilişkileri de olabilir.

Not: Burada açıklanan IdP mekanizması geniş çapta benimsenmemiştir. IdP tabanlı kimlik doğrulamanın durumu hakkında daha fazla bilgi için Bölüm 7'ye bakın.

Kimlik sağlama ile sinyalleşmenin bu şekilde ayrılması, Alice ve Bob'un aynı sosyal ağın kullanıcıları olduğu ve kimliklerinin o alana dayandığı "kapalı dünya" durumlarında (Şekil 3) özellikle önemli değildir. Ancak federasyon (bir alandan diğerine aramalar; bkz. Şekil 4) ve güvenilmeyen sitelerde arama gibi, önemli olduğu ayarlar vardır; örneğin, belirli bir sosyal ağ üzerinden ilişkisi olan iki kullanıcının, poker sitesi gibi başka, güvenilmeyen bir sitede birbirini aramak istemesi gibi.

Sunucuların kendilerinin de harici bir kimlik hizmeti olan SSL/TLS sertifika altyapısı tarafından (gösterilmemiştir) kimliği doğrulandığını unutmayın. Web'de yaygın olduğu üzere, tüm kimlikler nihai olarak bu sisteme köklenir. Örneğin, bir IdP bir kimlik beyanında bulunduğunda, bu beyanı tüketen Güvenen Taraf (Relying Party), IdP'ye HTTPS üzerinden bağlanabildiği için doğrulama yapabilir.

+----------------+
|                |
|   Signaling    |
|   Server       |
|                |
+----------------+
    ^        ^
   /          \
HTTPS        HTTPS
 /            \
/              \
v                v
JS API         JS API
+-----------+  +-----------+
|           |  |           |
|  Browser  |<>|  Browser  |
|           |  |           |
+-----------+  +-----------+
     ^      ^--+     +--^     ^
     |         |     |        |
     v         |     |        v
+-----------+  |     |  +-----------+
|           |<--------+  |           |
|   IdP1    |  |        |    IdP2    |
|           |  +------->|           |
+-----------+            +-----------+

Alice                                 Bob

Şekil 3: IdP Tabanlı Kimlikle Bir Arama

Şekil 4, yukarıda belirtildiği gibi, Şekil 2'deki gibi iki ayrı alan arasındaki bir aramayla (yani federasyonlu bir durum) esasen aynı arama senaryosunu gösterir. Alanlar, belirtilmemiş bir protokol aracılığıyla iletişim kurar ve ayrı sinyalleşme ile kimlik sağlanması, alanlar arası protokolün ayrıntılarından bağımsız olarak aramaların kimliğinin doğrulanmasına olanak tanır.

        +----------------+    Unspecified    +----------------+
        |                |      protocol     |                |
        |    Signaling   |<----------------->|    Signaling   |
        |    Server      |  (SIP, XMPP, ...) |    Server      |
        |                |                   |                |
        +----------------+                   +----------------+
                 ^                                   ^
                 |                                   |
           HTTPS |                                   | HTTPS
                 |                                   |
                 |                                   |
                 v                                   v
              JS API                               JS API
        +-----------+                             +-----------+
        |           |             Media           |           |
  Alice |  Browser  |<--------------------------->|  Browser  | Bob
        |           |           DTLS+SRTP         |           |
        +-----------+                             +-----------+
              ^      ^--+                      +--^     ^
              |         |                      |        |
              v         |                      |        v
        +-----------+   |                      |  +-----------+
        |           |<-------------------------+  |           |
        |   IdP1    |   |                         |    IdP2   |
        |           |   +------------------------>|           |
        +-----------+                             +-----------+

Şekil 4: IdP Tabanlı Kimlikle Federasyonlu Bir Arama

4.1. İlk Sinyalleşme

Basitlik açısından, Şekil 3’teki topolojiyi varsayalım. Alice ve Bob, ortak bir arama hizmetinin her ikisi de kullanıcısıdır; her ikisi de arama hizmetinin arama yapmasına onay vermiştir (cihaz erişim izinlerinin tartışmasını daha sonraya erteliyoruz). Her ikisi de arama hizmetine HTTPS üzerinden bağlıdır ve bu nedenle kaynağı belirli bir güven düzeyiyle bilirler. Ayrıca her ikisinin de bir IdP ile hesapları vardır. Bu tür kimlik hizmetleri, Web ortamında giderek daha yaygın hale gelmektedir (Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger gibi teknolojilerle) ve çoğu zaman bir kullanıcının bir hizmetteki sıradan hesaplarının yan etkisi olarak sağlanır. Bu örnekte, Alice ve Bob’un ayrı bir kimlik hizmeti kullandığını gösteriyoruz; ancak kimlik hizmeti arama hizmetiyle aynı varlık olabilir ya da hiç kimlik hizmeti bulunmayabilir.

Alice arama hizmetine giriş yapmıştır ve Bob’u aramaya karar verir. Arama hizmetinden Bob’un çevrimiçi olduğunu görür ve arama hizmeti, Bob’un adının yanında "Call" yazan bir düğme biçiminde bir JS kullanıcı arayüzü sunar. Alice düğmeye tıklar; bu, bir PeerConnection nesnesi başlatan bir JS geri çağrısını tetikler. Bu aşamaya gelmek için bir güvenlik denetimi gerekmez: Herhangi bir kaynaktan gelen JS’nin buraya kadar gelmesine izin verilir.

PeerConnection oluşturulduktan sonra, arama hizmeti JS’sinin bazı medya ayarlarını yapması gerekir. Bu bir ses/video araması olduğu için, biri bir ses girişine, diğeri bir video girişine bağlı iki MediaStreamTrack içeren bir MediaStream oluşturur. Bu noktada ilk güvenlik denetimi gereklidir: Güvenilmeyen kaynakların kamera ve mikrofona erişmesine izin verilmez; bu nedenle tarayıcı Alice’ten izin ister.

Mevcut W3C API’sinde, bazı akışlar eklendikten sonra Alice’in tarayıcısı + JS’si aşağıdakileri içeren bir sinyalleşme mesajı [RFC8829] üretir:

• Medya kanalı bilgileri
• Interactive Connectivity Establishment (ICE) [RFC8445] adayları
• İletişimi bir anahtar çiftiyle bağlayan bir "fingerprint" özniteliği [RFC5763]. Bu anahtarın yalnızca bu çağrı için geçici olarak üretilmiş olabileceğini ya da bu etki alanına özgü olabileceğini ve Alice’in bu tür anahtarlardan çok sayıda bulundurabileceğini unutmayın.

Sinyalleşme mesajı gönderilmeden önce, PeerConnection kodu kimlik hizmetiyle iletişime geçer ve Alice’in kimliğini parmak izine bağlayan bir doğrulama alır. Ayrıntılar kimlik hizmetine bağlıdır (7. Bölümde tartışıldığı üzere PeerConnection bunlara karşı duyarsız olabilir), ancak şimdilik bunu bir OAuth belirteci olarak düşünmek en kolayıdır. Doğrulama, parmak izi dışında başka bilgileri de kimliğe bağlayabilir, ancak en azından parmak izini bağlaması gerekir.

Bu mesaj, örneğin fetch() [fetch] ya da WebSockets [RFC6455] kullanılarak, TLS [RFC8446] üzerinden sinyalleşme sunucusuna gönderilir. Sinyalleşme sunucusu Alice’in tarayıcısından gelen mesajı işler, bunun Bob’a yapılan bir çağrı olduğunu belirler ve Bob’un tarayıcısına bir sinyalleşme mesajı gönderir (yine, biçim şu anda tanımlı değildir). Bob’un tarayıcısındaki JS bunu işler ve Bob’u gelen çağrı ve Alice’in kimliği konusunda uyarır. Bu durumda Alice bir kimlik doğrulaması sağlamıştır ve bu nedenle Bob’un tarayıcısı doğrulamayı doğrulamak için Alice’in IdP’siyle iletişime geçer (bu da tarayıcının IdP hakkında özel bir bilgiye sahip olmadığı genel bir şekilde yapılır). 7.1 Bölümünde açıklandığı gibi, tarayıcının belirli bir güven ilişkisine sahip olduğu IdP’lerin bulunması da mümkündür. Bu, tarayıcının tarayıcı çerçevesinde Alice’ten gelen bir çağrı olduğunu belirten güvenilir bir öğe göstermesine olanak tanır. Alice Bob’un adres defterindeyse, bu arayüz onun gerçek adını, bir fotoğrafını vb. de içerebilir. Arama sitesi ayrıca Bob’un çağrıyı yanıtlamasına olanak tanıyan bir kullanıcı arayüzü öğesi (örneğin bir düğme) sağlayacaktır; ancak bu büyük olasılıkla güvenilir kullanıcı arayüzünün bir parçası değildir.

Bob kabul ederse, Alice tarafındaki mesajla bir PeerConnection başlatılır. Ardından Alice’in tarayıcısındakine benzer bir süreç gerçekleşir: Bob’un tarayıcısı ondan cihaz izni ister, medya akışları oluşturulur ve medya bilgileri, ICE adayları ve bir parmak izi içeren bir dönüş sinyalleşme mesajı sinyalleşme hizmeti aracılığıyla Alice’e geri gönderilir. Bob’un bir IdP ile ilişkisi varsa, mesaj bir kimlik doğrulaması da içerir.

Bu noktada, Alice ve Bob, karşı tarafın kendileriyle güvenli bir çağrı yapmak istediğini bilir. Yalnızca sinyalleşme sunucusunun sağladığı arayüze dayanarak, sinyalleşme sunucusunun çağrının Alice’ten Bob’a olduğunu iddia ettiğini bilirler. Bu güvenlik düzeyi, yalnızca mesajda parmak izinin bulunması ve bu mesajın sinyalleşme sunucusundan güvenli bir şekilde alınmasıyla sağlanır. Uç taraf mesajıyla birlikte bir kimlik doğrulaması gönderdiği için, bunun IdP’den de doğrulanabilir olduğunu bilirler. Şekil 4’te gösterildiği gibi çağrı federasyonluysa, Alice Bob’un kimliğini ne kendi sinyalleşme sunucusu ne de Bob’unkisi tarafından aracılık edilen bir yolla değil, doğrudan Bob’un IdP’siyle doğrulayabilir.

Elbette, Alice ya da Bob’dan biri bir IdP ile ilişkiye sahip olmasa bile çağrı kusursuz biçimde çalışır; yalnızca daha düşük bir güvence düzeyi elde edilir. Yani, arayan/arananın kimliği hakkında arama sitesinin iddia ettiği bilgilerle yetinirler. Ayrıca Alice anonim bir arama sitesi üzerinden anonim bir çağrı yapmak isteyebilir; bu durumda elbette herhangi bir kimlik doğrulaması sağlamaz ve arama sitesi kimliğini Bob’dan gizler.

4.2. Medya Onay Doğrulaması

[RFC8826], Bölüm 4.2’de açıklandığı üzere, medya onay doğrulaması ICE aracılığıyla sağlanır. Dolayısıyla Alice ve Bob birbirleriyle ICE denetimleri gerçekleştirir. Bu denetimlerin tamamlanmasının ardından, ICE dışı verileri göndermeye hazırdırlar.

Bu noktada Alice şunları bilir: (a) Bob (IdP’si aracılığıyla doğrulandığı varsayılırsa) ya da sinyalleşme hizmetinin Bob olduğunu iddia ettiği başka biri onunla trafik alışverişi yapmaya isteklidir ve (b) ya Bob, ICE aracılığıyla doğruladığı IP adresindedir ya da bu IP adresine giden trafikte yol üzerinde bulunan bir saldırgan trafiği saptırmaktadır. Alice ile Bob arasında yol üzerinde bulunan ancak sinyalleşme hizmetine bağlı olmayan bir saldırganın bu denetimleri taklit etmesi mümkün değildir; çünkü ICE kimlik bilgilerine sahip değildir. Bob da Alice’e ilişkin olarak aynı güvenlik güvencelerine sahiptir.

4.3. DTLS El Sıkışması

Gerekli ICE denetimleri tamamlandıktan sonra, Alice ve Bob güvenli bir kanal ya da kanallar kurabilir. Bu, medya kanalı için DTLS [RFC6347] ve SRTP [RFC3711] için DTLS-SRTP [RFC5763] anahtarlaması ve veri kanalları için DTLS üzerinden Stream Control Transmission Protocol (SCTP) [RFC8261] aracılığıyla gerçekleştirilir. Özellikle, Alice ve Bob ICE tarafından kurulmuş her bir bileşen üzerinde bir DTLS el sıkışması yapar. Toplam kanal sayısı, çoklama miktarına bağlıdır; en olası durumda hem RTP/RTCP çoklaması hem de aynı kanal üzerinde birden fazla medya akışının çoklanması kullanılır ve bu durumda yalnızca bir DTLS el sıkışması vardır. DTLS el sıkışması tamamlandığında, anahtarlar dışa aktarılır [RFC5705] ve medya kanalları için SRTP’yi anahtarlamakta kullanılır.

Bu noktada Alice ve Bob, anahtarları herhangi bir üçüncü taraf saldırgan tarafından bilinmeyen güvenli veri ve/veya medya kanallarından oluşan bir küme paylaştıklarını bilir. Alice ve Bob IdP’leri aracılığıyla kimlik doğruladıysa, sinyalleşme hizmetinin trafiğe bir ortadaki adam saldırısı uygulamadığını da bilirler. Bir IdP kullanmasalar bile, sinyalleşme hizmetinin bir ortadaki adam saldırısı gerçekleştirmeyeceğine dair asgari bir güven duydukları sürece, iletişimlerinin sinyalleşme hizmetine karşı da güvenli olduğunu (yani sinyalleşme hizmetinin iletişime pasif bir saldırı uygulayamayacağını) bilirler.

4.4. İletişim ve Onay Güncelliği

Güvenlik açısından bakıldığında, bundan sonrası biraz anticlimactic kalır: Alice ve Bob, DTLS tarafından uzlaşılan anahtarlarla korunan verileri değiş tokuş eder. Önceki bölümlerde tartışılan güvenlik güvenceleri nedeniyle, iletişimin şifreli ve kimliği doğrulanmış olduğunu bilirler.

Kurulması gereken tek kalan güvenlik özelliği "onay güncelliği"dir; yani Alice’in Bob’un hâlâ iletişimini almaya hazır olduğunu doğrulayabilmesini sağlamak ve Alice’in aniden çevrimdışı olmuş varlıklara büyük trafik hacimleri göndermeye devam etmesini önlemektir. ICE, yalnızca medya akışı yoksa periyodik Session Traversal Utilities for NAT (STUN) canlı tutma paketlerini belirtir. Burada onay meselesi daha zor olduğundan, WebRTC uygulamalarının [RFC7675]’te belirtilen onay güncelliği mekanizmasını kullanarak periyodik olarak canlı tutma paketleri göndermesini zorunlu kılıyoruz. Bir canlı tutma başarısız olursa ve yeni ICE kanalları kurulamazsa, oturum sonlandırılır.

#5. SDP Kimlik Özniteliği

SDP "identity" özniteliği, bir uç noktanın kimlik doğrulamasını eşine iletmek için kullandığı oturum düzeyinde bir özniteliktir. identity-assertion değeri, [RFC4648] Bölüm 4’te açıklandığı üzere base64 olarak kodlanır.

Bu bölümdeki prosedürler, bir uç noktanın kimlik doğrulamasının uç noktanın parmak izlerine bağlı olduğu varsayımına dayanır. Bu, bir doğrulamanın uç noktaya bağlanması için alternatif yöntemlerin tanımlanmasını engellemez; ancak bu tür yöntemler bu belirtimin kapsamı dışındadır.

Bir teklif ya da yanıtta birden fazla "identity" özniteliğinin anlamsal yorumu tanımlı değildir. Uygulamalar, bir teklif ya da yanıtta yalnızca tek bir "identity" özniteliği içermelidir (SHOULD) ve Güvenen Taraflar ilk "identity" özniteliği dışındakilerin tümünü yok saymayı tercih edebilir (MAY).

Ad: identity

Değer: identity-assertion

Kullanım Düzeyi: oturum

Karakter Kümesine Bağımlı: hayır

Varsayılan Değer: Yok

Sözdizimi:

identity-assertion       = identity-assertion-value
                           *(SP identity-extension)
identity-assertion-value = base64
identity-extension       = extension-name [ "=" extension-value ]
extension-name           = token
extension-value          = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
                           ; [RFC4566]’dan byte-string

<ALPHA and DIGIT as defined in [RFC4566]>
<base64 as defined in [RFC4566]>

Örnek:

a=identity:\
  eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
  In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
  IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
  aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9

Örnekteki uzun satırların bu belgenin sütun genişliği kısıtlarını karşılamak için katlandığını unutmayın; bir satırın sonundaki ters eğik çizgi ("\\"), onu izleyen satır sonu ve boşluklar yok sayılacaktır.

Bu belirtim, öznitelik için herhangi bir uzantı tanımlamaz.

identity-assertion değeri, JSON kodlu bir dizgedir [RFC8259]. JSON nesnesi iki anahtar içerir: "assertion" ve "idp". "assertion" anahtarının değeri, IdP tarafından tüketilen opak bir dizge içerir. "idp" anahtarının değeri, IdP’yi tanımlayan bir veya iki ek değere sahip bir sözlük içerir. Daha fazla ayrıntı için Bölüm 7.6’ya bakın.

5.1. Teklif/Yanıt Hususları

Bu bölüm, SDP "identity" özniteliği için SDP teklif/yanıt [RFC3264] hususlarını tanımlar.

Bu bölüm kapsamında, ilk teklif, SDP oturumunda SDP "identity" özniteliği içeren ilk teklifi ifade eder.

5.1.1. İlk SDP Teklifinin Oluşturulması

Bir teklifi gönderen taraf, kimlik doğrulamasını eşine sağlamak amacıyla teklife bir "identity" özniteliği ekler. Ayrıca, teklif veren taraf bir veya daha fazla SDP "fingerprint" özniteliği de ekler. "identity" özniteliği, oturum tanımındaki tüm "fingerprint" özniteliklerine bağlanmalıdır (MUST).

5.1.2. SDP Yanıtının Oluşturulması

Yanıt veren taraf bir "identity" özniteliği eklemeyi tercih ederse, Bölüm 5.1.1’deki adımların aynısını izler. Yanıt veren taraf, teklif veren tarafın bunu yapıp yapmadığından bağımsız olarak, bir "identity" özniteliği eklemeyi seçebilir ya da eklemeyebilir.

5.1.3. SDP Teklifinin veya Yanıtının İşlenmesi

Bir uç nokta, bir "identity" özniteliği içeren bir teklif veya yanıt aldığında, yanıt veren taraf bu öznitelik bilgilerini kullanarak eşinin kimliğini doğrulamak için IdP ile iletişime geçebilir. Kimlik doğrulaması Bölüm 7.1’de açıklandığı gibi üçüncü taraf bir IdP gerektiriyorsa, bu IdP’nin özel olarak yapılandırılmış olması gerekir. Kimlik doğrulaması başarısız olursa, yanıt veren taraf teklifi veya yanıtı hatalı biçimli olarak reddetmelidir (MUST).

5.1.4. Oturumun Değiştirilmesi

Bir oturum değiştirilirken, parmak izi kümesi değişmemişse, gönderen taraf aynı "identity" özniteliğini gönderebilir (MAY). Bu durumda, oluşturulmuş kimlik, mevcut DTLS bağlantılarına ve bu parmak izlerinden biri kullanılarak kurulan yeni bağlantılara uygulanmalıdır (MUST). [RFC8829], Bölüm 5.2.1’in her medya bölümünün aynı parmak izi kümesini kullanmasını gerektirdiğini unutmayın. Yeni bir "identity" özniteliği alınırsa, alıcı bu kimliği mevcut tüm bağlantılara uygulamalıdır (MUST).

Parmak izi kümesi değişirse, gönderen taraf ya yeni bir "identity" özniteliği göndermeli ya da hiç göndermemelidir (MUST). Parmak izlerindeki bir değişiklik aynı zamanda yeni bir DTLS bağlantısının kurulmasına neden olduğundan, alıcı daha önce oluşturulmuş tüm kimlikleri geçersiz kılmalıdır (MUST).

#6. Ayrıntılı Teknik Açıklama

6.1. Köken ve Web Güvenliği Sorunları

WebRTC için temel izin birimi kökendir [RFC6454]. Kökenin güvenliği, o kökenden gelen içeriğin kimliğinin doğrulanabilmesine bağlı olduğundan, köken yalnızca veriler HTTPS [RFC2818] üzerinden aktarılıyorsa güvenli biçimde belirlenebilir. Bu nedenle, istemciler HTTP ve HTTPS kökenlerini farklı izin alanları olarak ele almalıdır (MUST). Not: Bu, köken güvenlik modelinden doğrudan takip eder ve burada yalnızca açıklık sağlamak için belirtilmiştir.

Birçok Web tarayıcısı, HTTPS sayfalarında varsayılan olarak herhangi bir etkin karma içeriği şu anda yasaklamaktadır. Yani, JavaScript bir HTTPS sayfasına bir HTTP kökeninden yüklendiğinde bir hata gösterilir ve kullanıcı hatayı geçersiz kılmadıkça HTTP içeriği çalıştırılmaz. Böyle bir politikayı uygulayan herhangi bir tarayıcı, karma içerik sayfalarından WebRTC işlevselliğine erişime de izin vermez (çünkü karma içeriği hiç göstermezler). Etkin karma içeriğe izin veren tarayıcılar ise yine de karma içerik ayarlarında WebRTC işlevselliğini devre dışı bırakmalıdır (MUST).

Karma içerik olmayan bir sayfanın, çağrının süresi boyunca karma içeriğe dönüşmesinin mümkün olduğunu da unutmayın. Buradaki başlıca risk, yeni gelen güvensiz JS’nin medyayı saldırganın denetimindeki bir konuma yönlendirebilmesidir. Uygulamalar bu noktada ya çağrıyı sonlandırmayı ya da bir uyarı göstermeyi seçmelidir (MUST).

Ayrıca, güvenlik mimarisinin, anahtarlama malzemesinin kökenler arasında taşınabilir olmamasına dayandığını da unutmayın. Bununla birlikte, kimlik doğrulamasının sayfanın uygun gördüğü herhangi birine aktarılabileceği varsayılmaktadır.

6.2. Cihaz İzinleri Modeli

Uygulamalar, kamera ve/veya mikrofona erişim sağlamadan önce açık kullanıcı onayı almalıdır (MUST). Uygulamalar, HTTPS kökenleri için en azından aşağıdaki iki izin modelini desteklemelidir (MUST).

• Tek seferlik kamera/mikrofon erişimi talepleri.
• Kalıcı erişim talepleri.

HTTP kaynaklarının ağ saldırganlarına karşı güvenli bir şekilde doğrulanması mümkün olmadığından, uygulamalar HTTP kaynakları için verilen tüm izinleri REDDETMELİDİR.

Buna ek olarak, bu izin kapsamında elde edilen medyanın tek bir iletişim kurulan eşe gönderileceğini taahhüt eden erişim taleplerini DESTEKLEMELİDİRLER (elbette diğer eşler için başka talepler olabilir), örneğin: "Call customerservice@example.org". Bu talebin anlamsal karşılığı, kamera ve mikrofondan gelen medya akışının yalnızca belirtilen kimlikle ilişkili olduğu kriptografik olarak doğrulanmış (IdP mekanizması veya DTLS-SRTP el sıkışmasındaki bir X.509 sertifikası aracılığıyla) bir bağlantı üzerinden yönlendirileceğidir. Tarayıcıların X.509 sertifikalarına sahip olmasının pek olası olmadığı, ancak sunucuların sahip olabileceği unutulmamalıdır. Bu tür talepleri karşılayan tarayıcılar, izin isterken bu kimliği kullanıcıya açıkça GÖSTERMELİDİR. Bu tür izinlerin arkasındaki fikir, bir kullanıcının iletişim kurmaya istekli olduğu eşlerin oldukça dar bir listesine sahip olabilmesidir; örneğin, "Facebook'taki herhangi biri" yerine "annem". Dar kapsamlı izinler, tarayıcının bu denetimi uygulamasına olanak tanır.

API Gereksinimi: API, talepte bulunan JS'nin medyayı görme veya değiştirme yeteneğinden vazgeçmesini sağlayacak bir mekanizma SUNMALIDIR (örneğin MediaStream.record() aracılığıyla). İletişim kurulan eşin güvenli kimlik doğrulamasıyla birleştirildiğinde, bu durum kullanıcının aramayı yapan sitenin konuşmalarına erişmediğinden veya bunları değiştirmediğinden emin olmasını sağlar.

UI Gereksinimi: UI, kullanıcının kamerası ve mikrofonu kullanımdayken bunu açıkça GÖSTERMELİDİR. Bu gösterge JS tarafından bastırılamaz OLMALIDIR ve cihaz erişiminin nasıl sonlandırılacağını açıkça belirtmeli, ayrıca JS'nin engelleyemeyeceği şekilde kamera/mikrofon girişini derhal durdurmak için bir UI aracı SUNMALIDIR.

UI Gereksinimi: Kamera/mikrofon kullanımına ilişkin UI göstergesi tarayıcıda, tarayıcı penceresinin küçültülmesinin göstergenin gizlenmesine yol açacağı veya JS'nin üst üste binen bir pencere oluşturmasının göstergenin gizlenmesine neden olacağı şekilde görüntüleniyorsa, tarayıcı gösterge gizlendiğinde kamera ve mikrofon girişini DURDURMALIDIR. (Not: Telefonlar gibi, pencere tabanlı olmayan ancak iyi bildirim desteğine sahip sistemlerde bu gerekli olmayabilir.)

• Tarayıcılar, JS tarafından yapılan bir izin talebine yanıt olarak kalıcı ekran veya uygulama paylaşımı izinlerinin yüklenmesine İZİN VERMEMELİDİR. Bunun yerine, bir siteye izin vermek için izin ayarı veya uygulama yükleme deneyimi gibi başka bir kullanıcı eylemini zorunlu kılmalıdırlar.
• Tarayıcılar, medya talebi kamera ve mikrofon izinleri talebiyle aynı anda yapılsa bile, ekran veya uygulama paylaşımı izinleri için AYRI bir iletişim kutusu talebi SUNMALIDIR.
• Tarayıcı, şu anda paylaşılan tüm pencereleri belirsizliğe yer bırakmayacak bir şekilde GÖSTERMELİDİR. Görünür olmayan pencereler, uygulama paylaşılıyor olsa bile PAYLAŞILMAMALIDIR. Ekran paylaşılıyorsa, bu MUTLAKA belirtilmelidir.

Tarayıcılar, herhangi bir doğrudan kullanıcı onayı olmaksızın veri kanallarının kurulmasına İZİN VEREBİLİR. Siteler her zaman veriyi sunucu üzerinden tünelleyebildiğinden, veri kanalı üzerindeki ek kısıtlamalar ilave bir güvenlik sağlamaz. (İlgili bir konu için Bölüm 6.3'e bakınız.)

Bir tür doğrudan kullanıcı kimlik doğrulamasını destekleyen uygulamalar, bir kullanıcının yalnızca belirli iletişim kurulan eşlere yapılan çağrıları yetkilendirebileceği bir politika da SUNMALIDIR. Özellikle, uygulama aşağıdaki arayüzleri/denetimleri SUNMALIDIR:

• Doğrulanmış bu kullanıcıya gelecekteki çağrılara izin ver.
• Sistem adres defterimde bulunan herhangi bir doğrulanmış kullanıcıya gelecekteki çağrılara izin ver (bu elbette adres defteri entegrasyonu ile çalışır).

Uygulamalar ayrıca, kimlikleri doğrudan doğrulanabilir olan kullanıcılara yapılan çağrılar sürerken farklı bir kullanıcı arayüzü göstergesi SUNMALIDIR. Bölüm 6.5 bu konu hakkında daha fazla bilgi sağlar.

6.3. İletişim Onayı

WebRTC'nin tarayıcı istemci uygulamaları ICE'yi UYGULAMALIDIR. Yalnızca genel IP adreslerinde çalışan sunucu ağ geçidi uygulamaları, tam ICE veya ICE-Lite [RFC8445]'ten birini UYGULAMALIDIR.

Tarayıcı uygulamaları, belirli bir hedefe ICE dışı herhangi bir paket göndermeden önce ICE aracılığıyla erişilebilirliği DOĞRULAMALIDIR. Uygulamalar, işlem süresi boyunca (yani ICE yığınının bu işlem için yeni bir yanıt kabul edeceği süre boyunca) ICE işlem kimliğini JavaScript'e SAĞLAMAMALIDIR. JS'nin yerel ufrag ve parolayı denetlemesine İZİN VERİLMEMELİDİR; ancak elbette bunları bilir.

Sürekli onay gerekli olmakla birlikte, ICE [RFC8445], Bölüm 11 keepalive'ları tek yönlü olan STUN Binding Indication'ları kullanır ve bu nedenle yeterli değildir. Çalışma Grubu'nun mevcut görüş birliği, sürekli onay tazeliği için ICE Binding Request'lerin kullanılması yönündedir. ICE zaten uygulamaların bu tür isteklere yanıt vermesini gerektirir, dolayısıyla bu yaklaşım azami düzeyde uyumludur. Kullanılacak ICE zamanlayıcılarını profilleyen ayrı bir belge yayınlanacaktır; bkz. [RFC7675].

6.4. IP Konum Gizliliği

Varsayılan ICE davranışının bir yan etkisi, eşin kişinin IP adresini öğrenmesidir; bu da büyük miktarda konum bilgisinin açığa çıkmasına neden olur. Bu, bazı durumlarda olumsuz gizlilik sonuçları doğurur. Bu bölümdeki API gereksinimleri bu sorunu hafifletmeyi amaçlamaktadır. Bu gereksinimlerin, kullanıcının IP adresini kötü niyetli bir siteden korumayı amaçlamadığı unutulmamalıdır. Genel olarak, site herhangi bir HTTP işlemi üzerinden en azından kullanıcının sunucu-yansıtmalı adresini öğrenecektir. Bunun yerine, bu gereksinimler sitenin, çağrının diğer tarafına karşı kullanıcının IP adresini gizlemek için kullanıcıyla iş birliği yapmasına olanak tanımayı amaçlar. Kullanıcının IP adresini sunucudan gizlemek, istemci tarafında açık bir gizliliği koruyan mekanizma gerektirir (örneğin Tor Browser https://www.torproject.org/projects/torbrowser.html.en) ve bu belirtimin kapsamı dışındadır.

API Gereksinimi: API, kullanıcı çağrıyı yanıtlamaya karar verene kadar ICE müzakeresini bastırmasına (aday toplamaya belki izin vererek) olanak tanıyacak bir mekanizma SUNMALIDIR. (Not: Çağrının ne zaman yanıtlandığının belirlenmesi JS için bir sorudur.) Bu, kullanıcının bir çağrıyı yanıtlamamayı seçmesi durumunda eşin IP adresini öğrenmesini ve ayrıca kullanıcının çevrimiçi olup olmadığını öğrenmesini engellemesini sağlar.

API Gereksinimi: API, aramayı yapan uygulama JS'sinin yalnızca TURN adaylarının kullanılacağını belirtmesine olanak tanıyan bir mekanizma SUNMALIDIR. Bu, eşin kişinin IP adresini hiç öğrenmemesini sağlar. Bu mekanizma ayrıca, yerel adresleri sızdırdığı için ilgili adres alanının bastırılmasına da İZİN VERMELİDİR.

API Gereksinimi: API, aramayı yapan uygulamanın mevcut bir çağrıyı, TURN olmayan adayları ekleyecek şekilde yeniden yapılandırmasına olanak tanıyan bir mekanizma SUNMALIDIR. Bu gereksinim ve bir önceki gereksinim birlikte ele alındığında, gelen çağrı bildirimi sırasında ICE müzakeresinin hemen başlamasına olanak tanır; böylece arama sonrası gecikme azalır, ancak kullanıcı yanıtlamaya karar verene kadar IP adresinin ifşa edilmesi önlenir. Ayrıca, kullanıcıların çağrı süresince IP adreslerini tamamen gizlemelerine olanak tanır. Son olarak, kullanıcı artık IP adresini gizlemeye ihtiyaç duymadığına karar verirse, etkin bir çağrı sırasında TURN olmayan adaylara izin verecek şekilde yeniden yapılandırarak performansı optimize etmesi için bir mekanizma sağlar.

Bazı kuruluşların, dahili IP adreslerini dış dünyadan gizlemek üzere tasarlanmış proxy'ler ve/veya NAT'ler çalıştırabileceği unutulmamalıdır. WebRTC bu işlevi sağlamak için açık bir mekanizma SUNMAZ. Bu tür kuruluşların ya HTTP/HTTPS'i proxy'lemesi ve SDP'yi ve/veya JS'yi değiştirmesi gerekir ya da sitenin tercihlerinden bağımsız olarak "yalnızca TURN" politikasını ayarlamak için tarayıcı desteği gerekir.

Not: Bu gereksinimler, sitelerin kullanıcının IP adresini eşten gizlemesine olanak tanımayı amaçlar. Kullanıcının IP adresini aramayı yapan siteden gizleme konusunda rehberlik için bkz. [RFC8828].

6.5. İletişim Güvenliği

Uygulamalar SRTP [RFC3711]'yi DESTEKLEMELİDİR. Uygulamalar, SRTP anahtarlandırması için DTLS [RFC6347] ve DTLS-SRTP [RFC5763] [RFC5764]'ü DESTEKLEMELİDİR. Uygulamalar DTLS üzerinden SCTP [RFC8261]'yi DESTEKLEMELİDİR.

Tüm medya kanalları SRTP ve Güvenli Gerçek Zamanlı Taşıma Denetim Protokolü (SRTCP) aracılığıyla güvence altına ALINMALIDIR. Medya trafiği düz (şifrelenmemiş) RTP veya RTCP üzerinden GÖNDERİLMEMELİDİR; yani uygulamalar NULL şifreleme modlarına sahip şifre paketlerini müzakere ETMEMELİDİR. DTLS-SRTP her medya kanalı için SUNULMALIDIR. WebRTC uygulamaları SDP güvenlik tanımlarını [RFC4568] SUNMAMALI veya sunulmuşsa SEÇMEMELİDİR. Bir SRTP Ana Anahtar Tanımlayıcısı (MKI) KULLANILMAMALIDIR.

Tüm veri kanalları DTLS aracılığıyla güvence altına ALINMALIDIR.

Tüm uygulamalar, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 şifre paketi ve P-256 eğrisi [FIPS186] ile DTLS 1.2'yi DESTEKLEMELİDİR. Bu belirtimin önceki taslakları, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA şifre paketiyle DTLS 1.0'ı gerektiriyordu ve bu yazının kaleme alındığı tarihte bazı uygulamalar DTLS 1.2'yi desteklememektedir; yalnızca DTLS 1.2'yi destekleyen uç noktalar birlikte çalışabilirlik sorunlarıyla karşılaşabilir. SRTP için DTLS-SRTP koruma profili SRTP_AES128_CM_HMAC_SHA1_80 DESTEKLENMELİDİR. Uygulamalar, İleri Gizlilik (FS) sağlayan şifre paketlerini FS olmayan şifre paketlerine tercih ETMELİ ve Kimlik Doğrulamalı İlişkili Verili Şifreleme (AEAD) sağlayan şifre paketlerini AEAD olmayanlara tercih ETMELİDİR. Not: IETF, DTLS 1.3 [TLS-DTLS13]'ü standartlaştırma sürecindedir.

Uygulamalar DTLS yeniden müzakereyi UYGULAMAMALI ve sunulması halinde "no_renegotiation" uyarısı ile REDDETMELİDİR.

Uç noktalar TLS False Start [RFC7918]'ı UYGULAMAMALIDIR.

API Gereksinimi: API, varsayılan olarak her yeni çağrı için yeni bir kimlik doğrulama anahtar çifti OLUŞTURMALIDIR. Bu, ilişkilendirilemezliği sağlamak amacıyla tasarlanmıştır.

API Gereksinimi: API, çağrılar için bir anahtar çiftinin yeniden kullanılmasına olanak tanıyan bir yol SUNMALIDIR. Bu, anahtar sürekliliğine dayalı kimlik doğrulamayı etkinleştirmek için kullanılabilir ve anahtar üretim maliyetlerini amorti etmek için de kullanılabilir.

API Gereksinimi: Kullanıcı özellikle harici bir anahtar çifti yapılandırmadıkça, her kaynak (origin) için farklı anahtar çiftleri KULLANILMALIDIR. (Bu, bir süper çerez oluşturulmasını önler.)

API Gereksinimi: DTLS-SRTP kullanıldığında, API, müzakere edilen anahtar materyalini JS'nin elde etmesine İZİN VERMEMELİDİR. Bu gereksinim, medyanın uçtan uca güvenliğini korur.

UI Gereksinimleri: Kullanıcıya yönelik bir istemci, kullanıcının medyanın "güvenlik özelliklerini" belirlemesine olanak tanıyan bir "denetleyici" arayüzü SUNMALIDIR.

Aşağıdaki özellikler, kullanıcının bunları talep etmesini gerektirmeden, tarayıcı kromunda "önceden" GÖSTERİLMELİDİR:

• Bir istemci, kullanıcının şu anda görüntülenen ses ve video akış(lar)ı için "güvenlik özelliklerini" belirleyebileceği bir kullanıcı arayüzü SUNMALIDIR.
• Bir istemci, kullanıcının mikrofon sesinin ve kamera videosunun iletimleri için "güvenlik özelliklerini" belirleyebileceği bir kullanıcı arayüzü SUNMALIDIR.
• Uzak uç nokta, üçüncü tarafça doğrulanabilir bir X.509 sertifikası veya bir Web IdP mekanizması (bkz. Bölüm 7) aracılığıyla doğrudan doğrulanmışsa, "güvenlik özellikleri" doğrulanmış bilgileri İÇERMELİDİR. X.509 kimlikleri ve Web IdP kimlikleri benzer anlamsal özelliklere sahiptir ve benzer bir şekilde GÖSTERİLMELİDİR.

Aşağıdaki özellikler, kullanıcının bazı "derinlemesine inceleme" yapmasını gerektirme olasılığı daha yüksektir:

• "Güvenlik özellikleri", kullanımda olan kriptografik algoritmaları GÖSTERMELİDİR (örneğin, "AES-CBC").
• "Güvenlik özellikleri", FS sağlanıp sağlanmadığını GÖSTERMELİDİR.
• "Güvenlik özellikleri", sertifika parmak izi veya Kısa Kimlik Doğrulama Dizesi (SAS) gibi, eşin bant dışı doğrulanmasına olanak tanıyan bir mekanizma İÇERMELİDİR. Bunlar, eşlerin birbirlerini doğrulaması için karşılaştırılır.

#7. Web Tabanlı Eş Kimlik Doğrulaması

NOT: Bu bölümde açıklanan mekanizma, RTCWEB sürecinin nispeten erken bir aşamasında tasarlanmıştır. Geriye dönüp bakıldığında, Çalışma Grubu bu tür bir mekanizmaya yönelik ilgi konusunda fazla iyimserdi. Yayın tarihinde, yaygın olarak benimsenmemiş veya uygulanmamıştır. Bu belgede, yazım tarihi itibarıyla mevcut durumun bir açıklaması olarak yer almaktadır.

Bir dizi durumda, uç noktanın (yani tarayıcının), bağlı oldukları sinyalleşme hizmetine güvenmeden karşı taraftaki uç noktayı doğrudan tanımlayabilmesi arzu edilir. Örneğin, kullanıcılar, karşı tarafın doğrudan kimlik doğrulamasını almak istedikleri, federasyonlu bir sistem üzerinden çağrı yapıyor olabilirler. Alternatif olarak, asgari düzeyde güvendikleri bir sitede (örneğin bir poker sitesi) çağrı yapıyor olabilirler, ancak güvendikleri bir sitede (örneğin bir sosyal ağ) kimliği olan bir kişiyle iletişim kuruyor olabilirler.

Son zamanlarda, bir dizi Web tabanlı kimlik teknolojisi (OAuth, Facebook Connect vb.) geliştirilmiştir. Ayrıntılar değişiklik gösterse de, bu teknolojilerin ortak noktası, Alice'in kimliğini onaylayan Web tabanlı (yani HTTP/HTTPS) bir IdP'ye sahip olmalarıdır. Örneğin, Alice example.org'da bir hesaba sahipse, Alice example.org IdP'sini kullanarak başkalarına Alice'in alice@example.org olduğunu kanıtlayabilir. Bu teknolojilerin geliştirilmesi, aramayı kimlik sağlamadan ayırmamıza olanak tanır: Alice sizi bir poker sitesinde arayabilir ancak kendisini alice@example.org olarak tanımlayabilir.

Altta yatan teknoloji ne olursa olsun, genel ilke, kimliği doğrulanan tarafın sinyalleşme sitesi DEĞİL, kullanıcı (ve onun tarayıcısı) olmasıdır. Benzer şekilde, Güvenen Taraf (Relying Party) sinyalleşme sitesi değil, tarayıcıdır. Bu nedenle, tarayıcı IdP beyan sürecine girdiyi OLUŞTURMALI ve doğrulama sürecinin sonuçlarını, aramayı yapan site tarafından taklit edilemeyecek bir şekilde kullanıcıya GÖSTERMELİDİR.

Bu belgede tanımlanan mekanizmalar, tarayıcının herhangi bir belirli kimlik protokolünü uygulamasını veya herhangi bir belirli IdP'yi desteklemesini gerektirmez. Bunun yerine, bu belge herhangi bir IdP'nin uygulayabileceği genel bir arayüz SUNAR. Böylece, yeni IdP'ler ve protokoller, tarayıcıda veya aramayı yapan hizmette değişiklik yapılmadan devreye alınabilir. Bu, belirli bir kimlik protokolüne bağlı kalma gereksinimini ortadan kaldırır; ancak tarayıcılar, daha üstün performans veya UI özellikleri sağlamak amacıyla bazı kimlik protokollerini doğrudan uygulamayı tercih edebilir.

7.1. Güven İlişkileri: IdP'ler, AP'ler ve RP'ler

Herhangi bir federasyonlu kimlik protokolünün üç ana katılımcısı vardır:

• Kimlik Doğrulanan Taraf (AP): Kimliğini tesis etmeye çalışan varlık.
• Kimlik Sağlayıcı (IdP): AP'nin kimliği için kefil olan varlık.
• Güvenen Taraf (RP): AP'nin kimliğini doğrulamaya çalışan varlık.

AP ile IdP arasında bir tür hesap ilişkisi vardır: AP, IdP’ye kaydolur ve daha sonra doğrudan IdP’ye (örneğin bir parola ile) kimlik doğrulaması yapabilir. Bu, tarayıcının kullanıcının hangi IdP(ler) ile bir hesap ilişkisi olduğunu bir şekilde bilmesi gerektiği anlamına gelir. Bu bilgi ya kullanıcının tarayıcıya yapılandırdığı bir şey olabilir ya da çağrıyı yapan sitede yapılandırılıp Web uygulaması tarafından o sitedeki PeerConnection’a sağlanabilir. Bu bilginin tarayıcıya yapılandırılmasının kullanım senaryosu, kullanıcının tarayıcıya bir kimlik bağlamak için tarayıcıya “giriş yapabilmesidir”. Bu durum yeni tarayıcılarda yaygınlaşmaktadır. Ancak, IdP bilgisinin basitçe çağrıyı yapan uygulama tarafından sağlanabilmesi de mümkün olmalıdır.

Üst düzeyde, iki tür IdP vardır:

• Yetkili (Authoritative): Kimlik uzayının belirli bir bölümünü doğrulanabilir biçimde kontrol eden IdP’ler. Örneğin e-posta alanında, "example.com" işletmecisi "@example.com" ile biten ad alanı üzerinde tam kontrole sahiptir. Dolayısıyla, "alice@example.com" adresinin kime ait olduğu işletmecinin söylediği kişidir. Yetkili IdP’lere sahip sistemlere DNSSEC, SIP için bir kimlik sistemi (bkz. [RFC8224]) ve Facebook Connect (Facebook kimlikleri yalnızca Facebook sistemi bağlamında anlamlıdır) örnek verilebilir.
• Üçüncü Taraf (Third-Party): Kimlik uzayının kendi bölümü üzerinde kontrolü olmayan, bunun yerine kullanıcıların kimliklerini belirtilmemiş bir mekanizma aracılığıyla doğrulayan ve ardından buna tanıklık eden IdP’ler. IdP ad alanını fiilen kontrol etmediği için, RP’lerin IdP’nin AP kimliklerini doğru biçimde doğruladığına güvenmesi gerekir ve potansiyel olarak aynı kimlik uzayının aynı bölümüne tanıklık eden birden fazla IdP olabilir. Üçüncü taraf IdP’lerin muhtemelen en bilinen örneği SSL/TLS sertifikalarıdır; burada, herhangi bir alan adına tanıklık edebilen çok sayıda sertifika otoritesi (CA) bulunmaktadır.

Bir AP yetkili bir IdP aracılığıyla kimlik doğrulaması yapıyorsa, RP’nin IdP’ye olan güveni açıkça yapılandırmasına hiç gerek yoktur. Kimlik mekanizması, IdP’nin ilgili kimlik iddiasını gerçekten yaptığını doğrudan doğrulayabilir (bu belgede tanımlanan mekanizmaların sağladığı bir işlevdir) ve yetkili olduğu bir kimlik hakkında yaptığı herhangi bir iddia doğrudan doğrulanabilirdir. Bunun, IdP’nin yalan söyleyemeyeceği anlamına gelmediğine dikkat edin; bu, kullanıcının kimliğe baktığı anda verebileceği bir güvenilirlik değerlendirmesidir.

Buna karşılık, bir AP üçüncü taraf bir IdP aracılığıyla kimlik doğrulaması yapıyorsa, RP’nin bu IdP’ye açıkça güvenmesi gerekir (bu nedenle PKI tabanlı SSL/TLS istemcilerinde açık bir güven çıpası listesine ihtiyaç vardır). Güvenilebilir IdP’lerin listesi, kullanıcı tarafından ya da potansiyel olarak tarayıcı üreticisi tarafından doğrudan tarayıcıya yapılandırılmalıdır. Bu, yetkili IdP’lerin önemli bir avantajıdır ve üçüncü taraf IdP’ler desteklenecekse, potansiyel sayılarının oldukça sınırlı olması gerektiğini ima eder.

7.2. Çalışma Şekline Genel Bakış

Çağrıyı yapan siteye güvenmeden güvenlik sağlamak için, tarayıcının PeerConnection bileşeni IdP ile doğrudan etkileşim kurmalıdır. Mekanizmanın ayrıntıları W3C API belirtiminde açıklanmıştır, ancak genel fikir, PeerConnection bileşeninin IdP alan adına göre belirlenen IdP üzerindeki belirli bir konumdan JS indirmesidir. Bu JS (“IdP proxy’si”) tarayıcı içinde yalıtılmış bir güvenlik bağlamında çalışır ve PeerConnection onunla güvenli bir mesaj geçiş kanalı üzerinden konuşur.

Burada mantıksal olarak ayrı iki işlev olduğuna dikkat edin:

• Kimlik iddiası üretimi.
• Kimlik iddiası doğrulaması.

Her iki işlev için de aynı IdP JS “uç noktası” kullanılır; ancak elbette belirli bir IdP, bir işlevi ya da diğerini gerçekleştirmek için farklı davranabilir ve yeni JS yükleyebilir.

+--------------------------------------+
| Browser                              |
|                                      |
| +----------------------------------+ |
| | https://calling-site.example.com | |
| |                                  | |
| |        Calling JS Code           | |
| |               ^                  | |
| +---------------|------------------+ |
|                 | API Calls          |
|                 v                    |
|          PeerConnection              |
|                 ^                    |
|                 | API Calls          |
|     +-----------|-------------+      |   +---------------+
|     |           v             |      |   |               |
|     |       IdP Proxy         |<-------->|   Identity    |
|     |                         |      |   |   Provider    |
|     | https://idp.example.org |      |   |               |
|     +-------------------------+      |   +---------------+
|                                      |
+--------------------------------------+

PeerConnection nesnesi IdP ile etkileşime geçmek istediğinde, olayların sırası aşağıdaki gibidir:

1. Tarayıcı (PeerConnection bileşeni) bir IdP proxy’si örnekler. Bu, IdP’nin proxy içine gerekli olan herhangi bir JS’yi yüklemesine olanak tanır. Ortaya çıkan kod, IdP’nin güvenlik bağlamında çalışır.
2. IdP, [webrtc-api] içinde tanımlanan API’ye uyan bir nesneyi tarayıcıya kaydeder.
3. Tarayıcı, kimlik iddialarını oluşturmak veya doğrulamak için IdP proxy’si tarafından kaydedilen nesne üzerindeki yöntemleri çağırır.

Bu yaklaşım, tarayıcıyı herhangi bir belirli IdP’den ayrıştırmamıza olanak tanır; tarayıcının yalnızca IdP’nin JavaScript’ini nasıl yükleyeceğini—konumu IdP’nin kimliğine göre belirlenir—bilmesi ve kimlik iddialarını istemek ve doğrulamak için genel API’yi çağırması yeterlidir. IdP, genel protokolü IdP’ye özgü gereksinimlere bağlamak için gerekli olan mantığı sağlar. Böylece tek bir tarayıcı, tarayıcı yazıldığı sırada mevcut olmayan IdP’lerle ileriye dönük uyumluluk da dâhil olmak üzere, çok sayıda kimlik protokolünü destekleyebilir.

7.3. Standardizasyon İçin Maddeler

Bu çalışmanın iki bölümü vardır:

• Kullanıcının kimliğine kriptografik olarak bağlanması gereken sinyalleşme mesajından alınan kesin bilgi ve JavaScript Session Establishment Protocol (JSEP) mesajlarında iddiaları taşımaya yönelik bir mekanizma. Bu, Bölüm 7.4’te belirtilmiştir.
• IdP’ye yönelik arayüz; bu, eşlik eden W3C WebRTC API belirtiminde [webrtc-api] tanımlanmıştır.

WebRTC API belirtimi ayrıca, çağrıyı yapan uygulamanın hangi IdP’nin kullanılacağını belirtmek için kullanabileceği JavaScript arayüzlerini de tanımlar. Bu API, iddia üretme yeteneğine ve doğrulama sürecinin durumuna erişim de sağlar.

7.4. Kimlik İddialarının JSEP Teklif/Cevap İşlemlerine Bağlanması

Bir kimlik iddiası, kullanıcının kimliğini (IdP tarafından iddia edildiği şekliyle) SDP teklif/cevap alışverişine ve özellikle medyaya bağlar. Bunu gerçekleştirmek için PeerConnection, kimliğe bağlanacak DTLS-SRTP parmak izini sağlamalıdır. Bu, aşağıda gösterildiği gibi tek bir "fingerprint" anahtarına sahip bir JavaScript nesnesi (sözlük ya da hash olarak da bilinir) olarak sağlanır:

{
  "fingerprint":
    [
      { "algorithm": "sha-256",
        "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" },
      { "algorithm": "sha-1",
        "digest": "74:E9:76:C8:19:...:F4:45:6B" }
    ]
}

"fingerprint" değeri bir nesneler dizisidir. Dizideki her nesne, SDP’nin "fingerprint" özniteliğindeki algoritma ve özet değerlerine doğrudan karşılık gelen "algorithm" ve "digest" değerlerini içerir [RFC8122].

Bu nesne, IdP’ye iletilmek üzere bir JSON [RFC8259] dizesi olarak kodlanır. IdP tarafından döndürülen ve "identity" özniteliğinde kodlanan kimlik iddiası, Bölüm 7.4.1’de açıklandığı şekilde kodlanmış bir JSON nesnesidir.

Bu yapının IdP ya da IdP proxy’si tarafından yorumlanması gerekmez. Yalnızca RP’nin tarayıcısı tarafından tüketilir. IdP, bunu yalnızca tanıklık edilecek opak bir değer olarak ele alır. Dolayısıyla, IdP’yi değiştirmeden iddiaya yeni parametreler eklenebilir.

7.4.1. Kimlik İddialarının Taşınması

Bir IdP bir iddia ürettikten sonra (bkz. Bölüm 7.6), bu iddia SDP teklif/cevap mesajına eklenir. Bu, SDP’ye yeni bir "identity" özniteliği eklenerek yapılır. Bu değerin tek içeriği kimlik iddiasıdır. IdP tarafından üretilen kimlik iddiası UTF-8 bir JSON metni olarak kodlanır, ardından base64 ile kodlanır [RFC4648] ve bu dize elde edilir. Örneğin:

v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=fingerprint:sha-1 \
  4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:\
  eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
  In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
  IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
  aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
a=...
t=0 0
m=audio 6056 RTP/SAVP 0
a=sendrecv
...

Örnekteki uzun satırların, bu belgenin sütun genişliği kısıtlarını karşılamak için katlandığına dikkat edin; bir satırın sonundaki ters eğik çizgi ("\\"), onu izleyen satır başı ve boşluklar yok sayılacaktır.

"identity" özniteliği, oturum açıklamasındaki tüm "fingerprint" özniteliklerine tanıklık eder. Bu nedenle, oturum düzeyi bir özniteliktir.

Bir eş için alternatif sertifikalar sunmak amacıyla birden fazla "fingerprint" değeri kullanılabilir. "identity" özniteliği, oturum açıklamasının "fingerprint" özniteliklerinde yer alan tüm "fingerprint" değerlerini İÇERMEK ZORUNDADIR.

RP tarayıcısı, bir iddiayı doğrularken DTLS bağlantısı için kullanımda olan sertifikanın, IdP’den döndürülen parmak izi kümesi içinde olduğunu DOĞRULAMAK ZORUNDADIR.

7.5. IdP URI’sinin Belirlenmesi

IdP’nin, alan adı sahibinin sunucusunda yalnızca bir hesabı olan biri yerine alan adı sahibinin kontrolü altında olmasını sağlamak için (örneğin paylaşımlı barındırma senaryolarında), IdP JavaScript’i IdP’nin alan adına dayalı olarak belirlenmiş deterministik bir konumda barındırılır. Her IdP proxy örneği iki değerle ilişkilidir:

• authority: IdP hizmetinin barındırıldığı yetkili bileşen [RFC3986].
• protocol: IdP’nin kullandığı belirli IdP protokolü. Bu, tamamen opak ve IdP’ye özgü bir dizedir, ancak bir IdP’nin paralel olarak iki protokol uygulamasına olanak tanır. Bu değer boş dize olabilir. Protokol için bir değer sağlanmazsa, "default" değeri kullanılır.

Her IdP, ilk giriş sayfasını (yani IdP proxy’si tarafından yüklenen sayfayı) iyi bilinen bir URI’den sunmak ZORUNDADIR [RFC8615]. Bir IdP proxy’si için iyi bilinen URI, aşağıdaki URI bileşenlerinden oluşturulur:

1. Şema, "https:". Bir IdP HTTPS kullanılarak yüklenmek ZORUNDADIR [RFC2818].
2. Yetkili bileşen [RFC3986]. Yukarıda belirtildiği gibi, yetkili bileşen varsayılan olmayan bir port numarası veya userinfo alt bileşeni içerebilir. Bir iddia edilen kimliğin IdP adıyla eşleşip eşleşmediği belirlenirken her ikisi de kaldırılır.
3. Yol, /.well-known/idp-proxy/ ile başlar ve IdP protokolü ile devam eder. Ayırıcı karakterler '/' (%2F) ve '\\' (%5C), saldırganın istekleri denetlenen /.well-known/ önekisinin dışına yönlendirebilmesini önlemek için protokol alanında KESİNLİKLE izin verilmemelidir. Sorgu ve parça değerleri, '?' veya '#' karakterleri eklenerek KULLANILABİLİR.

Örneğin, "identity.example.com" IdP’si ve "example" protokolü için URL şu olurdu:

https://identity.example.com/.well-known/idp-proxy/example

IdP, bu URL’ye yapılan istekleri yönlendirebilir, ancak "https:" şemasını KORUMAK ZORUNDADIR. Bu, IdP’nin etkin kaynağını değiştirir, ancak IdP’nin iddia etmeye ve doğrulamaya yetkili olduğu kimliklerin alan adını değiştirmez. Yani, IdP hâlâ özgün alan adı için yetkili kabul edilir.

7.5.1. Kimlik Doğrulayan Taraf

Bir AP’nin uygun IdP alan adını nasıl belirlediği bu belirtimin kapsamı dışındadır. Ancak genel olarak AP’nin IdP ile gerçek bir hesap ilişkisi vardır; zira IdP’nin tanıklık ettiği kimlik budur. Dolayısıyla, AP bir şekilde IdP bilgisini tarayıcıya sağlar. Olası bazı mekanizmalar şunlardır:

• Kullanıcı tarafından doğrudan sağlanması.
• Çağrıyı yapan sitenin bildiği bazı IdP’ler kümesinden seçilmesi (örneğin, “Facebook Connect ile kimlik doğrula” yazan bir düğme).

7.5.2. Güvenen Taraf

AP’den farklı olarak, RP’nin IdP ile herhangi bir özel ilişkiye sahip olması gerekmez. Bunun yerine, AP tarafından sağlanan herhangi bir iddiayı işleyebilmesi gerekir. İddia, JSON olarak kodlanmış nesnenin "idp" alanında IdP’nin kimliğini içerdiğinden (bkz. Bölüm 7.6), URI doğrudan iddiadan oluşturulabilir ve böylece RP, kullanıcı etkileşimi olmadan iddianın teknik geçerliliğini doğrudan doğrulayabilir. Yetkili iddiaların yalnızca doğrulanabilir olması gerekir. Üçüncü taraf iddialar da Bölüm 8.1’de açıklandığı gibi yerel politika karşısında DOĞRULANMAK ZORUNDADIR.

7.6. İddiaların İstenmesi

Kimlik iddiası üretim sürecine girdi, Bölüm 7.4’te tanımlanan ve tarayıcının kullanmayı planladığı sertifika parmak izleri kümesini içeren JSON kodlu nesnedir. Bu dize, IdP’nin bakış açısından opak olarak ele alınır.

Tarayıcı ayrıca PeerConnection’ın çalıştığı kaynağı (origin) tanımlar; bu, IdP’nin iddiayı kimin talep ettiğine göre kararlar almasına olanak tanır.

Bir uygulama, bir IdP belirtirken isteğe bağlı olarak bir kullanıcı tanımlayıcı ipucu sağlayabilir. Bu değer, IdP’nin birden fazla kimlik arasından seçim yapmasına ya da istenmeyen kimlikler için iddia sağlamaktan kaçınmasına yardımcı olabilecek bir ipucudur. "username", IdP dışındaki hiçbir varlık için anlamı olmayan bir dizedir; IdP’nin bir iddiayı doğru şekilde oluşturabilmesi için ihtiyaç duyduğu herhangi bir veriyi içerebilir.

IdP tarafından başarıyla sağlanan bir kimlik iddiası aşağıdaki bilgileri içerir:

• idp: Bir IdP’nin alan adı ve protokol dizesi. Bu, iddiayı üreten IdP ya da protokolden farklı bir IdP veya protokolü TANIMLAYABİLİR.
• assertion: İddianın kendisini içeren opak bir değer. Bu, yalnızca tanımlanan IdP ya da istemcide çalışan IdP kodu tarafından yorumlanabilir.

Şekil 5, JSON biçiminde düzenlenmiş örnek bir iddiayı göstermektedir. Bu durumda, mesajın IdP’nin daha sonra doğrulayabileceği bir şekilde dijital olarak imzalanmış ya da MAC’lenmiş olduğu varsayılmaktadır; ancak bu bir uygulama ayrıntısıdır ve bu belgenin kapsamı dışındadır.

{
  "idp": {
    "domain": "example.org",
    "protocol": "bogus"
  },
  "assertion": "{\"identity\":\"bob@example.org\",\n                   \"contents\":\"abcdefghijklmnopqrstuvwyz\",\n                   \"signature\":\"010203040506\"}"
}

Şekil 5: Örnek İddia

Sinyalleşmede kullanılmak üzere iddia JSON olarak serileştirilir, base64 ile kodlanır [RFC4648] ve "identity" özniteliğinin değeri olarak kullanılır. IdP’ler, ürettikleri iddiaların farklı bir bağlamda yorumlanamamasını SAĞLAMALIDIR. Örneğin, iddia üretimi ve diğer amaçlar için farklı bir biçim kullanmalı ya da ayrı kriptografik anahtarlara sahip olmalıdırlar. Satır sonları yalnızca okunabilirlik için eklenmiştir.

7.7. Kullanıcı Girişinin Yönetilmesi

Bir kimlik beyanı oluşturabilmek için IdP’nin kullanıcının kimliğine dair kanıta ihtiyacı vardır. Kullanıcıların kimliğinin doğrulanması (parolalar veya çok faktörlü kimlik doğrulama kullanılarak) ve ardından sonraki alışverişler için çerezlerin [RFC6265] veya HTTP kimlik doğrulamasının [RFC7617] kullanılması yaygın bir uygulamadır.

IdP proxy’si, IdP kaynağının güvenlik bağlamında çalıştığı için çerezlere, HTTP kimlik doğrulama verilerine veya diğer kalıcı oturum verilerine erişebilir. Dolayısıyla, bir kullanıcı oturum açmışsa, IdP bir beyan oluşturmak için gereken tüm bilgilere sahip olabilir.

Bir IdP proxy’si, kullanıcı oturum açmamışsa veya IdP beyanı oluşturmadan önce kullanıcıyla daha fazla bilgi almak üzere etkileşime geçmek istiyorsa beyan oluşturamaz. IdP, beyanı oluşturmadan önce kullanıcıyla etkileşime geçmek isterse, IdP proxy’si bir beyan oluşturmayı başarısız kılabilir ve bunun yerine oturum açmanın sürdürülmesi gereken bir URL belirtebilir.

Uygulama daha sonra, kullanıcının kimlik bilgilerini girmesini sağlamak için sağlanan URL’yi yükleyebilir. Uygulama ile IdP arasındaki iletişim [webrtc-api]’de açıklanmaktadır.

#8. Beyanların Doğrulanması

Kimlik doğrulamanın girdisi, çözümlenmiş bir "identity" özniteliğinden alınan beyan dizgesidir.

IdP proxy’si beyanı doğrular. Kimlik protokolüne bağlı olarak proxy, IdP sunucusuyla veya diğer sunucularla iletişime geçebilir. Örneğin, OAuth tabanlı bir protokol büyük olasılıkla IdP’nin bir oracle olarak kullanılmasını gerektirirken, imza tabanlı bir şemada ilgili açık anahtarı önbelleğe almış olması koşuluyla IdP ile iletişime geçmeden de beyanı doğrulayabilir.

Mekanizma ne olursa olsun, doğrulama başarılı olursa, IdP proxy’sinden gelen başarılı bir yanıt aşağıdaki bilgileri içerir:

• identity: IdP’nin bakış açısından AP’nin kimliği. Bunun ayrıntıları Bölüm 8.1’de verilmiştir.
• contents: AP tarafından beyan oluşturma sürecine girdi olarak sağlanan, değiştirilmemiş özgün dizge.

Şekil 6, JSON biçiminde olan örnek bir yanıt göstermektedir.

{
  "identity": "bob@example.org",
  "contents": "{\"fingerprint\":[ ... ]}"
}

Şekil 6: Örnek Doğrulama Sonucu

8.1. Kimlik Biçimleri

IdP’den RP tarayıcısına sağlanan kimlik, kullanıcının kimliğini temsil eden bir dizgeden OLUŞMAK ZORUNDADIR. Bu dizge <user>@<domain> biçimindedir; burada "user" herhangi bir karakterden oluşur ve domain, U-label’lar dizisi olarak kodlanmış uluslararasılaştırılmış bir alan adıdır [RFC5890].

PeerConnection API’si bu dizgeyi aşağıdaki şekilde KONTROL ETMEK ZORUNDADIR:

1. Dizgenin "domain" bölümü IdP proxy’sinin alan adıyla eşitse, IdP bu alan için yetkili olduğundan beyan geçerlidir. Alan adlarının karşılaştırılması, [RFC5890]’ın 2.3.2.4 Bölümünde tanımlanan etiket eşdeğerliği kuralı kullanılarak yapılır.
2. Dizgenin "domain" bölümü IdP proxy’sinin alan adıyla eşit değilse, PeerConnection nesnesi aşağıdaki koşulların her ikisi de sağlanmadıkça beyanı REDDETMEK ZORUNDADIR:
3. IdP alan adı, kabul edilebilir bir üçüncü taraf IdP olarak güvenilir kabul ediliyorsa; ve
4. yerel ilke, kimlik dizgesinin domain bölümü için bu IdP alan adına güvenecek şekilde yapılandırılmışsa.

Kimliğin "user" bölümündeki herhangi bir '@' veya '%' karakteri, [RFC3986]’ın 2.1 Bölümünde tanımlanan "yüzde-kodlama" kurallarına göre kaçırılmak ZORUNDADIR. '@' ve '%' dışındaki karakterler yüzde-kodlanmamalıdır. Örneğin, "user" değeri "user@133" ve "domain" değeri "identity.example.com" olan bir durumda, ortaya çıkan dizge user%40133@identity.example.com olarak kodlanır.

Uygulamalara, kaçırılmış '@' karakterleri içeren kullanıcı kimliklerini görüntülerken dikkatli olmaları önerilir. Bu tür karakterler görüntüleme öncesinde çözülürse, uygulamalar IdP proxy’sinin alan adı ile kaçırılmış '@' işaretinden sonra görünen "<user>" bölümünün ima edebileceği herhangi bir alan adı arasında AYRIM YAPMAK ZORUNDADIR.

#9. Güvenlik Hususları

RTCWEB’in güvenlik analizinin büyük bir bölümü [RFC8826]’da veya yukarıdaki belirli sorunların tartışmalarında yer almaktadır. Tekrarı önlemek amacıyla bu bölüm, (a) bu belge tarafından ele alınmayan artık tehditlere ve (b) sistemdeki bileşenlerden birinin başarısızlığı veya yanlış davranışıyla üretilen tehditlere odaklanmaktadır.

9.1. İletişim Güvenliği

Sinyalleşme sunucusuna giden iletişimi güvence altına almak için HTTPS kullanılmıyorsa ve Bölüm 7’de kullanılan kimlik mekanizması da kullanılmıyorsa, yol üzerindeki herhangi bir saldırgan el sıkışma sırasında DTLS-SRTP parmak izlerini değiştirebilir ve böylece uç noktalardan birinin kimliği yerine kendi kimliğini koyabilir.

HTTPS kullanılsa bile, uygulamaların anahtarları bağımsız olarak doğrulayacak bir mekanizması yoksa sinyalleşme sunucusu potansiyel olarak bir ortadaki adam saldırısı gerçekleştirebilir. Bölüm 6.5’teki UI gereksinimleri, motive olmuş/güvenlik bilincine sahip kullanıcılar için böyle bir mekanizma sağlamayı amaçlar; ancak genel kullanım için uygun değildir. Bölüm 7’deki kimlik hizmeti mekanizmaları genel kullanım için daha uygundur. Ancak, kötü niyetli bir sinyalleşme hizmetinin bu tür kimlik beyanlarını kaldırabileceğini, fakat yenilerini uyduramayacağını unutmayın. Mevcut tüm üçüncü taraf güvenlik mekanizmalarının (X.509 sertifikaları veya üçüncü taraf bir IdP olsun) üçüncü tarafın güvenliğine dayandığını da not edin—bu, elbette kullanıcının Web sitesine olan bağlantısı için de geçerlidir. Kötü niyetli bir IdP’ye karşı güvenliği kendileri için güvence altına almak isteyen kullanıcılar bunu yalnızca eş kimlik bilgilerini doğrudan doğrulayarak yapabilirler; örneğin eşin parmak izini bant dışı olarak iletilmiş bir değerle karşılaştırarak.

Kötü niyetli içerik JavaScript’ine karşı korunmak için, bu JavaScript’in DTLS anahtarlarına doğrudan erişmesine—veya bu anahtarlarla hesaplamalar yapmasına—İZİN VERİLMEMELİDİR. Örneğin, içerik JS’si dijital imzalar hesaplayabilseydi, tarayıcının ürettiği bir anahtar için bir kimlik beyanı alması ve ardından bu beyanı artı anahtar tarafından yapılan bir imzayı kullanarak, içerik JS’sinin kontrol ettiği geçici bir Diffie-Hellman (DH) anahtarı altında korunan bir çağrıyı doğrulaması mümkün olurdu; bu da IdP mekanizmasının sağladığı güvenlik garantilerini ihlal ederdi. Yalnızca içerik JS’sinin anahtarlara doğrudan erişiminin engellenmesi yeterli değildir; bazılarınca WebCrypto API [webcrypto] ile yapılması önerildiği gibi. JS’nin ayrıca bir DTLS uç noktası için geçerli olacak işlemleri yapmasına da izin verilmemelidir. Açık ara en güvenli yaklaşım, anahtarla ilişkili gizli bilgilere dayanan herhangi bir işlemi yapma yeteneğini basitçe reddetmektir. Açık bilgilere dayanan işlemler—örneğin açık anahtarın dışa aktarılması—elbette güvenlidir.

9.2. Gizlilik

Bu belgedeki gereksinimler aşağıdakilere olanak tanımayı amaçlar:

• Kullanıcıların konumlarını ifşa etmeden çağrılara katılması.
• Olası arananların, bir çağrıyı yanıtlamayı kabul etmeden önce konumlarını ve hatta varlık durumlarını ifşa etmekten kaçınması.

Ancak bu gizlilik korumaları, TURN rölelerinin kullanılması ve ikinci durumda ICE’in geciktirilmesi açısından bir performans maliyeti getirir. Siteler, kullanıcıları bu ödünleşimler konusunda BİLGİLENDİRMELİDİR.

Burada sağlanan korumaların, kötü niyetli olmayan bir arama hizmetini varsaydığını unutmayın. Arama hizmeti her zaman kullanıcının durumunu ve (Tor gibi bir teknoloji kullanılmadıkça) IP adresini bildiğinden, kullanıcının gizliliğini dilediği gibi ihlal edebilir. Kullandıkları arama sitelerine karşı gizlilik isteyen kullanıcılar, Tor gibi ayrı gizliliği artıran teknolojiler kullanmalıdır. Birleşik WebRTC/Tor uygulamaları, sinyalleşmenin yanı sıra medyayı da Tor üzerinden yönlendirmeyi AYARLAMALIDIR. Günümüzde bu, oldukça optimal olmayan bir performans üretecektir.

Ayrıca, birden fazla çağrı boyunca kalıcı olan herhangi bir tanımlayıcı, özellikle anonim arama hizmetleri için gizlilik açısından potansiyel bir sorundur. Bu tür hizmetler, tarayıcıya her çağrı için ayrı DTLS anahtarları kullanmasını ve ayrıca çağrı boyunca TURN kullanmasını SÖYLEMELİDİR. Aksi halde, karşı taraf tarayıcıyı birden fazla çağrı boyunca ilişkilendirmesine olanak tanıyacak bağlantılanabilir bilgiler öğrenecektir. Buna ek olarak, tarayıcılar [RFC7022]’nin gizliliği koruyan CNAME oluşturma kipini UYGULAMALIDIR.

9.3. Hizmet Reddi

Bu belgede açıklanan rıza mekanizmaları, bir saldırganın kurbanın rızası olmadan büyük miktarda trafiği kurbana göndermek için istemcileri kullandığı hizmet reddi (DoS) saldırılarını azaltmayı amaçlar. Bu mekanizmalar, WebRTC’yi hiç uygulamamış kurbanları korumak için yeterli olsa da, WebRTC uygulamalarının daha dikkatli olması gerekir.

WebRTC üzerinden çağrı kabul eden bir çağrı merkezi örneğini düşünün. Bir saldırgan çağrı merkezinin ön yüzünü vekil olarak kullanır ve birden fazla istemcinin çağrı merkezine çağrı başlatmasını ayarlar. Bunun çoğu durumda kullanıcı rızası gerektirdiğini, ancak veri kanalının rıza gerektirmediği için bunun doğrudan kullanılabileceğini unutmayın. ICE tamamlandığında, tarayıcılar veri kanalını herhangi bir şekilde destekliyorsa kurban çağrı merkezine büyük miktarda veri göndermeye yönlendirilebilir. Bu saldırıyı önlemek, otomatik WebRTC uygulamalarının makul akış kontrolü uygulamasını ve kötü davranan çağrıları ayıklama (yani ICE yoklamalarına yanıt vermeyi durdurma) yeteneğine sahip olmasını; özellikle de makul ses ve video yokluğunda (saldırganın kontrol edemeyeceği) veri kanalını uzaktan kısabilmeye hazır olmasını gerektirir.

Buna bağlı başka bir saldırı, sinyalleşme hizmetinin ses ve video akışları için ICE adaylarını yer değiştirmesidir; böylece bir tarayıcı, diğer kurbanın ses içermesini beklediği bir alıcıya video göndermeye zorlanır (belki yalnızca ses bekliyordur!), bu da potansiyel olarak aşırı yüke neden olur. Birden fazla medya akışını tek bir taşıma üzerinde çoklamak, ICE keepalive’ları reddederek tek bir akışı ayrı ayrı bastırmayı zorlaştırır. Ya medya düzeyi (RTCP) mekanizmaları kullanılmalı ya da uygulama yanıtları tamamen reddetmeli ve böylece çağrıyı sonlandırmalıdır.

Magnus Westerlund tarafından önerilen bir başka saldırı, saldırganın teklifleri ve yanıtları aşağıdaki gibi çapraz bağlamasıdır. Kurbanı bir çağrı yapmaya teşvik eder ve ardından diğer kullanıcıların tarayıcılarını kontrol ederek onların birine çağrı yapmaya çalışmasını sağlar. Daha sonra bu teklifleri kurbana görünen yanıtlar hâline çevirir; bu da büyük ölçekli paralel çatallama gibi görünür. Kurban yine de ICE yanıtlarına karşılık verir ve artık tarayıcıların hepsi kurbana medya göndermeye çalışır. Uygulamalar, yalnızca sınırlı sayıda uzak ufrag için ICE Binding Requests’e yanıt vererek bu saldırıya karşı kendilerini savunabilir (JS’nin ufrag ve parolayı kontrol edememesi gereksiniminin nedeni budur). [RFC8834], Bölüm 13 bir dizi olası RTCP tabanlı DoS saldırısını ve karşı önlemleri belgelemektedir.

Üçüncü taraf kimlik mekanizması mevcut olsa bile, sinyalleşme iletilerinin büyük bölümleri imzalanmadığı sürece rıza konusunda bir ucu ya da diğerini şaşırtmaya dayalı saldırıların mümkün olduğunu unutmayın. Öte yandan, tüm iletinin imzalanması çağrı uygulamasının yeteneklerini ciddi biçimde kısıtlar; dolayısıyla burada zor ödünleşimler vardır.

9.4. IdP Kimlik Doğrulama Mekanizması

Bu mekanizma, güvenliği için IdP’ye ve PeerConnection’ın yukarıda açıklanan güvenlik değişmezlerini doğru biçimde zorlamasına dayanır. Yüksek düzeyde, IdP beyanında tanımlanan kullanıcının bu beyanla ilişkilendirilmek istediğini tasdik eder. Dolayısıyla, rastgele üçüncü tarafların bir kullanıcıya bağlı beyanlar elde etmesi veya RP’lerin kabul edeceği beyanlar üretmesi mümkün olmamalıdır.

9.4.1. PeerConnection Kaynak Denetimi

Temelde, IdP proxy’si tarayıcı tarafından yüklenen bir HTML ve JS parçasıdır; dolayısıyla bir Web saldırganının kendi IFRAME’ini oluşturmasını, IdP proxy HTML/JS’sini yüklemesini ve tarayıcıda üretilenler yerine kendi anahtarları üzerinde bir imza talep etmesini engelleyen bir şey yoktur. Ancak bu proxy saldırganın kaynağında olur, IdP’nin kaynağında değil. Yalnızca tarayıcının kendisi, (a) IdP’nin kaynağında olan ve (b) doğru API yüzeyini açığa çıkaran bir bağlamı örnekleyebilir. Bu nedenle, gönderici tarafındaki IdP proxy’si, beyanları yayımlamadan önce IdP’nin kaynağında çalıştığından EMİN OLMAK ZORUNDADIR.

Bu denetimin yalnızca tarayıcının (veya kullanıcının kimlik doğrulama verilerine erişimi olan başka bir varlığın) isteği ve dolayısıyla parmak izini tasdik ettiğini belirttiğini unutmayın. Tarayıcının ilişkili özel anahtara erişimi olduğunu kanıtlamaz; bu nedenle bir saldırgan kendi kimliğini başka bir tarafın anahtarlama materyaline bağlayabilir ve böylece Alice’ten geliyormuş gibi görünen bir çağrının aslında saldırgandan gelmesini sağlayabilir. Bu tür saldırılara karşı savunmalar için [RFC8844]’e bakın.

9.4.2. IdP Well-Known URI

Bölüm 7.5’te açıklandığı üzere, IdP proxy HTML/JS varış sayfası, IdP’nin alan adına dayalı iyi bilinen bir URI’de yer alır. Bu gereksinim, IdP’de bazı kaynaklara yazabilen (örneğin birinin Facebook duvarına) bir saldırganın IdP’yi taklit edebilmesini önler.

9.4.3. IdP Tarafından Üretilen Kimliklerin ve Barındıran Sitenin Gizliliği

IdP’nin beyanlarının yapısına bağlı olarak, arama sitesi kullanıcının kimliğini IdP’nin bakış açısından öğrenebilir. Çoğu durumda bu bir sorun değildir; çünkü kullanıcı zaten siteye IdP aracılığıyla kimlik doğrulaması yapmaktadır—örneğin kullanıcı Facebook Connect ile oturum açmış ve ardından çağrısını bir Facebook kimliğiyle doğrulamaktadır. Ancak diğer durumlarda, kullanıcı kimliğini siteye önceden ifşa etmemiş olabilir. Genel olarak, IdP’ler YA kullanıcının kimliğinin siteye açıklanmasına istekli olduğunu doğrulamalı (örneğin olağan IdP izinler iletişim kutusu aracılığıyla) YA DA kimlik bilgilerinin yalnızca bilinen RP’lere (örneğin sosyal grafik komşulukları) erişilebilir olmasını, ancak arama sitesine açık olmamasını ayarlamalıdır. Beyan isteğinin "domain" alanı, kullanıcının kimliğini arama sitesine açıklamayı kabul edip etmediğini denetlemek için kullanılabilir; PeerConnection tarafından sağlandığından doğru olduğuna güvenilebilir.

9.4.4. Üçüncü Taraf IdP’lerin Güvenliği

Yukarıda tartışıldığı gibi, her üçüncü taraf IdP yeni bir evrensel güven noktası temsil eder ve bu nedenle bu IdP’lerin sayısının oldukça sınırlı olması gerekir. Facebook gibi niteliksiz kimlikler verenler dâhil çoğu IdP, yetkili IdP’ler olarak yeniden çerçevelenebilir (örneğin, 123456@facebook.com). Ancak bu durumlarda, kullanıcı arayüzü sonuçları tamamen arzu edilir değildir. Ara bir yaklaşım, büyük yetkili IdP’ler için özel (potansiyel olarak kullanıcı tarafından yapılandırılabilir) bir UI’ye sahip olmaktır; böylece kullanıcı çağrının Facebook, Google vb. tarafından doğrulandığını anında kavrayabilir.

9.4.4.1. Karıştırılabilir Karakterler

Kimlik dizgilerinde geniş bir karakter aralığına izin verildiğinden, saldırganların diğer kimliklerle karıştırılabilir kimlikler oluşturabilmesi mümkün olabilir (bu konu hakkında daha fazla bilgi için bkz. [RFC6943]). Bu, bu türdeki herhangi bir tanımlayıcı alanında (örneğin e-posta adresleri) görülen bir sorundur. Tanımlayıcıları üretenlerin karma yazı sistemlerinden ve benzer şekilde karıştırılabilir karakterlerden kaçınması gerekir. Bu tanımlayıcıları bir kullanıcıya sunanların, karma yazı sistemi kullanımının söz konusu olduğu durumları vurgulamayı dikkate alması gerekir (bkz. [RFC5890], Bölüm 4.4). Diğer en iyi uygulamalar hâlen geliştirme aşamasındadır.

9.4.5. Web Güvenlik Özelliği Etkileşimleri

Aşağıda ele alındığı üzere, bazı isteğe bağlı Web güvenlik özellikleri bu mekanizma için sorunlara yol açma potansiyeline sahiptir.

9.4.5.1. Açılır Pencere Engelleme

Açılır pencere engelleme kullanımdayken, IdP proxy açılır pencereler, diyaloglar veya kullanıcı etkileşiminin başka herhangi bir biçimini oluşturamaz. Bu durum, IdP proxy’nin kullanıcı etkileşimini dolanmak için kullanılmasını engeller. "LOGINNEEDED" iletisi, IdP proxy’nin, kullanıcı oturumu açma gereksinimini çağıran siteye bildirmesine olanak tanır ve bu gereksinimi, IdP proxy’nin kendisinden doğrudan kullanıcı etkileşimine başvurmadan karşılamak için gerekli bilgileri sağlar.

9.4.5.2. Üçüncü Taraf Çerezleri

Bazı tarayıcılar, gizlilik nedenleriyle kullanıcıların üçüncü taraf çerezlerini (üst düzey sayfa dışındaki kökenlerle ilişkili çerezler) engellemesine izin verir. Oturumları kalıcı kılmak için çerez kullanan herhangi bir IdP, üçüncü taraf çerez engellemesi nedeniyle çalışamaz hâle gelecektir. Bir seçenek bunu bir sınırlama olarak kabul etmektir; bir diğer seçenek ise PeerConnection nesnesinin, IdP proxy için üçüncü taraf çerez engellemesini devre dışı bırakmasını sağlamaktır.

#10. IANA Hususları

Bu belirtim, [RFC4566] Bölüm 8.2.4’teki prosedürlere göre "identity" SDP özniteliğini tanımlar. Kayıt için gerekli bilgiler burada yer almaktadır:

• İrtibat Adı: IESG (iesg@ietf.org)
• Öznitelik Adı: identity
• Uzun Biçim: identity
• Öznitelik Türü: oturum
• Karakter Kümesi Hususları: Bu öznitelik karakter kümesi özniteliğine tabi değildir.
• Amaç: Bu öznitelik, bir kimliği taşıma katmanı güvenlik oturumuna bağlayan bir kimlik beyanı taşır.
• Uygun Değerler: RFC 8827’nin Bölüm 5’ine bakınız.
• Mux Kategorisi: NORMAL

Bu bölüm, [RFC8615]’te tanımlanan "idp-proxy" iyi bilinen URI’sini kaydeder.

• URI soneki: idp-proxy
• Değişiklik denetleyicisi: IETF

#11. Kaynaklar

11.1. Normatif Kaynaklar

• [FIPS186] Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), "Dijital İmza Standardı (DSS)", NIST PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, Temmuz 2013, https://doi.org/10.6028/NIST.FIPS.186-4.
• [RFC2119] Bradner, S., "Gereksinim Düzeylerini Belirtmek için RFC’lerde Kullanılan Anahtar Sözcükler", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Mart 1997, https://www.rfc-editor.org/info/rfc2119.
• [RFC2818] Rescorla, E., "TLS Üzerinden HTTP", RFC 2818, DOI 10.17487/RFC2818, Mayıs 2000, https://www.rfc-editor.org/info/rfc2818.
• [RFC3264] Rosenberg, J. ve H. Schulzrinne, "Oturum Tanımlama Protokolü (SDP) ile Bir Teklif/Cevap Modeli", RFC 3264, DOI 10.17487/RFC3264, Haziran 2002, https://www.rfc-editor.org/info/rfc3264.
• [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP)", RFC 3711, DOI 10.17487/RFC3711, Mart 2004, https://www.rfc-editor.org/info/rfc3711.
• [RFC3986] Berners-Lee, T., Fielding, R. ve L. Masinter, "Tekdüzen Kaynak Tanımlayıcısı (URI): Genel Sözdizimi", STD 66, RFC 3986, DOI 10.17487/RFC3986, Ocak 2005, https://www.rfc-editor.org/info/rfc3986.
• [RFC4566] Handley, M., Jacobson, V. ve C. Perkins, "SDP: Oturum Tanımlama Protokolü", RFC 4566, DOI 10.17487/RFC4566, Temmuz 2006, https://www.rfc-editor.org/info/rfc4566.
• [RFC4568] Andreasen, F., Baugher, M. ve D. Wing, "Ortam Akışları için Oturum Tanımlama Protokolü (SDP) Güvenlik Tanımları", RFC 4568, DOI 10.17487/RFC4568, Temmuz 2006, https://www.rfc-editor.org/info/rfc4568.
• [RFC4648] Josefsson, S., "Base16, Base32 ve Base64 Veri Kodlamaları", RFC 4648, DOI 10.17487/RFC4648, Ekim 2006, https://www.rfc-editor.org/info/rfc4648.
• [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, DOI 10.17487/RFC5763, Mayıs 2010, https://www.rfc-editor.org/info/rfc5763.
• [RFC5764] McGrew, D. ve E. Rescorla, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) için Anahtarların Kurulmasını Sağlayan Datagram Taşıma Katmanı Güvenliği (DTLS) Uzantısı", RFC 5764, DOI 10.17487/RFC5764, Mayıs 2010, https://www.rfc-editor.org/info/rfc5764.
• [RFC5890] Klensin, J., "Uygulamalar için Uluslararasılaştırılmış Alan Adları (IDNA): Tanımlar ve Belge Çerçevesi", RFC 5890, DOI 10.17487/RFC5890, Ağustos 2010, https://www.rfc-editor.org/info/rfc5890.
• [RFC6347] Rescorla, E. ve N. Modadugu, "Datagram Taşıma Katmanı Güvenliği Sürüm 1.2", RFC 6347, DOI 10.17487/RFC6347, Ocak 2012, https://www.rfc-editor.org/info/rfc6347.
• [RFC6454] Barth, A., "Web Kökeni Kavramı", RFC 6454, DOI 10.17487/RFC6454, Aralık 2011, https://www.rfc-editor.org/info/rfc6454.
• [RFC7022] Begen, A., Perkins, C., Wing, D. ve E. Rescorla, "RTP Kontrol Protokolü (RTCP) Kanonik Adlarının (CNAME) Seçilmesi için Kılavuzlar", RFC 7022, DOI 10.17487/RFC7022, Eylül 2013, https://www.rfc-editor.org/info/rfc7022.
• [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T. ve M. Thomson, "Onay Tazeliği için NAT Geçiş Yardımcıları (STUN) Kullanımı", RFC 7675, DOI 10.17487/RFC7675, Ekim 2015, https://www.rfc-editor.org/info/rfc7675.
• [RFC7918] Langley, A., Modadugu, N. ve B. Moeller, "Taşıma Katmanı Güvenliği (TLS) Yanlış Başlatma", RFC 7918, DOI 10.17487/RFC7918, Ağustos 2016, https://www.rfc-editor.org/info/rfc7918.
• [RFC8122] Lennox, J. ve C. Holmberg, "Oturum Tanımlama Protokolü (SDP) İçinde Taşıma Katmanı Güvenliği (TLS) Protokolü Üzerinden Bağlantı Yönelimli Ortam Taşıma", RFC 8122, DOI 10.17487/RFC8122, Mart 2017, https://www.rfc-editor.org/info/rfc8122.
• [RFC8174] Leiba, B., "RFC 2119 Anahtar Sözcüklerinde Büyük Harf ile Küçük Harf Belirsizliği", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mayıs 2017, https://www.rfc-editor.org/info/rfc8174.
• [RFC8259] Bray, T., Ed., "JavaScript Nesne Gösterimi (JSON) Veri Değişim Biçimi", STD 90, RFC 8259, DOI 10.17487/RFC8259, Aralık 2017, https://www.rfc-editor.org/info/rfc8259.
• [RFC8261] Tuexen, M., Stewart, R., Jesup, R. ve S. Loreto, "SCTP Paketlerinin Datagram Taşıma Katmanı Güvenliği (DTLS) Kapsüllenmesi", RFC 8261, DOI 10.17487/RFC8261, Kasım 2017, https://www.rfc-editor.org/info/rfc8261.
• [RFC8445] Keranen, A., Holmberg, C. ve J. Rosenberg, "Etkileşimli Bağlantı Kurma (ICE): Ağ Adres Çevirici (NAT) Geçişi için Bir Protokol", RFC 8445, DOI 10.17487/RFC8445, Temmuz 2018, https://www.rfc-editor.org/info/rfc8445.
• [RFC8446] Rescorla, E., "Taşıma Katmanı Güvenliği (TLS) Protokolü Sürüm 1.3", RFC 8446, DOI 10.17487/RFC8446, Ağustos 2018, https://www.rfc-editor.org/info/rfc8446.
• [RFC8615] Nottingham, M., "İyi Bilinen Tekdüzen Kaynak Tanımlayıcıları (URI’ler)", RFC 8615, DOI 10.17487/RFC8615, Mayıs 2019, https://www.rfc-editor.org/info/rfc8615.
• [RFC8825] Alvestrand, H., "Genel Bakış: Tarayıcı Tabanlı Uygulamalar için Gerçek Zamanlı Protokoller", RFC 8825, DOI 10.17487/RFC8825, Ocak 2021, https://www.rfc-editor.org/info/rfc8825.
• [RFC8826] Rescorla, E., "WebRTC için Güvenlik Hususları", RFC 8826, DOI 10.17487/RFC8826, Ocak 2021, https://www.rfc-editor.org/info/rfc8826.
• [RFC8829] Uberti, J., Jennings, C. ve E. Rescorla, Ed., "JavaScript Oturum Kurma Protokolü (JSEP)", RFC 8829, DOI 10.17487/RFC8829, Ocak 2021, https://www.rfc-editor.org/info/rfc8829.
• [RFC8834] Perkins, C., Westerlund, M. ve J. Ott, "WebRTC’de Ortam Taşıma ve RTP Kullanımı", RFC 8834, DOI 10.17487/RFC8834, Ocak 2021, https://www.rfc-editor.org/info/rfc8834.
• [RFC8844] Thomson, M. ve E. Rescorla, "Oturum Tanımlama Protokolü (SDP) ile TLS Kullanımlarında Bilinmeyen Anahtar Paylaşımı Saldırıları", RFC 8844, DOI 10.17487/RFC8844, Ocak 2021, https://www.rfc-editor.org/info/rfc8844.
• [webcrypto] Watson, M., "Web Kriptografi API’si", W3C Tavsiyesi, 26 Ocak 2017, https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/.
• [webrtc-api] Jennings, C., Boström, H. ve J.-I. Bruaroey, "WebRTC 1.0: Tarayıcılar Arasında Gerçek Zamanlı İletişim", W3C Önerilen Tavsiye, https://www.w3.org/TR/webrtc/.

11.2. Bilgilendirici Kaynaklar

• [fetch] van Kesteren, A., "Fetch", https://fetch.spec.whatwg.org/.
• [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. ve E. Schooler, "SIP: Oturum Başlatma Protokolü", RFC 3261, DOI 10.17487/RFC3261, Haziran 2002, https://www.rfc-editor.org/info/rfc3261.
• [RFC5705] Rescorla, E., "Taşıma Katmanı Güvenliği (TLS) için Anahtar Malzemesi Dışa Aktarıcıları", RFC 5705, DOI 10.17487/RFC5705, Mart 2010, https://www.rfc-editor.org/info/rfc5705.
• [RFC6120] Saint-Andre, P., "Genişletilebilir Mesajlaşma ve Durum Protokolü (XMPP): Çekirdek", RFC 6120, DOI 10.17487/RFC6120, Mart 2011, https://www.rfc-editor.org/info/rfc6120.
• [RFC6265] Barth, A., "HTTP Durum Yönetim Mekanizması", RFC 6265, DOI 10.17487/RFC6265, Nisan 2011, https://www.rfc-editor.org/info/rfc6265.
• [RFC6455] Fette, I. ve A. Melnikov, "WebSocket Protokolü", RFC 6455, DOI 10.17487/RFC6455, Aralık 2011, https://www.rfc-editor.org/info/rfc6455.
• [RFC6943] Thaler, D., Ed., "Güvenlik Amaçlı Tanımlayıcı Karşılaştırmasındaki Sorunlar", RFC 6943, DOI 10.17487/RFC6943, Mayıs 2013, https://www.rfc-editor.org/info/rfc6943.
• [RFC7617] Reschke, J., "‘Basic’ HTTP Kimlik Doğrulama Şeması", RFC 7617, DOI 10.17487/RFC7617, Eylül 2015, https://www.rfc-editor.org/info/rfc7617.
• [RFC8224] Peterson, J., Jennings, C., Rescorla, E. ve C. Wendt, "Oturum Başlatma Protokolünde (SIP) Kimliği Doğrulanmış Kimlik Yönetimi", RFC 8224, DOI 10.17487/RFC8224, Şubat 2018, https://www.rfc-editor.org/info/rfc8224.
• [RFC8828] Uberti, J. ve G. Shieh, "WebRTC IP Adresi İşleme Gereksinimleri", RFC 8828, DOI 10.17487/RFC8828, Ocak 2021, https://www.rfc-editor.org/info/rfc8828.
• [TLS-DTLS13] Rescorla, E., Tschofenig, H. ve N. Modadugu, "Datagram Taşıma Katmanı Güvenliği (DTLS) Protokolü Sürüm 1.3", Çalışma Aşamasında, Internet-Draft, draft-ietf-tls-dtls13-39, 2 Kasım 2020, https://tools.ietf.org/html/draft-ietf-tls-dtls13-39.

#Yazarın Adresi

Eric Rescorla Mozilla

E-posta: ekr@rtfm.com