Введение
Протокол аутентификации для протокола "точка-точка" (Extensible Authentication Protocol, EAP) — это структура аутентификации, часто используемая в сетевых и интернет-соединениях. Он определён в , который стал устаревшим, и обновляется . EAP представляет собой структуру аутентификации, обеспечивающую передачу и использование данных и параметров, генерируемых методами EAP. Существует множество методов, определённых в RFC, а также ряд фирменных методов и новых предложений. EAP не является сетевым протоколом; вместо этого он определяет только информацию интерфейса и форматы данных. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP, генерируемых пользователем, в сообщения этого протокола. EAP широко применяется. Например, в IEEE 802.11 (Wi-Fi) стандарты WPA и WPA2 приняли IEEE 802.1X (с различными типами EAP) в качестве стандартного механизма аутентификации.
Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in , which made obsolete, and is updated by EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages. EAP is in wide use. For example, in IEEE 802.11 (Wi Fi) the WPA and WPA2 standards have adopted IEEE 802.1X (with various EAP types) as the canonical authentication mechanism.
Методы
EAP – это фреймворк аутентификации, а не конкретный механизм аутентификации. Он предоставляет общие функции и согласование методов аутентификации, называемых методами EAP. В настоящее время определено около 40 различных методов. Методы, определенные в RFC IETF, включают EAP MD5, EAP POTP, EAP GTC, EAP TLS, EAP IKEv2, EAP SIM, EAP AKA и EAP AKA'. Кроме того, существует ряд методов, специфичных для производителей, и новых предложений. К наиболее часто используемым современным методам, способным работать в беспроводных сетях, относятся EAP TLS, EAP SIM, EAP AKA, LEAP и EAP TTLS. Требования к методам EAP, используемым для аутентификации в беспроводных локальных сетях, описаны в [здесь]. Список типов и кодов пакетов, используемых в EAP, доступен в реестре EAP IANA. Стандарт также описывает условия, при которых могут быть выполнены требования к управлению ключами AAA, описанные в [здесь].
Легкий расширяемый протокол аутентификации (LEAP)
Легкий расширяемый протокол аутентификации (LEAP) был разработан компанией Cisco Systems до ратификации IEEE стандарта безопасности 802.11i. Cisco распространяла этот протокол посредством CCX (Cisco Certified Extensions) с целью стимулирования внедрения 802.1X и динамического WEP в отрасли в отсутствие единого стандарта. Встроенной поддержки LEAP в операционных системах Windows нет, однако он широко поддерживается сторонним клиентским программным обеспечением, которое обычно поставляется вместе с устройствами WLAN (беспроводной локальной сети). Поддержку LEAP для Microsoft Windows 7 и Microsoft Windows Vista можно добавить, загрузив клиентский модуль от Cisco, обеспечивающий поддержку как LEAP, так и EAP FAST. В связи с широким распространением LEAP в сетевой индустрии многие другие производители WLAN заявляют о его поддержке. LEAP использует модифицированную версию MS CHAP – протокола аутентификации, в котором учетные данные пользователей недостаточно защищены и легко могут быть скомпрометированы. В начале 2004 года Джошуа Райт опубликовал инструмент для эксплуатации этой уязвимости под названием ASLEAP. Cisco рекомендует клиентам, которым необходимо использовать LEAP, применять только достаточно сложные пароли, хотя администрирование и обеспечение соблюдения таких паролей может быть затруднительным. В настоящее время Cisco рекомендует использовать более современные и надежные протоколы EAP, такие как EAP FAST, PEAP или EAP TLS.
EAP Transport Layer Security (EAP-TLS) - безопасность транспортного слоя EAP
EAP Transport Layer Security (EAP TLS), определенный в , является открытым стандартом IETF, использующим протокол Transport Layer Security (TLS) и широко поддерживаемым производителями беспроводного оборудования. EAP TLS – это оригинальный стандартный протокол аутентификации EAP для беспроводных локальных сетей. EAP TLS по-прежнему считается одним из наиболее безопасных стандартов EAP, хотя TLS обеспечивает надежную защиту только при условии, что пользователь понимает потенциальные предупреждения о недостоверных учетных данных, и поддерживается всеми производителями аппаратного и программного обеспечения для беспроводных локальных сетей. До апреля 2005 года EAP TLS был единственным типом EAP, сертификация которого требовалась для получения логотипа WPA или WPA2. Клиентские и серверные реализации EAP TLS доступны для 3Com, Apple, Avaya, Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft и операционных систем с открытым исходным кодом. EAP TLS поддерживается в Mac OS X 10.3 и более поздних версиях, wpa supplicant, Windows 2000 SP4, Windows XP и более поздних версиях, Windows Mobile 2003 и более поздних версиях, Windows CE 4.2 и мобильной операционной системе Apple iOS. В отличие от большинства TLS-реализаций HTTPS, используемых, например, в World Wide Web, большинство реализаций EAP TLS требуют взаимной аутентификации с использованием клиентских сертификатов X.509, не предоставляя возможности отключить это требование, хотя стандарт не предписывает их обязательное использование. 22 августа 2012 года hostapd (и wpa supplicant) добавили поддержку в свой репозиторий Git для EAP-типа UNAUTH TLS, специфичного для поставщика (используя номер Private Enterprise Number проекта hostapd/wpa supplicant), а 25 февраля 2014 года – поддержку EAP-типа WFA UNAUTH TLS, специфичного для поставщика (используя номер Wi-Fi Alliance Private Enterprise Number), который выполняет только аутентификацию сервера. Это позволяет создавать сценарии, аналогичные HTTPS, когда беспроводная точка доступа предоставляет свободный доступ и не аутентифицирует клиентские станции, но клиентские станции хотят использовать шифрование (IEEE 802.11i 2004, то есть WPA2) и, возможно, аутентифицировать беспроводную точку доступа. Также были предложения использовать IEEE 802.11u для точек доступа, чтобы сигнализировать о поддержке EAP TLS с использованием только аутентификации на стороне сервера, применяя стандартный тип EAP TLS IETF вместо типа EAP, специфичного для поставщика. Требование клиентского сертификата, несмотря на его непопулярность, обеспечивает надежность аутентификации EAP TLS и иллюстрирует классический компромисс между удобством и безопасностью. При использовании клиентского сертификата скомпрометированного пароля недостаточно для взлома систем, использующих EAP TLS, поскольку злоумышленнику все равно потребуется этот сертификат; более того, пароль даже не нужен, так как он используется только для шифрования клиентского сертификата при хранении. Максимальная безопасность достигается при хранении "приватных ключей" клиентского сертификата на смарт-картах, поскольку украсть соответствующий приватный ключ с смарт-карты без кражи самой карты невозможно. Вероятность обнаружения физической кражи смарт-карты (и ее немедленной блокировки) выше, чем вероятность обнаружения (типичной) кражи пароля. Кроме того, приватный ключ на смарт-карте обычно зашифрован с помощью PIN-кода, известного только владельцу смарт-карты, что минимизирует его полезность для злоумышленника даже до сообщения об утере или краже карты.
EAP-MD5
EAP MD5 был единственным методом EAP, разработанным в рамках IETF Standards Track, когда он впервые был определен в оригинальном RFC для EAP. Он обеспечивает минимальный уровень безопасности: хеш-функция MD5 уязвима к атакам по словарю и не поддерживает генерацию ключей, что делает его непригодным для использования с динамическим WEP или WPA/WPA2 в корпоративной среде. EAP MD5 отличается от других методов EAP тем, что он обеспечивает только аутентификацию клиента EAP на сервере EAP, но не взаимную аутентификацию. Отсутствие аутентификации сервера EAP делает этот метод уязвимым для атак типа "человек посередине". Поддержка EAP MD5 была впервые реализована в Windows 2000 и прекращена в Windows Vista.
EAP-POTP (EAP-Protected One-Time Password) - защищенный одноразовый пароль
EAP Protected One Time Password (EAP POTP), описанный в , является методом EAP, разработанным RSA Laboratories, который использует токены одноразового пароля (OTP), такие как портативное аппаратное устройство или аппаратный или программный модуль, работающий на персональном компьютере, для генерации ключей аутентификации. EAP POTP может использоваться для обеспечения односторонней или взаимной аутентификации и ключевого материала в протоколах, использующих EAP. Метод EAP POTP обеспечивает двухфакторную аутентификацию пользователя, то есть для аутентификации пользователю требуется как физический доступ к токену, так и знание личного идентификационного номера (PIN).
Предварительно общий ключ EAP (EAP-PSK)
и RADIUS-серверов Radiator, а также реализовано в hostapd и клиенте WPA.
EAP Tunnelled Transport Layer Security (EAP-TTLS) - безопасность транспортного уровня туннельного прохода EAP
EAP Tunneled Transport Layer Security (EAP TTLS) – это протокол EAP, расширяющий TLS. Он был разработан совместно компаниями Funk Software и Certicom и широко поддерживается на различных платформах. Microsoft не включила встроенную поддержку протокола EAP TTLS в Windows XP, Vista или 7. Для поддержки TTLS на этих платформах требуется стороннее программное обеспечение, сертифицированное протоколом управления шифрованием (ECP). Поддержка EAP TTLS в Microsoft Windows началась с Windows 8, а в Windows Phone она появилась в версии 8.1. Клиент может, но не обязан, аутентифицироваться на сервере с помощью PKI-сертификата, подписанного центром сертификации (CA). Это значительно упрощает процедуру настройки, поскольку сертификат не требуется для каждого клиента. После безопасной аутентификации сервера перед клиентом через его CA-сертификат и, опционально, клиента перед сервером, сервер может использовать установленное защищенное соединение ("туннель") для аутентификации клиента. Он может использовать существующий и широко распространенный протокол аутентификации и инфраструктуру, включая устаревшие механизмы паролей и базы данных аутентификации, при этом защищенный туннель обеспечивает защиту от перехвата данных и атак типа "человек посередине". Важно отметить, что имя пользователя никогда не передается в незашифрованном виде, что повышает конфиденциальность. Существуют две различные версии EAP TTLS: оригинальный EAP TTLS (также известный как EAP TTLSv0) и EAP TTLSv1. EAP TTLSv0 описан в , а EAP TTLSv1 доступен в виде интернет-черновика.
Обмен интернет-ключами EAP v. 2 (EAP-IKEv2)
EAP Internet Key Exchange v. 2 (EAP IKEv2) — это метод EAP, основанный на протоколе Internet Key Exchange версии 2 (IKEv2). Он обеспечивает взаимную аутентификацию и установление ключа сеанса между EAP-клиентом и EAP-сервером. Он поддерживает методы аутентификации, основанные на следующих типах учетных данных:
Asymmetric key pairs Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party. Passwords Low entropy bit strings that are known to both the server and the peer. Symmetric keys High entropy bit strings that are known to both the server and the peer. It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key. EAP IKEv2 is described in , and a prototype implementation exists.
Асимметричные пары ключей: пары открытого и закрытого ключей, где открытый ключ встроен в цифровой сертификат, а соответствующий закрытый ключ известен только одной стороне.
Asymmetric key pairs Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party. Passwords Low entropy bit strings that are known to both the server and the peer. Symmetric keys High entropy bit strings that are known to both the server and the peer. It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key. EAP IKEv2 is described in , and a prototype implementation exists.
Пароли: низкоэнтропийные битовые строки, известные как серверу, так и клиенту.
Asymmetric key pairs Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party. Passwords Low entropy bit strings that are known to both the server and the peer. Symmetric keys High entropy bit strings that are known to both the server and the peer. It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key. EAP IKEv2 is described in , and a prototype implementation exists.
Симметричные ключи: высокоэнтропийные битовые строки, известные как серверу, так и клиенту.
Asymmetric key pairs Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party. Passwords Low entropy bit strings that are known to both the server and the peer. Symmetric keys High entropy bit strings that are known to both the server and the peer. It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key. EAP IKEv2 is described in , and a prototype implementation exists.
Возможно использование различных учетных данных (и, следовательно, различных методов) в каждом направлении. Например, EAP-сервер может аутентифицироваться с помощью асимметричной пары ключей, а EAP-клиент — с помощью симметричного ключа. Однако на практике не ожидается использование всех девяти теоретических комбинаций. В частности, стандарт определяет четыре варианта использования: сервер аутентифицируется с помощью асимметричной пары ключей, а клиент использует любой из трех методов; и обе стороны используют симметричный ключ. EAP IKEv2 описан в , и существует прототип реализации.
Asymmetric key pairs Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party. Passwords Low entropy bit strings that are known to both the server and the peer. Symmetric keys High entropy bit strings that are known to both the server and the peer. It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key. EAP IKEv2 is described in , and a prototype implementation exists.
Протокол расширяемой аутентификации туннеля (TEAP)
Tunnel Extensible Authentication Protocol (TEAP) — это EAP-метод, основанный на использовании туннеля, который обеспечивает безопасную связь между клиентом и сервером посредством протокола Transport Layer Security (TLS) для установления взаимно аутентифицированного туннеля. Внутри туннеля для передачи данных, связанных с аутентификацией, между EAP-клиентом и EAP-сервером используются объекты TLV (Type Length Value). Помимо аутентификации клиента, TEAP позволяет клиенту запрашивать у сервера сертификат, отправляя запрос в формате PKCS#10. После получения запроса на сертификат и аутентификации клиента, сервер может предоставить клиенту сертификат в формате PKCS#7. Сервер также может распространять доверенные корневые сертификаты клиенту в формате PKCS#7. Обе операции заключаются в соответствующие TLV и выполняются безопасно внутри уже установленного TLS-туннеля.
Модуль идентификации абонента EAP (EAP-SIM)
Модуль идентификации абонента EAP (EAP SIM) используется для аутентификации и распределения ключей сеанса с использованием модуля идентификации абонента (SIM) в системе глобальной мобильной связи (GSM). В сотовых сетях GSM для аутентификации пользователей используется SIM-карта. EAP SIM использует алгоритм аутентификации SIM между клиентом и сервером аутентификации, авторизации и учёта (AAA), обеспечивая взаимную аутентификацию клиента и сети. В EAP SIM взаимодействие между SIM-картой и центром аутентификации (AuC) устраняет необходимость в предварительно установленном пароле между клиентом и сервером AAA. Алгоритмы A3/A8 выполняются несколько раз с использованием различных 128-битных вызовов, что позволяет получить больше 64-битных значений Kc, которые объединяются и перемешиваются для создания более надёжных ключей (значения Kc не используются напрямую). Проблема отсутствия взаимной аутентификации в GSM также решена. EAP SIM описан в .
Соглашение об аутентификации и ключе EAP (EAP-AKA)
Метод расширяемого протокола аутентификации для аутентификации и согласования ключей в системе универсальной мобильной связи (UMTS) (EAP AKA) — это механизм EAP для аутентификации и распределения ключей сеанса с использованием модуля идентификации абонента UMTS (USIM). EAP AKA определен в .
Аутентификация EAP и соглашение ключа prime (EAP-AKA)
Вариант EAP AKA', определенный в , используется для не-3GPP доступа к базовой сети 3GPP. Например, через EVDO, WiFi или WiMax.
Общая токенная карта EAP (EAP-GTC)
EAP Generic Token Card, или EAP GTC, — это метод EAP, разработанный компанией Cisco как альтернатива PEAPv0/EAP MSCHAPv2 и описанный в RFC 4746. EAP GTC передает текстовый запрос от сервера аутентификации и ответ, сгенерированный токеном безопасности. Механизм аутентификации PEAP GTC обеспечивает универсальную аутентификацию к различным базам данных, таким как Novell Directory Service (NDS) и Lightweight Directory Access Protocol (LDAP), а также поддержку одноразовых паролей.
Обмен зашифрованным ключом EAP (EAP-EKE)
EAP с зашифрованным обменом ключами, или EAP EKE, – один из немногих методов EAP, обеспечивающих безопасную взаимную аутентификацию с использованием коротких паролей и не требующих сертификатов открытого ключа. Он представляет собой трехэтапный обмен, основанный на варианте алгоритма Диффи — Хеллмана известного протокола EKE. Спецификация EAP EKE приведена в .
Nimble аутентификация вне полосы для EAP (EAP-NOOB)
Гибкая аутентификация по стороннему каналу для EAP (EAP NOOB) – это универсальное решение для начальной настройки устройств, не имеющих предварительно настроенных учетных данных для аутентификации и еще не зарегистрированных ни на одном сервере. Оно особенно полезно для устройств и игрушек Интернета вещей (IoT), которые не содержат информации о владельце, сети или сервере. Аутентификация для этого метода EAP основана на канале OOB (out of band) с участием пользователя между сервером и устройством-партнером. EAP NOOB поддерживает различные типы OOB-каналов, такие как QR-коды, NFC-метки, аудио и т.д., и, в отличие от других методов EAP, безопасность протокола была подтверждена формальным моделированием спецификации с использованием инструментов ProVerif и MCRL2. EAP NOOB выполняет эфемерный обмен ключами Диффи-Хеллмана на эллиптических кривых (ECDHE) по каналу EAP. Затем пользователь подтверждает этот обмен, передав OOB-сообщение. Пользователи могут передавать OOB-сообщение от устройства-партнера к серверу, например, когда устройство является смарт-телевизором, способным отображать QR-код. Альтернативно, пользователи могут передавать OOB-сообщение с сервера на устройство-партнер, например, когда загружаемое устройство является камерой, которая может только считывать QR-код.
Инкапсулирование
EAP не является сетевым протоколом; он лишь определяет форматы сообщений. Каждый протокол, использующий EAP, определяет способ заключения сообщений EAP в свои собственные сообщения.
IEEE 802.1X
Инкапсуляция EAP через IEEE 802 определена в IEEE 802.1X и известна как "EAP over LAN" или EAPOL. EAPOL был первоначально разработан для IEEE 802.3 Ethernet в стандарте 802.1X 2001 года, но был уточнен для поддержки других технологий IEEE 802 LAN, таких как беспроводная сеть IEEE 802.11 и интерфейс распределенных данных по оптоволокну (Fiber Distributed Data Interface, ANSI X3T9.5/X3T12, принятый как ISO 9314) в стандарте 802.1X 2004 года. Протокол EAPOL также был модифицирован для использования с IEEE 802.1AE (MACsec) и IEEE 802.1AR (Initial Device Identity, IDevID) в стандарте 802.1X 2010 года. Когда EAP инициируется устройством сервера сетевого доступа (NAS) с поддержкой 802.1X, например точкой беспроводного доступа (WAP) IEEE 802.11i 2004 года, современные методы EAP могут обеспечить безопасный механизм аутентификации и согласовать защищенный парный ключ (Pairwise Master Key, PMK) между клиентом и NAS, который затем может быть использован для сеанса беспроводного шифрования с использованием шифрования TKIP или CCMP (на основе AES).
ПЭАП
Протокол защищенной расширяемой аутентификации, также известный как Protected EAP или просто PEAP, — это протокол, который инкапсулирует EAP в потенциально зашифрованный и аутентифицированный туннель безопасности транспортного уровня (TLS). Он был разработан для устранения недостатков EAP, который предполагал использование защищенного канала связи, например, обеспечиваемого физической безопасностью, и поэтому не предусматривал средств защиты обмена данными EAP. PEAP был разработан совместно компаниями Cisco Systems, Microsoft и RSA Security. PEAPv0 был версией, включенной в Microsoft Windows XP, и номинально определен в черновике kamath pppext peapv0 00. PEAPv1 и PEAPv2 были определены в различных версиях черновика josefsson pppext eap tls eap. PEAPv1 был определен в черновиках josefsson pppext eap tls eap 00 по josefsson pppext eap tls eap 05, а PEAPv2 — в версиях, начиная с черновика josefsson pppext eap tls eap 06. Протокол определяет лишь последовательное использование нескольких механизмов EAP, но не какой-либо конкретный метод. Наиболее распространенными являются методы EAP MSCHAPv2 и EAP GTC.
РАДИУС и диаметр
Протоколы RADIUS и Diameter AAA могут инкапсулировать сообщения EAP. Устройства сетевого доступа (NAS) часто используют их для пересылки пакетов EAP между оконечными точками IEEE 802.1X и серверами AAA, обеспечивая работу IEEE 802.1X.
ПАНА
Протокол переноса аутентификации для доступа к сети (PANA) — это протокол на основе IP, позволяющий устройству аутентифицироваться в сети для получения доступа. PANA не определяет новые протоколы аутентификации, распределения ключей, согласования ключей или вывода ключей; для этих целей используется EAP, а PANA передает полезные данные EAP. PANA обеспечивает динамический выбор поставщика услуг, поддерживает различные методы аутентификации, подходит для роуминговых пользователей и не зависит от механизмов канального уровня.
ППС
EAP изначально был расширением для аутентификации протокола «точка-точка» (PPP). PPP поддерживает EAP с момента создания EAP как альтернативы протоколу аутентификации с подтверждением вызова (CHAP) и протоколу аутентификации по паролю (PAP), которые впоследствии были интегрированы в EAP. Расширение EAP для PPP было впервые определено в , а затем заменено .