2.4. Взаимная идентификация
Поскольку протокол EAP основан на равноправных отношениях (peer-to-peer), может возникать независимая и одновременная идентификация во встречных направлениях (в зависимости от возможностей нижележащего уровня). Обе стороны канала могут действовать, как идентифицирующие и идентифицируемые одновременно. В таких случаях обеим сторонам необходимо реализовать уровни идентифицирующей и идентифицируемой стороны EAP. Кроме того, метод EAP на обеих сторонах должен поддерживать функциональность идентифицирующего и идентифицируемого узла.
Хотя EAP поддерживает взаимную идентификацию сторон, некоторые реализации EAP, методов, протоколов AAA, и канального уровня могут не поддерживать такой режим. Некоторые методы EAP могут поддерживать асимметричную идентификацию с запросом одного типа «удостоверений» для идентифицирующей стороны и другого типа для ее партнера. Хосты, поддерживающие взаимную идентификацию с таким методом, должны быть обеспечены удостоверениями обоих типов.
Например, EAP-TLS [RFC2716] представляет собой протокол «клиент-сервер», в котором для клиента и сервера обычно используются разные профили сертификатов. Это предполагает для хоста, поддерживающего взаимную идентификацию с использованием EAP-TLS, необходимость реализовать уровни идентифицирующей и идентифицируемой стороны EAP, поддерживать роли обеих сторон в реализации EAP-TLS о обеспечивать подходящие сертификаты для каждой роли.
Протоколы AAA типа RADIUS/EAP [RFC3579] и Diameter EAP [DIAM-EAP] поддерживают только работу в режиме проходной идентифицирующей стороны. Как было отмечено в параграфе 2.6.2 [RFC3579], сервер RADIUS отвечает на Access-Request, инкапсулированный в пакет EAP-Request, Success или Failure откликом Access-Reject. Следовательно, он не поддерживает работы в режиме проходного партнера.
Даже при использовании метода, поддерживающего взаимную идентификацию сторон и индикацию результата, некоторые аспекты могут потребовать двух идентификаций EAP (по одной в каждом направлении). Эти аспекты включают:
- Поддержка двухстороннего создания ключей на нижележащем уровне. Нижележащие уровни типа IEEE 802.11 могут обеспечивать лишь одностороннюю генерацию и доставку временных сеансовых ключей. Например согласование ключа группы, определенное в [IEEE-802.11i], является односторонним, поскольку в режиме инфраструктуры IEEE 802.11 только точки доступа (AP) передают групповой и широковещательный трафик. В специальном режиме IEEE 802.11, где любой из партнеров может передавать групповой/широковещательный трафик, требуется два односторонних обмена ключами групп. В следствие присущих архитектуре ограничений это также ведет к необходимости использования индивидуальной адресации при создании ключей и обмена EAP в каждом направлении.
- Поддержка «разрубания узлов» на нижележащем уровне. Нижележащие уровни типа IEEE 802.11 ad hoc не поддерживают «разрубания узлов», когда два хоста инициируют идентификацию друг друга, что приводит в результате лишь к одной идентификации. Это приводит к тому, что даже при поддержке двухстороннего согласования групповых ключей в 802.11, могут выполняться две идентификации (по одной для направления).
- Политика партнера. Методы EAP могут поддерживать индикацию результата, позволяя партнеру показать серверу EAP в рамках метода, что он успешно идентифицировал сервер, а серверу выполнить аналогичную индикацию для пратнера. Однако идентифицирующая сторона в проходном режиме не может быть уверена, что партнер принял представленные сервером EAP удостоверения, пока эта информация не будет представлена идентифицирующей стороне по протоколу AAA. Идентифицирующей стороне следует интерпретировать получение ключа в пакете Accept, как индикацию успешной идентификации сервера ее партнером.
Однако возможно, что политика доступа партнера оказалась неподходящей в начальном обмене EAP даже при взаимной идентификации. Например, идентифицирующая сторона EAP может не показывать наличие полномочий для работы в роли идентифицирующей и идентифицируемой сторон. В результате партнер может потребовать дополнительной идентификации в обратном направлении, даже если сервер EAP успешно идентифицирован им.