2.16. Методы EAP
В дополнение к идентификаци на основе подписей с открытыми ключами и разделяемыми секретами IKE поддерживает идентификацию с использованием методов, определенных в RFC 3748, Расширяемый протокол идентификации [EAP]. Обычно эти методы являются асимметричными (они разработаны для идентификации пользователей на сервере) и могут не быть обоюдными. По это причине упомянутые протоколы обычно используются для идентификации инициатора на отвечающей стороне и должны применяться в комбинации с идентификацией ответчика инициатору по цифровой подписи на основе открытого ключа. Эти методы часто ассоциируются с механизмами, которые называют «унаследованной идентификацией» (Legacy Authentication).
Хотя в этом документе [EAP] упоминается, прежде всего, в плане добавления в будущем новых методов без обновления данной спецификации, некоторые простые варианты описаны здесь и в параграфе 3.16. [EAP] определяет протокол идентификации с переменным числом сообщений. Расширяемая идентификация реализуется в IKE, как дополнительные обмены IKE_AUTH, которые должны быть выполнены для инициализации IKE_SA.
Инициатор показывает свое намерение использовать расширяемую идентификацию, пропуская элемент AUTH в сообщении 3. За счет включения элемента Idi при отсутствии AUTH инициатор объявляет свою идентификацию, но доказывает ее. Если ответчик желает использовать расширяемую идентификауцию, он будет включать элемент EAP в сообщение 4 и откладывает передачу SAr2, TSi и Tsr, пока идентификаци инициатора не будет завершена в последующем обмене IKE_AUTH. В варианте минимально расширяемой идентификации организация начальной SA будет иметь вид:
Инициатор Ответчик
----------- ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
Для методов EAP, которые создают разделяемый ключ в качестве побочного продкта идентификации, этот ключ должен использоваться инициатором и ответчиком для генерации элементов данных AUTH в сообщениях 7 и 8 с использованием синтаксиса для разделяемых секретов, описанного в параграфе 2.15. Разделяемый ключ от EAP в спецификации EAP называется полем MSK. Разделяемый ключ, созданный в процессе обмена IKE, недопустимо использовать для иных целей.
Методы EAP, не создающие разделяемого ключа, использовать не следует, поскольку они подвержены многочисленным атакам MITM [EAPMITM] при использовании в других протоколах, не применяющих идентифицированные сервером туннели. Если используются методы EAP, не генерирующие разделяемого ключа, элементы данных AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.
Инициатору IKE_SA с использованием EAP следует поддерживать возможность расширения начального протокольного обмена по крайней мере до десяти обменов IKE_AUTH, если ответчик передает уведомления и/или провторяет приглашение к идентификации. После успешного завершения протокольного обмена, определенного выбранным методом идентификации EAP ответчик должен передать данные EAP, содержащие сообщение Success. Если при использовании выбранного метода идентификации возник отказ, ответчик должен передать данные EAP, содержащие сообщение Failure. Ответчик может в любой момент прервать обмен IKE путем передачи данных EAP с сообщением Failure.
При таком расширенном обмене элементы данных EAP AUTH должны включаться в два сообщения, следующие за собщением, содержащим EAP Success.