Войти
Extensible Authentication Protocol (EAP ) - это структура аутентификации, часто используемая в сетевых и интернет-соединениях. Он определен в RFC 3748, который сделал RFC 2284 устаревшим, и обновлен в RFC 5247. EAP - это структура аутентификации для обеспечения транспортировки и использования материалов и параметров, генерируемых методами EAP. Есть много методов, определенных RFC, и существует ряд специфических для поставщиков методов и новых предложений. EAP не является проводным протоколом; вместо этого он только определяет информацию из интерфейса и форматов. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP пользователя в сообщения этого протокола.
EAP широко используется. Например, в IEEE 802.11 (WiFi) стандарты WPA и WPA2 приняли IEEE 802.1X (с различными типами EAP) в качестве канонического механизма аутентификации.
EAP - это структура аутентификации, а не конкретный механизм аутентификации. Он предоставляет некоторые общие функции и согласование методов аутентификации, называемых методами 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.
Стандарт также описывает условия, при которых могут быть удовлетворены требования к управлению ключами AAA, описанные в RFC 4962.
Метод Легкий расширяемый протокол аутентификации (LEAP) был разработан Cisco Systems до Ратификация IEEE стандарта безопасности 802.11i. Cisco распространила протокол через CCX (Cisco Certified Extensions) в рамках внедрения 802.1X и динамического WEP в отрасли в отсутствие стандарта. В любой операционной системе Windows нет встроенной поддержки LEAP, но он широко поддерживается сторонним клиентским программным обеспечением, которое чаще всего входит в состав устройств WLAN (беспроводная локальная сеть). LEAP Поддержка Microsoft Windows 7 и Microsoft Windows Vista может быть добавлена путем загрузки клиентской надстройки от Cisco, которая обеспечивает поддержку как LEAP, так и EAP-FAST. Из-за широкого внедрения LEAP в сетевой индустрии многие другие поставщики WLAN заявляют о поддержке LEAP.
LEAP использует модифицированную версию MS-CHAP, протокола аутентификации, в котором учетные данные пользователя не защищены надежно и легко скомпрометированы; инструмент эксплойта под названием ASLEAP был выпущен в начале 2004 года Джошуа Райтом. 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. Существуют клиентские и серверные реализации 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 без возможности отключения требования, даже если стандарт не требует их использования. Некоторые определили, что это может значительно снизить внедрение EAP-TLS и предотвратить «открытые», но зашифрованные точки доступа. 22 августа 2012 года hostapd (и wpa_supplicant) добавил поддержку в свой репозиторий Git для типа EAP UNAUTH-TLS, зависящего от поставщика (с использованием проекта hostapd / wpa_supplicant RFC 5612 Private Enterprise Number), а 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, потому что злоумышленнику по-прежнему требуется сертификат на стороне клиента; действительно, пароль даже не нужен, поскольку он используется только для шифрования сертификата на стороне клиента для хранения. Наивысшая доступная безопасность обеспечивается тогда, когда «частные ключи» сертификата на стороне клиента размещаются в смарт-картах. Это связано с тем, что невозможно украсть соответствующий закрытый ключ клиентского сертификата со смарт-карты без кражи самой карты. Более вероятно, что физическая кража смарт-карты будет замечена (и смарт-карта немедленно отозвана), чем будет замечена (типичная) кража пароля. Кроме того, закрытый ключ на смарт-карте обычно зашифрован с помощью ПИН-кода, который знает только владелец смарт-карты, что сводит к минимуму его полезность для вора даже до того, как карта будет объявлена украденной и отозванной.
EAP-MD5 был единственным методом EAP на основе IETF Standards Track, когда он был впервые определен в исходном RFC для EAP, RFC 2284. Он предлагает минимальную безопасность; хэш-функция MD5 уязвима для словарных атак и не поддерживает генерацию ключей, что делает ее непригодной для использования с динамическим WEP или WPA / WPA2 Enterprise. EAP-MD5 отличается от других методов EAP тем, что он обеспечивает только аутентификацию однорангового узла EAP на сервере EAP, но не взаимную аутентификацию. Не обеспечивая аутентификацию сервера EAP, этот метод EAP уязвим для атак типа "злоумышленник в середине". Поддержка EAP-MD5 впервые была включена в Windows 2000 и устарела в Windows Vista.
EAP Protected One-Time Password (EAP-POTP), который описан в RFC 4793, представляет собой метод EAP, разработанный RSA Laboratories, который использует токены одноразового пароля (OTP), такие как портативное аппаратное устройство или аппаратный или программный модуль. работает на персональном компьютере, чтобы генерировать ключи аутентификации. EAP-POTP может использоваться для обеспечения односторонней или взаимной аутентификации и ключевого материала в протоколах, использующих EAP.
Метод EAP-POTP обеспечивает двухфакторную аутентификацию пользователя, что означает, что пользователю необходим как физический доступ к токену, так и знание личного идентификационного номера (PIN) для выполнения аутентификации.
Общий ключ EAP (EAP-PSK), определенный в RFC 4764, является методом EAP для взаимной аутентификации и получение сеансового ключа с использованием предварительного общего ключа (PSK). Он обеспечивает защищенный канал связи, когда взаимная аутентификация успешна, для связи обеих сторон и предназначена для аутентификации в небезопасных сетях, таких как IEEE 802.11.
EAP-PSK задокументирован в экспериментальном RFC, который предоставляет легкий и расширяемый метод EAP, не требующий криптографии с открытым ключом. Обмен по протоколу метода EAP осуществляется минимум четырьмя сообщениями.
Пароль EAP (EAP-PWD), определенный в RFC 5931, представляет собой метод EAP, который использует общий пароль для аутентификации. Пароль может быть низкоэнтропийным и может быть получен из некоторого набора возможных паролей, например словаря, который доступен злоумышленнику. Базовый обмен ключами устойчив к активной атаке, пассивной атаке и атаке по словарю.
EAP-PWD лежит в основе Android 4.0 (ICS), он находится на RADIUS-серверах FreeRADIUS и Radiator, а также в hostapd и wpa_supplicant.
EAP Tunneled Transport Layer Security (EAP-TTLS) - это протокол EAP, расширяющий TLS. Он был разработан совместно Funk Software и Certicom и широко поддерживается на разных платформах. Microsoft не реализовала встроенную поддержку протокола EAP-TTLS в Windows XP, Vista или 7. Для поддержки TTLS на этих платформах требуется стороннее программное обеспечение, сертифицированное для протокола управления шифрованием (ECP). Microsoft Windows запустила поддержку EAP-TTLS в Windows 8, поддержка EAP-TTLS появилась в Windows Phone версии 8.1.
Клиент может, но не обязательно аутентифицирован через сертификат CA с подписью PKI на сервере. Это значительно упрощает процедуру настройки, поскольку сертификат не требуется на каждом клиенте.
После того, как сервер надежно аутентифицирован для клиента с помощью его сертификата CA и, возможно, клиента для сервера, сервер может затем использовать установленное безопасное соединение («туннель») для аутентификации клиента. Он может использовать существующий и широко распространенный протокол и инфраструктуру аутентификации, включая устаревшие механизмы паролей и базы данных аутентификации, в то время как безопасный туннель обеспечивает защиту от перехвата и атак типа «человек посередине». Обратите внимание, что имя пользователя никогда не передается в незашифрованном виде, что улучшает конфиденциальность.
Существуют две различные версии EAP-TTLS: исходный EAP-TTLS (также известный как EAP-TTLSv0) и EAP-TTLSv1. EAP-TTLSv0 описан в RFC 5281, EAP-TTLSv1 доступен как черновик в Интернете.
EAP Internet Key Exchange v. 2 (EAP-IKEv2) - это метод EAP, основанный на протоколе Internet Key Exchange версии 2 (IKEv2). Он обеспечивает взаимную аутентификацию и установление сеансового ключа между одноранговым узлом EAP и сервером EAP. Он поддерживает методы аутентификации, основанные на следующих типах учетных данных:
Можно использовать другую аутентификацию учетные данные (и тем самым техника) в каждом направлении. Например, сервер EAP аутентифицирует себя с помощью пары открытый / закрытый ключ, а одноранговый узел EAP - с использованием симметричного ключа. В частности, на практике ожидается использование следующих комбинаций:
EAP-IKEv2 описан в RFC 5106, и существует реализация прототипа.
Гибкая аутентификация через безопасное туннелирование (EAP-FAST; RFC 4851 ) - это протокол, предложенный Cisco Systems вместо LEAP. Протокол был разработан для устранения слабых мест LEAP при сохранении «облегченной» реализации. Использование сертификатов сервера в EAP-FAST не является обязательным. EAP-FAST использует учетные данные защищенного доступа (PAC) для установления туннеля TLS, в котором проверяются учетные данные клиента.
EAP-FAST состоит из трех фаз:
| Фаза | Функция | Описание | Цель |
|---|---|---|---|
| 0 | Внутриполосное обеспечение - предоставить одноранговому узлу общий секрет, который будет использоваться в безопасном диалоге фазы 1 | Использует аутентифицированный протокол Диффи-Хеллмана (ADHP). Эта фаза не зависит от других фаз; следовательно, в будущем может использоваться любая другая схема (внутриполосная или внеполосная). | Устранение требования в клиенте устанавливать главный секрет каждый раз, когда клиенту требуется доступ к сети |
| 1 | Установление туннеля | Аутентификация с помощью PAC и установка туннельного ключа | Создание ключа для обеспечения конфиденциальности и целостности во время процесса аутентификации на этапе 2 |
| 2 | Аутентификация | Аутентифицирует однорангового узла | Множественные туннельные безопасные механизмы аутентификации (обмен учетными данными) |
Когда включена автоматическая инициализация 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 для Windows Vista и более поздних операционных систем, которые имеют расширяемую архитектуру EAPHost для новых методов аутентификации и соискателей.
Tunnel Extensible Authentication Protocol (TEAP; RFC 7170 ) - это метод EAP на основе туннеля, который обеспечивает безопасную связь между одноранговым узлом и сервером с использованием безопасности транспортного уровня (TLS) протокол для создания туннеля с взаимной аутентификацией. В туннеле объекты TLV (тип-длина-значение) используются для передачи данных, связанных с аутентификацией, между одноранговым узлом EAP и сервером EAP.
В дополнение к аутентификации однорангового узла TEAP позволяет одноранговому узлу запрашивать сертификат у сервера, отправляя запрос в формате PKCS # 10, и сервер может предоставлять сертификат одноранговому узлу в [rfc: 2315 PKCS # 7] формат. Сервер также может рассылать доверенные корневые сертификаты партнеру в формате [rfc: 2315 PKCS # 7]. Обе операции заключены в соответствующие TLV и выполняются безопасным способом внутри ранее установленного туннеля TLS.
EAP Subscriber Identity Module (EAP-SIM) используется для аутентификации и распределения сеансовых ключей с помощью модуля идентификации абонента ( SIM) из глобальной системы мобильной связи (GSM ).
Сотовые сети GSM используют карту модуля идентификации абонента для аутентификации пользователя. EAP-SIM использует алгоритм аутентификации SIM-карты между клиентом и сервером аутентификации, авторизации и учета (AAA), обеспечивая взаимную аутентификацию между клиентом и сетью.
В EAP-SIM обмен данными между SIM-картой и центром аутентификации (AuC) заменяет необходимость предварительно установленного пароля между клиентом и сервером AAA.
Алгоритмы A3 / A8 запускаются несколько раз с различными 128-битными задачами, поэтому будет больше 64-битных Kc-s, которые будут объединены / смешаны для создания более сильных ключей (Kc-s выиграла ' t использоваться напрямую). Отсутствие взаимной аутентификации в 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 с encrypted key exchange, или EAP-EKE, является одним из немногих методов EAP которые обеспечивают безопасную взаимную аутентификацию с использованием коротких паролей и не требуют сертификатов открытых ключей. Это трехэтапный обмен, основанный на варианте Диффи-Хеллмана известного протокола EKE.
EAP-EKE указан в RFC 6124.
Nimble внеполосная аутентификация для EAP ( EAP-NOOB) - это предлагаемое (в процессе разработки, не RFC) универсальное решение начальной загрузки для устройств, у которых нет предварительно настроенных учетных данных для аутентификации и которые еще не зарегистрированы ни на одном сервере. Это особенно полезно для гаджетов и игрушек Интернета вещей (IoT), которые не содержат информации о владельце, сети или сервере. Аутентификация для этого метода EAP основана на внеполосном (OOB) канале, поддерживаемом пользователем между сервером и одноранговым узлом. EAP-NOOB поддерживает множество типов каналов OOB, таких как QR-коды, теги NFC, аудио и т. Д., И, в отличие от других методов EAP, безопасность протокола была подтверждена формальным моделированием спецификации с ProVerif и Инструменты MCRL2.
EAP-NOOB выполняет эфемерную эллиптическую кривую Диффи-Хеллмана (ECDHE) по внутриполосному каналу EAP. Затем пользователь подтверждает этот обмен, передавая сообщение OOB. Пользователи могут передавать OOB-сообщение от однорангового узла на сервер, например, когда устройство представляет собой смарт-телевизор, который может отображать QR-код. В качестве альтернативы пользователи могут передавать сообщение OOB от сервера к партнеру, когда, например, загружаемое устройство является камерой, которая может считывать только QR-код.
EAP не является проводным протоколом; вместо этого он определяет только форматы сообщений. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP в сообщениях этого протокола.
Инкапсуляция EAP поверх IEEE 802 определен в IEEE 802.1X и известен как «EAP через LAN» или EAPOL. Первоначально EAPOL был разработан для IEEE 802.3 ethernet в 802.1X-2001, но был уточнен для соответствия другим технологиям LAN IEEE 802, таким как IEEE 802.11 беспроводной и Fiber Distributed Data Interface (ISO 9314-2) в 802.1X-2004. Протокол EAPOL также был изменен для использования с IEEE 802.1AE (MACsec) и IEEE 802.1AR (исходный идентификатор устройства, IDevID) в 802.1X-2010.
Когда EAP запускается устройством сервера доступа к сети (NAS) с поддержкой 802.1X, например точкой беспроводного доступа (WAP) IEEE 802.11i-2004, современные методы EAP могут обеспечить безопасную механизм аутентификации и согласование безопасного закрытого ключа (парного главного ключа, PMK) между клиентом и NAS, который затем может использоваться для сеанса беспроводного шифрования с использованием TKIP или CCMP (на основе на AES ) шифровании.
Protected Extensible Authentication Protocol, также известный как Protected EAP или просто PEAP, - это протокол, который инкапсулирует EAP в потенциально зашифрованный и аутентифицированный транспортный Уровень безопасности (TLS) туннель. Целью было исправить недостатки в EAP; EAP предполагал наличие защищенного канала связи, например, обеспечиваемого физической безопасностью, поэтому средства для защиты разговора EAP не были предоставлены.
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, а PEAPv2 был определен в версиях начиная с draft-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 был создан как альтернатива протоколу аутентификации Challenge-Handshake (CHAP) и протоколу аутентификации паролей (PAP), которые в конечном итоге были включены в EAP. Расширение EAP для PPP было впервые определено в RFC 2284, теперь устарело в RFC 3748.
