IKEv1 ile IKEv2 arasında ön paylaşımlı anahtar: kimlik doğrulamada ne farklı
Her iki sürüm de ön paylaşımlı anahtarı göndermeden bilindiğini kanıtlar, ancak farklı hash'lere farklı girdiler verir. İki izi karşılaştırın.
Aynı ön paylaşımlı anahtarla yapılandırılmış iki geçit bir el sıkışmayı tamamlar ve paket kaydı kablo üzerinden geçen hiçbir sır göstermez. İnsanların hatırladığı kısım budur. İlginç olan kısım, her sürümün sırrın bilindiğini kanıtlamak için gerçekte ne hesapladığıdır, çünkü IKEv1 ve IKEv2 bu kanıtı farklı girdilerden kurar ve bunu yaparken farklı bilgileri açığa çıkarır. İki izi yan yana okuyun, fark artık kozmetik olmaktan çıkar.
Kanıtın başarması gereken şey
Diffie-Hellman her iki tarafa, açık yarılarını izleyen herkesin de hesaplayabildiği ortak bir değer verir. Tek başına bu, kimlik hakkında hiçbir şey kanıtlamaz: bir anahtar değişimini tamamlayan saldırgan, geçidinizle aynı ortak değere sahiptir. Kimlik doğrulama adımı, o değişimi yalnızca amaçlanan tarafların bildiği bir sırra ve üzerinde anlaştıkları kimliklere ve parametrelere bağlamak için vardır.
Hash'in anahtardan fazlasını kapsamasının nedeni bu bağlamadır. Yalnızca sırrı kapsasaydı, bir saldırgan onu farklı kimlikler veya önerilerle başka bir değişime yeniden oynatabilirdi.
IKEv1 Main Mode: SKEYID türet, sonra kanıtla
Main Mode altı mesaj çalıştırır. İlk çift güvenlik ilişkisini müzakere eder, ikincisi Diffie-Hellman açık değerlerini ve nonce'ları değiş tokuş eder, üçüncüsü ise yeni kurulan şifreleme altında kimlikleri ve kimlik doğrulama hash'lerini taşır. RFC 2409 yapıyı tanımlar: ön paylaşımlı anahtar doğrulamasında SKEYID sırdan ve her iki nonce'dan, sonraki anahtar malzemesi ise SKEYID'den, Diffie-Hellman ortak değerinden, çerezlerden ve sabitlerden türetilir.
Beşinci ve altıncı mesajlardaki hash, Diffie-Hellman değeri, iki çerez, öneri ve gönderenin kimliği üzerinden SKEYID anahtarıyla hesaplanır. Alıcı bunu kendi yapılandırdığı sırla yeniden hesaplar. Uyuşmazlık değişimi bitirir ve sır hiçbir aşamada yükün kendisi değildir.
Aggressive Mode aynı işi üç mesaja sıkıştırır; bu, şifreli bir kanal var olmadan önce kimliklerin ve kimlik doğrulama hash'inin yola çıktığı anlamına gelir. Bu, tahmin edilebilir bir sır için gerçek bir maruziyettir ve sırrın iletilip iletilmediği sorusundan ayrıdır. IKEv1, RFC 9395 ile kullanımdan kaldırılmıştır, dolayısıyla eski bir iz bir dağıtım hedefi değil, tanılama alıştırmasıdır.
IKEv2: farklı bir türetme ve farklı bir AUTH yükü
IKEv2, IKEv1 anahtar çizelgesini yeniden kullanmaz. İlk IKE anahtarları nonce'lardan ve Diffie-Hellman ortak değerinden kurulan bir tohumdan gelir ve alt güvenlik ilişkileri bundan türetilir. Ön paylaşımlı anahtar tohuma hiç girmez.
Kimlik doğrulama sonra bir AUTH yükü olarak görünür. Paylaşımlı anahtar doğrulaması için RFC 7296, sırrın dolgulu bir biçimini tanımlar; bu, sırrın sabit diziyle hash'lenmesiyle elde edilir Key Pad for IKEv2, ardından imzalanmış değişim verilerinin ve kimliğin bu dolgulu anahtarla hash'lenmesi gelir. Doğrulayıcı aynı değeri yeniden kurabilir; bir gözlemci sır olmadan kuramaz.
Neyin değiştiğine dikkat edin. IKEv1'de sır, kimlik doğrulama hash'i var olmadan önce anahtar çizelgesine işlenmiştir; IKEv2'de anahtar çizelgesi sırdan bağımsızdır ve kanıt, imzalanmış oktetlere bağlı ayrı bir yüktür. Aynı kavramsal güvence, farklı makine, ve parametre adlarıyla kayıtların bire bir eşleşmemesinin nedeni budur.
Bir gözlemci gerçekte ne öğrenir
Diffie-Hellman açık değerleri, öneriler, nonce'lar ve çerezler her iki sürümde görünür. Kimlikler IKEv1 Aggressive Mode'da görünür, diğer durumlarda korunur. Sır hiçbir zaman görünmez.
Son cümlenin söylenmeye değer bir sınırı var. Zayıf, insan tarafından seçilmiş bir sır tahminle saldırıya uğrayabilir: saldırgan aday bir sır için kimlik doğrulama değerinin ne olacağını hesaplar ve karşılaştırır. IKEv1 Aggressive Mode bunu en ucuz hale getirir çünkü kanıt açıktadır ve standartlar genel olarak düşük entropili sırlar konusunda uyarır. Sırrı hiç iletmemek, kötü bir sırrı güvenli hale getirmekle aynı şey değildir.
Bu karşılaştırmayla ne yapmalı
Her eş çifti için tek ve benzersiz bir sır kullanın, onu rastgele bir kaynaktan üretin ve onu dağıtan aynı hazırlama yolundan döndürün. Sır her şubeye gönderilen bir yapılandırma şablonunda saklanıyorsa, tek bir yerdeki ihlal her yerde ihlaldir.
İşletme maliyeti kabul edilebilir olduğunda sertifika tabanlı kimlik doğrulamayı tercih edin, çünkü paylaşılan sır tahmini sorununu ortadan kaldırır ve her eşe ayrı bir kimlik verir. Ön paylaşımlı anahtar kalıyorsa onu uzun tutun, kapsamını daraltın ve IKE sürümünü bir birlikte çalışabilirlik ayrıntısı değil, güvenlik kararı olarak görün.