„Проектиране на корпоративна vpn мрежа
Изтегляне 2.17 Mb.
|
| Main mode – удостоверяване с предварително споделен ключ Инициатор
Main mode – удостоверяване със сертификати Използването на предварително споделени ключове за удостоверяване налага всяка система да бъде конфигурирана с парола, която е асоциирана с IP адресите на удостоверяваните отдалечени системи. Първи обмен Първият обмен започва със съобщение от инициатора до отсрещната страна, което съдържа ISAKMP хедър и SA хедър. В SA хедъра се съдържат съответните proposal и transform payload-и, които представят на отсрещната страна опциите за сигурност. В оригиналното съобщение от инициатора е включена “бисквитка”. Второто съобщение е от отсрещната страна. То съдържа ISAKMP хедър и SA хедър, който от своя страна съдържа proposal и transform payload с параметрите, които ще се използват. Включени са “бисквитките” на отсрещната страна. На този етап двете системи са се договорили за параметрите за сигурност, които ще бъдат използвани за защита на по-нататъшната комуникация, и са обменили “бискивитки”, които намаляват възможността атакуващ да вмъкне невалидни пакети по време на преговорите в IKE. След завършване на първия обмен всяка система генерира публичните стойности на Diffie-Hellman, които се споделят с отсрещната страна. Втори обмен Следващата част от комуникацията позволява на страните да обменят публичните стойности на Diffie-Hellman и “nonce”. Nonce и “бисквитките” формират защитен слой и уверяват, че страната в комуникацията е активно участваща, а не само повтаряща прихванати по-рано съобщения или отправяща фалшиви запитвания. След завършване на втория обмен всяка система обработва стойностите на Diffie-Hellman с цел създаване на основен ключ. Всяка система създава четири ключа: 1. SKEYID, таен ключ, на който се основават всички следващи ключове. Ако обаче PFS (perfect forward secrecy- политика ) е активирана, този ключ не се използва за създаване на бъдещи ключове, а се създава нов ключ в нова Фаза 1 и Фаза 2. 2. SKEYID_d се използва като ключов материал за създаване на ключове за SA в операции във Фаза 2 (т.е. за IPSec). 3. SKEYID_a е ключът, използван за удостоверяване и интегритет на данни. 4. SKEYID_e е ключът, използван за криптиране на IKE съобщения. Ключовете, които фактически се използват при криптирането и удостоверяването, се базират на основния ключ, SKEYID. Атрибутите,които се използват за създаване на SKEYID, зависят от използвания удостоверяващ метод. За изграждане на ключове се използва псевдо-случайна функция (prf) с ключ и различни данни, които се комбинират за създаване на фиксирана стойност. Prf е заключена хеш функция, която се използва за генериране на стойности, които изглеждат случайни, но се използват за валидиране на данните. Пример за този процес е: Digest = prf (key/seed, data1 | data2 | data3) Тази секция представлява детайлизиране на предварително споделено тайно удостоверяване, при което SKEYID се определя като: SKEYID = prf (pre-shared key, Nonce_i | Nonce_r) Информацията с която разполага всяка система за другата след първия обмен е: Инициатор/ отсрещна страна (отговарящ) 1 – “Бисквитки” на инициатора 2 – “Бисквитки” на отсрещната страна (отговарящия) 3 – Предложения пакет за сигурност (ESP-DES и ESP MD5-HMAC). При удостоверяване с цифрови сертификати ключът се определя, както следва: SKEYID = prf (Nonce_i | Nonce_r, DH_key), където Nonce_i и Nonce_r са случайни стойности, а DH_key е е стойността, произлизаща от процеса Diffie-Hellman и е резултат от споделянето на публичните стойности на Diffie-Hellman. Тази стойност не е публична, а е създадена независимо от всяка страна чрез използване на публична стойност, предоставена от отсрещната страна. SKEYID_d = prf (SKEYID, DH_key | Cookie_i | Cookie_r | 0) SKEYID_a = prf (SKEYID, SKEYID_d | DH_key | Cookie_i | Cookie_r | 1) SKEYID_e = prf (SKEYID, SKEYID_a | DH_key | Cookie_i | Cookie_r | 2) Другите три ключа, създадени с използването на основния ключ SKEYID, са резултат от същия детайлизиран метод, независимо от избрания удостоверяващ метод. При завършването на втория обмен всяка система разполага с достатъчно информация, за да започне криптирането на комуникацията. Важно е да се отбележи, че ключовете, които ще бъдат използвани за криптиране и удостоверяване, са създадени единствено на базата на IP адреса на отсрещната страна. Identification Payload предоставя възможност за удостоверяване на информационния обмен, като IP адреси, маски или “fully qualified domain name” (FQDN). ID payload-ът не се споделя по време на първия и втория обмен, което означава, че IP адресът на страната остава единствен уникален идентификатор. Main Mode на Фаза 1 с предварително споделена тайна, като удостоверяващ процес, не предоставя защита и се основава изцяло на IP адреса на страната. Това е едно прието ограничение на Main Mode с предварително споделена тайна и в много случаи не представлява проблем. В случаи обаче, когато IP адресът е динамичен, отговарящият не може да поддържа предварително споделени тайни, базирани на IP адреси, които не познава. Решенията за отдалечен достъп са пример за това, че IP адресът на инициатора може да бъде различен за всяка връзка. За да отговорят на тези случаи, се използват сертификати за удостоверяване на отдалечен достъп. Повечето решения за отдалечен достъп използват главно Aggressive Mode, защото ID payload-ът се осигурява по време на първия обмен. Трети обмен Последният обмен се състои от ISAKMP хедър, ID payload и HASH payload за удостоверяване на произхода на данните. Той е криптиран с ключ SKEYID_e. HASH обединява няколко компонента, които вече са известни на страните и един, който се осигурява при петото и шестото съобщение - ID payload. Той се състои от: HASH = prf (SKEYID, Ya | Yb | Cookie_i | Cookie_r | SA offer | ID_i) При използване на сертификати в третия обмен вместо HASH се предават съответните удостоверявaщи сертификати. Изтегляне 2.17 Mb. Сподели с приятели:
|