Extensible Authentication Protocol ( EAP ) — это фреймворк аутентификации, часто используемый в сетевых и интернет-соединениях. Он определен в RFC 3748, который сделал RFC 2284 устаревшим, и обновлен в RFC 5247. EAP — это фреймворк аутентификации для обеспечения транспортировки и использования материалов и параметров, сгенерированных методами EAP. Существует множество методов, определенных в RFC, и существует ряд методов, специфичных для поставщиков, и новых предложений. EAP — это не проводной протокол; вместо этого он определяет только информацию из интерфейса и форматы. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP пользователем в сообщения этого протокола.
EAP широко используется. Например, в IEEE 802.11 (Wi-Fi) стандарты WPA и WPA2 приняли IEEE 802.1X (с различными типами EAP) в качестве канонического механизма аутентификации.
EAP — это инфраструктура аутентификации, а не конкретный механизм аутентификации. [1] Он предоставляет некоторые общие функции и согласование методов аутентификации, называемых методами EAP. В настоящее время определено около 40 различных методов. Методы, определенные в IETF RFC, включают 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, используемым при аутентификации в беспроводной локальной сети, описаны в RFC 4017. Список типов и кодов пакетов, используемых в EAP, доступен в реестре IANA EAP. [2]
Стандарт также описывает условия, при которых могут быть выполнены требования к управлению ключами AAA, описанные в RFC 4962.
Метод Lightweight Extensible Authentication Protocol (LEAP) был разработан Cisco Systems до ратификации IEEE стандарта безопасности 802.11i . [3] 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.
LEAP использует модифицированную версию MS-CHAP , протокола аутентификации , в котором учетные данные пользователя не защищены надежно и легко скомпрометированы; инструмент для взлома под названием ASLEAP был выпущен в начале 2004 года Джошуа Райтом. [4] Cisco рекомендует клиентам, которым абсолютно необходимо использовать LEAP, делать это только с достаточно сложными паролями, хотя сложные пароли трудно администрировать и обеспечивать соблюдение. Текущая рекомендация Cisco — использовать более новые и надежные протоколы EAP, такие как EAP-FAST, PEAP или EAP-TLS.
EAP Transport Layer Security (EAP-TLS), определенный в RFC 5216, является открытым стандартом IETF , который использует протокол Transport Layer Security (TLS) и хорошо поддерживается среди поставщиков беспроводных решений. EAP-TLS является исходным стандартным протоколом аутентификации EAP для беспроводных сетей.
EAP-TLS по-прежнему считается одним из самых безопасных доступных стандартов EAP, хотя TLS обеспечивает надежную защиту только до тех пор, пока пользователь понимает потенциальные предупреждения о ложных учетных данных, и повсеместно поддерживается всеми производителями оборудования и программного обеспечения беспроводных локальных сетей. До апреля 2005 года EAP-TLS был единственным поставщиком типа EAP, которому требовалось сертифицироваться для логотипа WPA или WPA2. [5] Существуют клиентские и серверные реализации 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 и мобильной операционной системе iOS от Apple.
В отличие от большинства реализаций TLS HTTPS , таких как во Всемирной паутине , большинство реализаций EAP-TLS требуют взаимной аутентификации с использованием клиентских сертификатов X.509 без предоставления возможности отключить это требование, даже несмотря на то, что стандарт не предписывает их использование. [6] [7] Некоторые определили, что это может значительно сократить принятие EAP-TLS и предотвратить «открытые», но зашифрованные точки доступа. [6] [7] 22 августа 2012 года hostapd (и wpa_supplicant) добавили в свой репозиторий Git поддержку типа EAP UNAUTH-TLS, специфичного для поставщика (используя проект hostapd/wpa_supplicant RFC 5612 Private Enterprise Number), [8] а 25 февраля 2014 года добавили поддержку типа EAP WFA-UNAUTH-TLS, специфичного для поставщика (используя Wi-Fi Alliance Private Enterprise Number), [9] [10] которые выполняют только аутентификацию сервера. Это позволило бы в ситуациях, похожих на HTTPS, когда беспроводная точка доступа разрешает свободный доступ и не аутентифицирует клиентов станции, но клиенты станции хотят использовать шифрование ( IEEE 802.11i-2004 , т.е. WPA2 ) и потенциально аутентифицировать беспроводную точку доступа. Также были предложения использовать IEEE 802.11u для точек доступа, чтобы сигнализировать, что они разрешают EAP-TLS, используя только аутентификацию на стороне сервера, используя стандартный тип EAP-TLS IETF вместо типа EAP, специфичного для поставщика. [11]
Требование клиентского сертификата, каким бы непопулярным оно ни было, — это то, что дает EAP-TLS его силу аутентификации и иллюстрирует классический компромисс между удобством и безопасностью. При наличии клиентского сертификата скомпрометированного пароля недостаточно для взлома систем с поддержкой EAP-TLS, поскольку злоумышленнику все равно нужен клиентский сертификат; на самом деле, пароль даже не нужен, поскольку он используется только для шифрования клиентского сертификата для хранения. Самая высокая доступная безопасность достигается, когда «закрытые ключи» клиентского сертификата размещаются на смарт-картах . [12] Это связано с тем, что нет способа украсть соответствующий закрытый ключ клиентского сертификата со смарт-карты, не украв саму карту. Более вероятно, что физическая кража смарт-карты будет замечена (и смарт-карта будет немедленно отозвана), чем (типичная) кража пароля. Кроме того, закрытый ключ на смарт-карте обычно шифруется с использованием PIN-кода, который известен только владельцу смарт-карты, что сводит к минимуму ее полезность для вора еще до того, как карта будет объявлена украденной и отозвана.
EAP-MD5 был единственным методом EAP, основанным на стандартах IETF, когда он был впервые определен в оригинальном RFC для EAP, RFC 2284. Он обеспечивает минимальную безопасность; хэш-функция MD5 уязвима для атак по словарю и не поддерживает генерацию ключей, что делает его непригодным для использования с динамическим WEP или WPA/WPA2 enterprise. EAP-MD5 отличается от других методов EAP тем, что он обеспечивает только аутентификацию однорангового узла EAP для сервера EAP, но не взаимную аутентификацию. Не предоставляя аутентификацию сервера EAP, этот метод EAP уязвим для атак типа «человек посередине». [13] Поддержка EAP-MD5 была впервые включена в Windows 2000 и устарела в Windows Vista . [14]
EAP Protected One-Time Password (EAP-POTP), описанный в RFC 4793, представляет собой метод EAP, разработанный RSA Laboratories, который использует токены одноразовых паролей (OTP), такие как портативное аппаратное устройство или аппаратный или программный модуль, работающий на персональном компьютере, для генерации ключей аутентификации. EAP-POTP может использоваться для обеспечения односторонней или взаимной аутентификации и ключевого материала в протоколах, использующих EAP.
Метод EAP-POTP обеспечивает двухфакторную аутентификацию пользователя, то есть для выполнения аутентификации пользователю необходим как физический доступ к токену, так и знание персонального идентификационного номера (ПИН-кода). [15]
[1] EAP Pre-shared key (EAP-PSK), определенный в RFC 4764, представляет собой метод EAP для взаимной аутентификации и получения сеансового ключа с использованием предварительного общего ключа (PSK). Он обеспечивает защищенный канал связи, когда взаимная аутентификация успешна, для обеих сторон для связи и предназначен для аутентификации в незащищенных сетях, таких как IEEE 802.11.
EAP-PSK документирован в экспериментальном RFC, который обеспечивает легкий и расширяемый метод EAP, не требующий никакой криптографии с открытым ключом. Обмен протоколом метода EAP осуществляется минимум четырьмя сообщениями.
EAP Password (EAP-PWD), определенный в RFC 5931, представляет собой метод EAP, который использует общий пароль для аутентификации. Пароль может быть низкоэнтропийным и может быть взят из некоторого набора возможных паролей, например словаря, который доступен злоумышленнику. Базовый обмен ключами устойчив к активным атакам, пассивным атакам и атакам по словарю.
EAP-PWD находится в базе Android 4.0 (ICS). Он есть в серверах RADIUS FreeRADIUS [16] и Radiator [17] , а также в hostapd и wpa_supplicant. [18]
EAP Tunneled Transport Layer Security (EAP-TTLS) — это протокол EAP, расширяющий TLS . Он был совместно разработан Funk Software и Certicom и широко поддерживается на разных платформах. Microsoft не включила собственную поддержку протокола EAP-TTLS в Windows XP , Vista или 7. Поддержка TTLS на этих платформах требует стороннего сертифицированного программного обеспечения Encryption Control Protocol (ECP). Microsoft Windows начала поддержку EAP-TTLS с Windows 8 , [19] поддержка EAP-TTLS [20] появилась в Windows Phone версии 8.1 . [21]
Клиент может, но не обязан проходить аутентификацию через подписанный CA PKI- сертификат на сервере. Это значительно упрощает процедуру настройки, поскольку сертификат не требуется для каждого клиента.
После того, как сервер надежно аутентифицирован для клиента через свой сертификат CA и, опционально, клиента для сервера, сервер может использовать установленное защищенное соединение («туннель») для аутентификации клиента. Он может использовать существующий и широко развернутый протокол и инфраструктуру аутентификации, включающую устаревшие механизмы паролей и базы данных аутентификации, в то время как защищенный туннель обеспечивает защиту от подслушивания и атаки типа «человек посередине» . Обратите внимание, что имя пользователя никогда не передается в незашифрованном виде, что повышает конфиденциальность.
Существуют две различные версии EAP-TTLS: оригинальный EAP-TTLS (он же EAP-TTLSv0) и EAP-TTLSv1. EAP-TTLSv0 описан в RFC 5281, EAP-TTLSv1 доступен в виде интернет-проекта. [22]
EAP Internet Key Exchange v. 2 (EAP-IKEv2) — это метод EAP, основанный на протоколе Internet Key Exchange версии 2 (IKEv2). Он обеспечивает взаимную аутентификацию и установление сеансового ключа между одноранговым узлом EAP и сервером EAP. Он поддерживает методы аутентификации, основанные на следующих типах учетных данных:
Можно использовать разные учетные данные аутентификации (и, следовательно, технику) в каждом направлении. Например, сервер EAP аутентифицирует себя с помощью пары открытого/закрытого ключей, а одноранговый узел EAP — с помощью симметричного ключа. Однако не все из девяти теоретических комбинаций ожидаются на практике. В частности, стандарт RFC 5106 перечисляет четыре варианта использования: сервер аутентифицируется с помощью асимметричной пары ключей, в то время как клиент использует любой из трех методов; и обе стороны используют симметричный ключ.
EAP-IKEv2 описан в RFC 5106, и существует прототипная реализация.
Гибкая аутентификация через защищенное туннелирование (EAP-FAST; RFC 4851) — это протокол, предложенный Cisco Systems в качестве замены LEAP . [23] Протокол был разработан для устранения недостатков LEAP при сохранении «легкой» реализации. Использование сертификатов сервера является необязательным в EAP-FAST. EAP-FAST использует защищенные учетные данные доступа (PAC) для установления туннеля TLS, в котором проверяются учетные данные клиента.
EAP-FAST состоит из трех фаз: [24]
Когда включена автоматическая подготовка PAC, EAP-FAST имеет уязвимость, при которой злоумышленник может перехватить PAC и использовать его для компрометации учетных данных пользователя. Эта уязвимость смягчается ручной подготовкой PAC или использованием сертификатов сервера для фазы подготовки PAC.
Стоит отметить, что файл PAC выдается на основе пользователя. Это требование RFC 4851 sec 7.4.4, поэтому если новый пользователь входит в сеть с устройства, сначала необходимо предоставить новый файл PAC. Это одна из причин, по которой сложно не запускать EAP-FAST в небезопасном анонимном режиме предоставления. Альтернативой является использование паролей устройств, но тогда в сети проверяется устройство, а не пользователь.
EAP-FAST можно использовать без PAC-файлов, используя обычный TLS.
EAP-FAST изначально поддерживается в Apple OS X 10.4.8 и более поздних версиях. Cisco поставляет модуль EAP-FAST [25] для Windows Vista [26] и более поздних операционных систем, которые имеют расширяемую архитектуру EAPHost для новых методов аутентификации и запрашивающих устройств. [27]
Tunnel Extensible Authentication Protocol (TEAP; RFC 7170) — это туннельный метод EAP, который обеспечивает безопасную связь между одноранговым узлом и сервером с использованием протокола Transport Layer Security (TLS) для установления взаимно аутентифицированного туннеля. В туннеле объекты TLV (Type-Length-Value) используются для передачи данных, связанных с аутентификацией, между одноранговым узлом EAP и сервером EAP.
В дополнение к аутентификации однорангового узла TEAP позволяет одноранговому узлу запрашивать у сервера сертификат, отправляя запрос в формате PKCS#10 . После получения запроса на сертификат и аутентификации однорангового узла сервер может предоставить одноранговому узлу сертификат в формате PKCS#7 ( RFC 2325). Сервер также может распространять доверенные корневые сертификаты одноранговому узлу в формате PKCS#7 ( RFC 2325). Обе операции заключены в соответствующие TLV и безопасно выполняются в уже установленном туннеле TLS.
Модуль идентификации абонента EAP (EAP-SIM) используется для аутентификации и распространения сеансовых ключей с использованием модуля идентификации абонента (SIM) из Глобальной системы мобильной связи ( GSM ).
Сотовые сети GSM используют карту модуля идентификации абонента для выполнения аутентификации пользователя. EAP-SIM используют алгоритм аутентификации SIM между клиентом и сервером аутентификации, авторизации и учета (AAA), обеспечивая взаимную аутентификацию между клиентом и сетью.
В EAP-SIM связь между SIM-картой и центром аутентификации (AuC) заменяет необходимость в предварительно установленном пароле между клиентом и сервером AAA.
Алгоритмы A3/A8 запускаются несколько раз с различными 128-битными вызовами, поэтому будет больше 64-битных Kc-ов, которые будут объединены/смешаны для создания более сильных ключей (Kc-ы не будут использоваться напрямую). Также был преодолен недостаток взаимной аутентификации в GSM.
EAP-SIM описан в RFC 4186.
Метод расширяемого протокола аутентификации для универсальной системы мобильной связи (UMTS) аутентификации и согласования ключей (EAP-AKA) — это механизм EAP для аутентификации и распределения сеансовых ключей с использованием модуля идентификации абонента UMTS ( USIM ). EAP-AKA определен в RFC 4187.
Вариант EAP-AKA' EAP-AKA, определенный в RFC 5448, используется для не-3GPP доступа к базовой сети 3GPP . Например, через EVDO , WiFi или WiMax .
EAP Generic Token Card, или EAP-GTC, — это метод EAP, созданный Cisco в качестве альтернативы PEAPv0/EAP-MSCHAPv2 и определенный в RFC 2284 и RFC 3748. EAP-GTC переносит текстовый запрос от сервера аутентификации и ответ, сгенерированный токеном безопасности . Механизм аутентификации PEAP-GTC позволяет выполнять общую аутентификацию для ряда баз данных, таких как Novell Directory Service (NDS) и Lightweight Directory Access Protocol (LDAP), а также использовать одноразовый пароль .
EAP с зашифрованным обменом ключами , или EAP-EKE, является одним из немногих методов EAP, которые обеспечивают безопасную взаимную аутентификацию с использованием коротких паролей и без необходимости в сертификатах открытых ключей . Это трехраундовый обмен, основанный на варианте Диффи-Хеллмана известного протокола EKE.
EAP-EKE определен в RFC 6124.
Nimble out-of-band authentication for EAP [28] (EAP-NOOB) — это универсальное решение для начальной загрузки устройств, которые не имеют предварительно настроенных учетных данных аутентификации и которые еще не зарегистрированы ни на одном сервере. Это особенно полезно для гаджетов и игрушек Интернета вещей (IoT), которые поставляются без информации о владельце, сети или сервере. Аутентификация для этого метода EAP основана на поддерживаемом пользователем внеполосном (OOB) канале между сервером и одноранговым узлом. EAP-NOOB поддерживает множество типов каналов OOB, таких как QR-коды, метки NFC, аудио и т. д., и в отличие от других методов EAP, безопасность протокола была проверена путем формального моделирования спецификации с помощью инструментов ProVerif и MCRL2 . [29]
EAP-NOOB выполняет эфемерную эллиптическую кривую Диффи-Хеллмана (ECDHE) по внутриполосному каналу EAP. Затем пользователь подтверждает этот обмен, передавая сообщение OOB. Пользователи могут передавать сообщение OOB от однорангового узла на сервер, когда, например, устройство является смарт-телевизором, который может показывать QR-код. В качестве альтернативы пользователи могут передавать сообщение OOB от сервера одноранговому узлу, когда, например, загружаемое устройство является камерой, которая может только считывать QR-код.
EAP не является проводным протоколом; вместо этого он только определяет форматы сообщений. Каждый протокол, который использует EAP, определяет способ инкапсуляции сообщений EAP в сообщения этого протокола. [30] [31]
Инкапсуляция EAP через IEEE 802 определена в IEEE 802.1X и известна как «EAP через локальные сети» или EAPOL. [32] [33] [34] EAPOL изначально был разработан для IEEE 802.3 Ethernet в 802.1X-2001, но был уточнен для соответствия другим технологиям IEEE 802 LAN, таким как беспроводной интерфейс IEEE 802.11 и интерфейс распределенных данных по оптоволокну (ANSI X3T9.5/X3T12, принятый как ISO 9314) в 802.1X-2004. [35] Протокол EAPOL также был изменен для использования с IEEE 802.1AE (MACsec) и IEEE 802.1AR (начальная идентификация устройства, IDevID) в 802.1X-2010. [36]
Когда EAP вызывается устройством сервера сетевого доступа (NAS) с поддержкой 802.1X, таким как беспроводная точка доступа IEEE 802.11i-2004 (WAP), современные методы EAP могут обеспечить безопасный механизм аутентификации и согласовать безопасный закрытый ключ (парный главный ключ, PMK) между клиентом и NAS, который затем может использоваться для сеанса беспроводного шифрования с использованием шифрования TKIP или CCMP (на основе AES ).
Защищенный расширяемый протокол аутентификации , также известный как защищенный EAP или просто PEAP, представляет собой протокол, который инкапсулирует EAP в потенциально зашифрованный и аутентифицированный туннель Transport Layer Security (TLS) . [37] [38] [39] Целью было исправление недостатков EAP; EAP предполагал защищенный канал связи, такой как тот, который обеспечивается физической безопасностью, поэтому средства для защиты разговора EAP не были предусмотрены. [40]
PEAP был совместно разработан Cisco Systems, Microsoft и RSA Security. PEAPv0 была версией, включенной в Microsoft Windows XP , и была номинально определена в draft-kamath-pppext-peapv0-00. PEAPv1 и PEAPv2 были определены в различных версиях draft-josefsson-pppext-eap-tls-eap . PEAPv1 был определен в draft-josefsson-pppext-eap-tls-eap-00 через draft-josefsson-pppext-eap-tls-eap-05, [41] а PEAPv2 был определен в версиях, начинающихся с draft-josefsson-pppext-eap-tls-eap-06. [42]
Протокол определяет только цепочку нескольких механизмов EAP, а не какой-либо конкретный метод. [38] [43] Наиболее часто поддерживаются методы EAP -MSCHAPv2 и EAP-GTC . [ необходима ссылка ]
Оба протокола RADIUS и Diameter AAA могут инкапсулировать сообщения EAP. Они часто используются устройствами Network Access Server (NAS) для пересылки пакетов EAP между конечными точками IEEE 802.1X и серверами AAA для содействия IEEE 802.1X.
Протокол аутентификации для сетевого доступа (PANA) — это основанный на IP протокол, который позволяет устройству аутентифицировать себя в сети для получения доступа. PANA не будет определять никаких новых протоколов аутентификации, распределения ключей, согласования ключей или протоколов выработки ключей; для этих целей будет использоваться EAP, а PANA будет переносить полезную нагрузку EAP. PANA допускает динамический выбор поставщика услуг, поддерживает различные методы аутентификации, подходит для пользователей в роуминге и не зависит от механизмов канального уровня.
EAP изначально был расширением аутентификации для протокола Point-to-Point (PPP). PPP поддерживает EAP с тех пор, как EAP был создан как альтернатива протоколу аутентификации Challenge-Handshake (CHAP) и протоколу аутентификации Password (PAP), которые в конечном итоге были включены в EAP. Расширение EAP для PPP было впервые определено в RFC 2284, теперь устаревшем в RFC 3748.
Сообщение certificate_request включается, когда сервер хочет, чтобы одноранговый узел аутентифицировал себя с помощью открытого ключа. Хотя сервер EAP ДОЛЖЕН требовать аутентификацию однорангового узла, это не обязательно, поскольку существуют обстоятельства, при которых аутентификация однорангового узла не требуется (например, экстренные службы, как описано в [UNAUTH]), или когда одноранговый узел будет аутентифицироваться с помощью некоторых других средств.