Ağ Postası İçin İmza Doğrulama Sorunu Üzerine

Network Working Group
Request for Comments: 644
Bob Thomas
BBN-TENEX
Temmuz 1974

Bu not, ağ postası için imza doğrulama sorununu açıklar, soruna genel bir yaklaşım sunar ve bu yaklaşımın belirli bir uygulamasını önerir.

1. Sorun

Ele almak istediğimiz sorun şudur:

Bir ağ postası iletisinin alıcısı, imzanın (örneğin "FROM" alanındaki adın) özgün olduğundan; yani iletinin gerçekten iddia ettiği kişiden geldiğinden nasıl "emin" olabilir?

Ağ bağlamında imza özgünlüğü sorunuyla ilgileniyoruz. Bu notun amacı doğrultusunda, yerel posta için imza doğrulama sorununa yönelik bir çözümün var olduğunu varsayacağız (yani tek bir ana makine içindeki bir kullanıcıdan diğerine gönderilen iletiler). Başka bir deyişle, herhangi bir ana makine için şu varsayımı yapıyoruz: ya ana makine bu sorunu önemli görür ve yerel postadaki imzaları güvence altına alan bir mekanizmaya sahiptir ya da bu sorunu önemli görmez ve imza doğrulamasını güvence altına almaz. Bu varsayımın ağ imza sorunu yaklaşımımızla nasıl ilişkili olduğu açık hâle gelecektir.

Yaklaşımımızı, ağ postası için aşağıdaki basit modeli kullanarak tartışacağız:

Bir kullanıcı ağ postası göndermek için yerel ana makinesinde (SH) bir posta gönderme sürecini (SP) çalıştırır. SP süreci, kullanıcı adına hareket ederek iletiyi alıcı ana makinedeki (RH) uygun bir posta kutusuna teslim eder. Bunu, RH ana makinesinde çalışan bir alıcı süreç (RP) ile etkileşime girerek yapar. RP, iletiyi SP'den kabul eder ve uygun posta kutusuna yerleştirir.

Ağ postasının mevcut uygulamasında, alıcı süreç RP genellikle bir FTP sunucu sürecidir. Mevcut TENEX uygulamasında posta gönderme süreci SP, ya SNDMSG çalıştıran bir süreçtir ya da "background" MAILER sürecidir; bu süreç "queued" (önceden gönderilmek üzere bırakılmış ancak teslim edilmemiş) postaları gönderir.

2. Bir Yaklaşım

RP'nin, yani alıcı sürecin, aldığı iletilerdeki imzayı gönderici ana makine SH açısından doğrulanmış veya doğrulanmamış olarak işaretleyebilmesine olanak tanıyan bir çözüm arıyoruz. Eğer RP gelen iletileri bu şekilde işaretleyebilirse, RH üzerinde postasını okuyan bir kullanıcı her iletinin imzasını kaynak ana makine açısından doğrulanmış veya doğrulanmamış olarak görebilir. Bir posta parçası üzerindeki imzanın özgünlüğü, gönderen ana makinenin sorumluluğu olarak kabul edilir. Bir kullanıcının özgün olarak işaretlenmiş belirli bir iletiye verdiği güvenilirlik derecesi, kullanıcının kaynak ana makinenin kullanıcı doğrulama ve erişim kontrol mekanizmalarına ilişkin kendi değerlendirmesine dayanabilir.

Bu yaklaşımın başarısı iki şeye bağlıdır:

• a. Kullanıcılar, çeşitli ana makinelerin kullanıcı doğrulama ve erişim kontrol mekanizmalarının güvenliği hakkında değerlendirmeler geliştirir. Veri gizliliği ve güvenliği konusunda kaygı duyan kullanıcıların ARPANET içinde bunu zaten yapmakta olduklarını gördük.

• b. Alıcı süreç RP'nin, gönderici ana makine açısından doğrulanmış posta ile gönderici ana makine tarafından doğrulanmamış posta arasında ayrım yapabilmesini sağlayan bir mekanizmanın varlığı. Yani, uygun şekilde yetkilendirilmiş (gönderen ana makine tarafından) bir posta gönderme sürecinin, posta alma sürecine kendisini bu şekilde tanıtmasına olanak verecek bir mekanizma gereklidir. Alıcı süreç daha sonra böyle doğrulanmış bir süreçten gelen postayı özgün olarak işaretleyebilir. Yetkisiz süreçler (örneğin yetkili bir posta gönderme süreci gibi davranmaya çalışan bir kullanıcı süreci) RH üzerindeki posta kutularına posta göndermeye çalışabilir; böyle bir durumda alıcı süreç iletileri kabul etmeyi reddetme ya da kabul edip doğrulanmamış olarak işaretleme seçeneğine sahiptir.

3. Yaklaşımın Önerilen Uygulaması

Parolaların kullanımı, gönderme süreci doğrulamasını sağlamak için olası bir yöntemdir. Yalnızca yetkili bir gönderme süreci parolayı bilecek ve böylece kendisini posta alma sürecine doğru biçimde tanıtabilecektir.

Aşağıdaki nedenlerle parola mekanizmasını operasyonel açıdan pratik olmadığı için reddediyoruz:

• a. Bir parolanın kullanılması, parolanın gönderme programı içinde saklanmasını veya ona bir şekilde erişilebilir olmasını gerektirir; bu da böyle bir parolanın gizliliğinin tehlikeye girmesi olasılığını artırır.

• b. Bir parola ele geçirilirse, hem gönderici hem de alıcı ana makinelerde değiştirilmesi gerekir; bu da bir eşzamanlama sorunu doğurur.

• c. Gerçekten güvenli posta muhtemelen her ana makine çifti için parolalar gerektirir; bu da N ana makineli bir ağ için N × N parola anlamına gelir.

Süreç doğrulaması için parola kullanımına alternatif olarak, doğrulamanın gönderme ve alma süreçleri arasındaki iletişim yolu üzerine kurulmasını öneriyoruz.

ARPANET'te bir iletişim yolu, iki ucu tarafından benzersiz biçimde tanımlanır: gönderici ana makine–socket çifti ve alıcı ana makine–socket çifti. Bir süreç, iletişim yolunun uzak ucundaki ana makine–socket çiftini doğru şekilde belirleyebilir. Alıcı sürecin, gönderme sürecini yalnızca iletişim yolunun gönderici ucu doğrulanmış posta iletimi için ayrılmış socket(lerden) biri ise uygun biçimde yetkilendirilmiş (gönderen ana makine tarafından) bir posta göndericisi olarak kabul etmesini öneriyoruz. Posta gönderme socket(leri) önceden yapılan ana makine anlaşmalarıyla ayrılacaktır.

Gönderen ana makinenin sorumluluğu, yalnızca yetkili posta gönderme süreçlerinin posta gönderme socket(lerine) erişmesine izin vermektir. Postasının özgünlüğü konusunda kaygı duyan kullanıcının sorumluluğu ise, özgün olarak işaretlenmiş postanın gönderen ana makinenin göndericinin kimliğini belirlediği anlamına geldiğini ve böyle bir postadaki imzanın güvenilirliğinin yalnızca gönderen ana makinenin kullanıcı doğrulama ve erişim kontrol prosedürleri kadar iyi veya kötü olduğunu anlamaktır.

4. Ek Açıklamalar

• a. Süreç doğrulaması için socket kullanımının ARPANET içinde yeni bir kavram olmadığı belirtilmelidir. Ana makineler arasındaki anlaşmayla TELNET logger süreci socket #1'e yapılan bağlantılara, FTP logger süreci socket #3'e yapılan bağlantılara yanıt verir vb. Aslında ağ postasının gizliliği, ana makinenin FTP logger socket'ine erişimi ne kadar iyi kontrol ettiğine bağlıdır; yani posta alma sürecinin özgünlüğü, socket #3'e ICP yapılarak ulaşılan süreç olmasına dayanır. Bu not, posta gönderme süreçlerinin doğrulanmasını sağlamak için aynı mekanizmanın kullanılmasını önermektedir.

• b. Planlanan TENEX Deneyi

  Posta iletimi için bir socket kümesi tahsis edilmiştir. Bunlar (tüm sayılar ondalıktır):

  • ICP "from" socket – 232
  • FTP kullanıcı komut socket'leri: alma, gönderme = 234, 235
  • Varsayılan veri aktarımı (user, send) socket = 237

  TENEX posta gönderme, alma ve okuma yazılımlarını yukarıda önerildiği şekilde değiştirmeyi planlıyoruz. TENEX'ten uzak ana makinelere gönderilen ve özgün olan (TENEX açısından) posta, ICP'nin uzak FTP sunucu socket'i 232'ye başlatılmasıyla gönderilecektir. Uzak ana makinelerden alınan posta ise yalnızca TENEX FTP sunucusuna yapılan ICP uzak socket 232'den başlatılmışsa özgün olarak işaretlenecektir. TENEX posta okuma yazılımı, her ileti için iletideki imzanın kaynak doğrulamasından geçip geçmediğini gösterecektir.

• c. Posta Gönderme Socket'i İçin Rekabet

  Gönderen ana makinenin NCP'sinin ve posta ağ gönderme yazılımının uygulanışına bağlı olarak, aynı anda ağ postası gönderen birkaç kullanıcının tek bir ICP "from" socket'i için rekabet etmesi söz konusu olabilir. Eğer socket rekabeti uygulamada ciddi bir sorun hâline gelirse, doğrulanmış ağ postası için bir ICP "from" socket kümesi ayrılabilir.

• d. Yerel posta imza doğrulama sorunu, burada tartıştığımız ağ postası imza doğrulama sorunundan neredeyse bağımsızdır. Örneğin aşağıdaki gözlemler yapılabilir:

  1. Yerel postayı doğrulamayan bir ana makinenin yerel kullanıcıları, ana makinenin kendilerine doğrulanmış ağ postasını güvenilir biçimde teslim etmesini muhtemelen beklememelidir. Çünkü yerel posta doğrulanmadığından, kötü niyetli bir yerel kullanıcı diğer kullanıcıların posta kutularına ağ postasıyla tamamen aynı biçimde düzenlenmiş ve ana makinenin posta alma sürecinin postayı işaretlediği şekilde özgün olarak işaretlenmiş sahte iletiler ekleyebilir.

  2. Güçlü kullanıcı doğrulama prosedürlerine sahip olan ve yerel postayı doğrulayan bir ana makine, mutlaka doğrulanmış ağ postasının güvenilir bir kaynağı değildir. Güvenilir bir kaynak olabilmesi için, ağ postası iletim socket(lerine) erişimi yetkili posta gönderme süreçleriyle sınırlaması gerekir.

  3. Yerel doğrulanmış postayı desteklemeyen bir ana makine, yine de özgün ağ postasının güvenilir bir kaynağı olabilir.