Из Википедии, бесплатной энциклопедии
  (Перенаправлено с EAP-TTLS )
Перейти к навигации Перейти к поиску

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 - это структура аутентификации, а не конкретный механизм аутентификации. [1] Он обеспечивает некоторые общие функции и согласование методов аутентификации, называемых методами 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, используемым при аутентификации беспроводной локальной сети, описаны в RFC 4017. Список типов и кодов пакетов, используемых в EAP, доступен в реестре IANA EAP.

Стандарт также описывает условия, при которых могут быть выполнены требования к управлению ключами AAA, описанные в RFC 4962.

Легкий расширяемый протокол аутентификации (LEAP) [ править ]

Основная статья: Легкий расширяемый протокол аутентификации

Метод облегченного расширяемого протокола аутентификации (LEAP) был разработан Cisco Systems до ратификации IEEE стандарта безопасности 802.11i . [2] Cisco распространила протокол через CCX (Cisco Certified Extensions) как часть внедрения 802.1X и динамического WEP в отрасли в отсутствие стандарта. В любой операционной системе Windows отсутствует встроенная поддержка LEAP , но она широко поддерживается клиентским программным обеспечением сторонних производителей, которое чаще всего входит в состав устройств WLAN (беспроводной локальной сети). ПРЫГНУТЬПоддержка Microsoft Windows 7 и Microsoft Windows Vista может быть добавлена ​​путем загрузки клиентской надстройки от Cisco, которая обеспечивает поддержку как LEAP, так и EAP-FAST. Из-за широкого внедрения LEAP в сетевой индустрии многие другие поставщики WLAN [ кто? ] требовать поддержки для LEAP.

LEAP использует модифицированную версию MS-CHAP , протокола аутентификации , в котором учетные данные пользователя не защищены надежно и легко скомпрометированы; инструмент эксплойта под названием ASLEAP был выпущен в начале 2004 года Джошуа Райтом. [3] Cisco рекомендует клиентам, которые абсолютно должны использовать LEAP, делать это только с достаточно сложными паролями, хотя сложные пароли сложно администрировать и применять. Текущая рекомендация Cisco - использовать новые и более мощные протоколы EAP, такие как EAP-FAST, PEAP или EAP-TLS.

Безопасность транспортного уровня EAP (EAP-TLS) [ править ]

EAP Transport Layer Security (EAP-TLS), определенный в RFC 5216, является открытым стандартом IETF, который использует протокол TLS и хорошо поддерживается поставщиками беспроводной связи. EAP-TLS - это оригинальный стандартный протокол аутентификации EAP в беспроводной локальной сети.

EAP-TLS по-прежнему считается одним из самых безопасных доступных стандартов EAP, хотя TLS обеспечивает надежную безопасность только до тех пор, пока пользователь понимает возможные предупреждения о ложных учетных данных, и повсеместно поддерживается всеми производителями оборудования и программного обеспечения для беспроводных локальных сетей. До апреля 2005 года EAP-TLS был единственным поставщиком типа EAP, который требовался для сертификации на наличие логотипа WPA или WPA2. [4] Существуют клиентские и серверные реализации 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.

В отличие от большинства реализаций HTTPS TLS , таких как World Wide Web , большинство реализаций EAP-TLS требуют взаимной аутентификации с использованием клиентских сертификатов X.509 без возможности отключения требования, даже если стандарт не требует их использование. [5] [6] Некоторые определили, что это может значительно снизить внедрение EAP-TLS и предотвратить «открытые», но зашифрованные точки доступа. [5] [6] 22 августа 2012 года hostapd (и wpa_supplicant) добавили поддержку в свой Gitрепозиторий для типа EAP, зависящего от поставщика UNAUTH-TLS (с использованием номера частного предприятия RFC 5612 проекта hostapd / wpa_supplicant), [7], а 25 февраля 2014 г. добавлена ​​поддержка типа EAP для конкретного поставщика WFA-UNAUTH-TLS (с использованием Номер частного предприятия Wi-Fi Alliance ), [8] [9], который выполняет только проверку подлинности сервера. Это допускает ситуации, похожие на HTTPS, где беспроводная точка доступа разрешает свободный доступ и не аутентифицирует клиентов станции, но клиенты станции хотят использовать шифрование ( IEEE 802.11i-2004, т.е. WPA2 ) и потенциально аутентифицировать беспроводную точку доступа. Также были предложения использовать IEEE 802.11u.для точек доступа, чтобы сигнализировать о том, что они разрешают EAP-TLS, используя только аутентификацию на стороне сервера, используя стандартный тип EAP-TLS IETF вместо типа EAP, зависящего от поставщика. [10]

Требование сертификата на стороне клиента, каким бы непопулярным оно ни было, придает EAP-TLS надежность аутентификации и демонстрирует классический компромисс между удобством и безопасностью. С сертификатом на стороне клиента скомпрометированного пароля недостаточно для взлома систем с поддержкой EAP-TLS, потому что злоумышленнику по-прежнему нужен сертификат на стороне клиента; действительно, пароль даже не нужен, поскольку он используется только для шифрования сертификата на стороне клиента для хранения. Наивысший уровень безопасности возможен, когда «закрытые ключи» сертификата на стороне клиента размещаются на смарт-картах . [11]Это связано с тем, что невозможно украсть соответствующий закрытый ключ клиентского сертификата со смарт-карты без кражи самой карты. Более вероятно, что физическая кража смарт-карты будет замечена (и смарт-карта немедленно отозвана), чем будет замечена (типичная) кража пароля. Кроме того, закрытый ключ на смарт-карте обычно зашифрован с использованием ПИН-кода, который знает только владелец смарт-карты, что сводит к минимуму его полезность для вора даже до того, как карта будет объявлена ​​украденной и отозванной.

EAP-MD5 [ править ]

EAP-MD5 был единственным методом EAP на основе IETF Standards Track, когда он был впервые определен в исходном RFC для EAP, RFC 2284. Он обеспечивает минимальную безопасность; MD5 хэш - функция уязвима для атак по словарю , и не поддерживает генерацию ключей, что делает его непригодным для использования с динамическим WEP или WPA / WPA2 предприятия. EAP-MD5 отличается от других методов EAP тем, что он обеспечивает только аутентификацию однорангового узла EAP на сервере EAP, но не взаимную аутентификацию. Не обеспечивая аутентификацию сервера EAP, этот метод EAP уязвим для атак типа "злоумышленник в середине". [12] Поддержка EAP-MD5 впервые была включена в Windows 2000 и устарела в Windows Vista . [13]

Одноразовый пароль, защищенный EAP (EAP-POTP) [ править ]

Защищенный одноразовый пароль EAP (EAP-POTP), описанный в RFC 4793, представляет собой метод EAP, разработанный RSA Laboratories, который использует токены одноразового пароля (OTP), такие как портативное аппаратное устройство или аппаратный или программный модуль. работает на персональном компьютере, чтобы генерировать ключи аутентификации. EAP-POTP может использоваться для обеспечения односторонней или взаимной аутентификации и ключевого материала в протоколах, использующих EAP.

Метод EAP-POTP обеспечивает двухфакторную аутентификацию пользователя, что означает, что пользователю необходим как физический доступ к токену, так и знание личного идентификационного номера (PIN) для выполнения аутентификации. [14]

Общий ключ EAP (EAP-PSK) [ править ]

[1] Общий ключ EAP (EAP-PSK), определенный в RFC 4764, представляет собой метод EAP для взаимной аутентификации и получения сеансового ключа с использованием предварительного общего ключа (PSK). Он обеспечивает защищенный канал связи, когда взаимная аутентификация успешна, для связи обеих сторон и предназначена для аутентификации в незащищенных сетях, таких как IEEE 802.11.

EAP-PSK задокументирован в экспериментальном RFC, который предоставляет легкий и расширяемый метод EAP, не требующий криптографии с открытым ключом. Обмен по протоколу метода EAP осуществляется минимум четырьмя сообщениями.

Пароль EAP (EAP-PWD) [ редактировать ]

Пароль EAP (EAP-PWD), определенный в RFC 5931, представляет собой метод EAP, который использует общий пароль для аутентификации. Пароль может быть низкоэнтропийным и может быть получен из некоторого набора возможных паролей, например словаря, доступного злоумышленнику. Базовый обмен ключами устойчив к активным атакам, пассивным атакам и атакам по словарю.

EAP-PWD находится в основе Android 4.0 (ICS), он есть в RADIUS-серверах FreeRADIUS [15] и Radiator [16] , а также в hostapd и wpa_supplicant. [17]

EAP Tunneled Transport Layer Security (EAP-TTLS) [ править ]

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 , [18] поддержка EAP-TTLS [19] появилась в Windows Phone версии 8.1 . [20]

Клиент может, но не должен быть идентифицирован через CA -signed PKI сертификат сервера. Это значительно упрощает процедуру настройки, поскольку сертификат не требуется на каждом клиенте.

После того, как сервер надежно аутентифицирован для клиента с помощью его сертификата CA и, возможно, клиента для сервера, сервер может затем использовать установленное безопасное соединение («туннель») для аутентификации клиента. Он может использовать существующий и широко распространенный протокол и инфраструктуру аутентификации, включая устаревшие механизмы паролей и базы данных аутентификации, в то время как безопасный туннель обеспечивает защиту от подслушивания и атаки типа « злоумышленник в середине» . Обратите внимание, что имя пользователя никогда не передается в незашифрованном виде, что улучшает конфиденциальность.

Существуют две различные версии EAP-TTLS: исходный EAP-TTLS (также известный как EAP-TTLSv0) и EAP-TTLSv1. EAP-TTLSv0 описан в RFC 5281, EAP-TTLSv1 доступен как черновик в Интернете. [21]

EAP Internet Key Exchange v. 2 (EAP-IKEv2) [ править ]

EAP Internet Key Exchange v. 2 (EAP-IKEv2) - это метод EAP, основанный на протоколе Internet Key Exchange версии 2 (IKEv2). Он обеспечивает взаимную аутентификацию и установление сеансового ключа между одноранговым узлом EAP и сервером EAP. Он поддерживает методы аутентификации, основанные на следующих типах учетных данных:

Асимметричные пары ключей
Пары открытого / закрытого ключей, в которых открытый ключ встроен в цифровой сертификат , а соответствующий закрытый ключ известен только одной стороне.
Пароли
Битовые строки с низкой энтропией , известные как серверу, так и партнеру.
Симметричные ключи
Битовые строки с высокой энтропией, известные как серверу, так и партнеру.

Можно использовать разные учетные данные аутентификации (и, следовательно, методику) в каждом направлении. Например, сервер EAP аутентифицирует себя с помощью пары открытый / закрытый ключ, а одноранговый узел EAP - с использованием симметричного ключа. В частности, на практике предполагается использовать следующие комбинации:

EAP-IKEv2 описан в RFC 5106, и существует прототип реализации .

Гибкая аутентификация EAP через безопасное туннелирование (EAP-FAST) [ править ]

Гибкая аутентификация через безопасное туннелирование (EAP-FAST; RFC 4851) - это протокол, предложенный Cisco Systems в качестве замены LEAP . [22] Протокол был разработан для устранения недостатков LEAP при сохранении «облегченной» реализации. Использование сертификатов сервера в EAP-FAST не является обязательным. EAP-FAST использует учетные данные защищенного доступа (PAC) для установления туннеля TLS, в котором проверяются учетные данные клиента.

EAP-FAST состоит из трех этапов: [23]

ФазаФункцияОписаниеЦель
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 [24] для Windows Vista [25] и более поздних операционных систем, которые имеют расширяемую архитектуру EAPHost для новых методов аутентификации и соискателей. [26]

Протокол расширяемой аутентификации туннеля (TEAP) [ править ]

Протокол расширяемой аутентификации туннеля (TEAP; RFC 7170) - это метод EAP на основе туннеля, который обеспечивает безопасную связь между одноранговым узлом и сервером с помощью протокола TLS для установления туннеля с взаимной аутентификацией. В туннеле объекты TLV (тип-длина-значение) используются для передачи данных, связанных с аутентификацией, между одноранговым узлом EAP и сервером EAP.

В дополнение к одноранговой аутентификации TEAP позволяет одноранговому узлу запрашивать сертификат у сервера, отправляя запрос в формате PKCS # 10 , и сервер может предоставлять сертификат одноранговому узлу в формате [rfc: 2315 PKCS # 7]. Сервер также может распространять доверенные корневые сертификаты партнеру в формате [rfc: 2315 PKCS # 7]. Обе операции заключены в соответствующие TLV и выполняются безопасным способом в ранее установленном туннеле TLS.

Модуль идентификации подписчика EAP (EAP-SIM) [ править ]

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 не будет использоваться напрямую). Отсутствие взаимной аутентификации в GSM также было преодолено.

EAP-SIM описан в RFC 4186.

Соглашение об аутентификации EAP и ключах (EAP-AKA) [ править ]

Метод расширяемого протокола аутентификации для аутентификации и согласования ключей универсальной системы мобильной связи (UMTS) (EAP-AKA) - это механизм EAP для аутентификации и распределения ключей сеанса с использованием модуля идентификации абонента UMTS ( USIM ). EAP-AKA определен в RFC 4187.

Аутентификация EAP и ключи премьер (EAP-AKA ') [ править ]

EAP-AKA 'вариант EAP-AKA, определенный в RFC 5448, и используется для доступа не-3GPP к базовой сети 3GPP . Например, через EVDO , WiFi или WiMax .

Карта общего токена EAP (EAP-GTC) [ править ]

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 с зашифрованным обменом ключами , или EAP-EKE, является одним из немногих методов EAP, который обеспечивает безопасную взаимную аутентификацию с использованием коротких паролей и не требует сертификатов с открытым ключом . Это трехэтапный обмен, основанный на варианте Диффи-Хеллмана известного протокола EKE.

EAP-EKE указан в RFC 6124.

Nimble внеполосная аутентификация для EAP (EAP-NOOB) [ править ]

Nimble внеполосная аутентификация для EAP [27] (EAP-NOOB) - это предлагаемое (в процессе разработки, не RFC) универсальное решение начальной загрузки для устройств, у которых нет предварительно настроенных учетных данных для аутентификации и которые еще не зарегистрированы ни на одном сервере. . Это особенно полезно для гаджетов и игрушек Интернета вещей (IoT), которые не содержат информации о владельце, сети или сервере. Аутентификация для этого метода EAP основана на внеполосном (OOB) канале, поддерживаемом пользователем между сервером и одноранговым узлом. EAP-NOOB поддерживает множество типов OOB каналов , таких как QR - коды, теги NFC, аудио и т.д. , и в отличие от других методов EAP, безопасность протокола была проверена путем формального моделирования спецификации с ProVerif и MCRL2 инструментов. [28]

EAP-NOOB выполняет эфемерную эллиптическую кривую Диффи-Хеллмана (ECDHE) по внутриполосному каналу EAP. Затем пользователь подтверждает этот обмен, передавая сообщение OOB. Пользователи могут передавать OOB-сообщение от однорангового узла на сервер, например, если устройство представляет собой смарт-телевизор, который может отображать QR-код. В качестве альтернативы пользователи могут передавать сообщение OOB от сервера к партнеру, когда, например, загружаемое устройство представляет собой камеру, которая может считывать только QR-код.

Инкапсуляция [ править ]

EAP не является проводным протоколом; вместо этого он определяет только форматы сообщений. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP в сообщениях этого протокола. [29] [30]

IEEE 802.1X [ править ]

Основная статья: IEEE 802.1X

Инкапсуляция EAP через IEEE 802 определена в IEEE 802.1X и известна как «EAP через LAN» или EAPOL. [31] [32] [33] EAPOL был первоначально разработан для Ethernet IEEE 802.3 в 802.1X-2001, но был уточнен, чтобы соответствовать другим технологиям IEEE 802 LAN, таким как беспроводная связь IEEE 802.11 и интерфейс распределенных данных по оптоволокну (ANSI X3T9.5 / X3T12 , принятый как ISO 9314) в 802.1X-2004. [34] Протокол EAPOL также был модифицирован для использования с IEEE 802.1AE (MACsec) и IEEE 802.1AR ( исходная идентификация устройства, IDevID) в 802.1X-2010. [35]

Когда EAP запускается устройством сервера доступа к сети (NAS) с поддержкой 802.1X, например точкой беспроводного доступа (WAP) IEEE 802.11i-2004 , современные методы EAP могут обеспечить безопасный механизм аутентификации и согласовать безопасный закрытый ключ (попарно Мастер-ключ, PMK) между клиентом и NAS, который затем может использоваться для сеанса беспроводного шифрования с использованием шифрования TKIP или CCMP (на основе AES ).

PEAP [ править ]

Основная статья: Защищенный расширяемый протокол аутентификации

Протокол защищенной расширенной аутентификации , также известный как защищенный EAP или просто PEAP, представляет собой протокол, который инкапсулирует EAP в потенциально зашифрованный и аутентифицированный туннель безопасности транспортного уровня (TLS) . [36] [37] [38] Целью было исправить недостатки в EAP; EAP предполагал наличие защищенного канала связи, например, обеспечиваемого физической безопасностью, поэтому средства для защиты разговора EAP не были предоставлены. [39]

Протокол 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 , [40], а PEAPv2 был определен в версиях, начинающихся с draft-josefsson-pppext-eap -tls-eap-06 . [41]

Протокол определяет только объединение нескольких механизмов EAP, а не какой-либо конкретный метод. [37] [42] Использование EAP-MSCHAPv2 и EAP-GTC метода наиболее часто поддерживаются. [ необходима цитата ]

РАДИУС и диаметр [ править ]

Основные статьи: RADIUS и Диаметр (протокол)

Оба RADIUS и Diameter протоколы AAA могут инкапсулировать сообщения EAP. Они часто используются устройствами сервера доступа к сети (NAS) для пересылки пакетов EAP между конечными точками IEEE 802.1X и серверами AAA для облегчения работы с IEEE 802.1X.

ПАНА [ править ]

Основная статья: Протокол для проведения аутентификации для доступа к сети

Протокол Проведение проверки подлинности для доступа к сети (PANA) представляет собой IP-протокол , основанный , что позволяет устройству аутентифицировать себя с сетью , чтобы быть предоставлен доступ. PANA не будет определять какие-либо новые протоколы аутентификации, распределения ключей, согласования ключей или деривации ключей; для этих целей будет использоваться EAP, а PANA будет нести полезную нагрузку EAP. PANA позволяет динамический выбор поставщика услуг, поддерживает различные методы аутентификации, подходит для пользователей в роуминге и не зависит от механизмов канального уровня.

PPP [ править ]

Основная статья: Протокол точка-точка

Первоначально EAP был расширением аутентификации для протокола точка-точка (PPP). PPP поддерживает EAP с тех пор, как EAP был создан как альтернатива протоколу аутентификации с вызовом и рукопожатием (CHAP) и протоколу аутентификации пароля (PAP), которые в конечном итоге были включены в EAP. Расширение EAP для PPP было впервые определено в RFC 2284, теперь оно устарело в RFC 3748.

См. Также [ править ]

  • Протокол аутентификации
  • Передача ключей
  • ITU-T X.1035

Ссылки [ править ]

  1. ^ a b RFC 3748, § 1
  2. ↑ Джордж Оу (11 января 2007 г.). «Полное руководство по безопасности беспроводной сети: введение в аутентификацию LEAP» . TechRepublic . Проверено 17 февраля 2008 .
  3. ↑ Дэн Джонс (1 октября 2003 г.). «Посмотрите, прежде чем прыгнуть» . Без струн. Архивировано из оригинала 9 февраля 2008 года . Проверено 17 февраля 2008 .
  4. ^ «Понимание обновленных стандартов WPA и WPA2» . techrepublic.com . Проверено 17 февраля 2008 .
  5. ^ a b Берд, Кристофер (5 мая 2010 г.). «Open Secure Wireless» (PDF) . Архивировано из оригинального (PDF) 12 декабря 2013 года . Проверено 14 августа 2013 .
  6. ^ a b RFC 5216: Протокол аутентификации EAP-TLS , Инженерная группа Интернета , март 2008 г. Сообщение certificate_request включается, когда сервер желает, чтобы одноранговый узел аутентифицировал себя с помощью открытого ключа. Хотя серверу EAP СЛЕДУЕТ требовать аутентификацию однорангового узла, это не обязательно, поскольку существуют обстоятельства, при которых аутентификация однорангового узла не потребуется (например, экстренные службы, как описано в [UNAUTH]), или когда одноранговый узел будет аутентифицироваться с помощью других средств. .
  7. ^ "Добавить тип EAP поставщика UNAUTH-TLS" . hostapd . Архивировано из оригинала на 2013-02-13 . Проверено 14 августа 2013 .
  8. ^ «HS 2.0R2: Добавить метод однорангового узла EAP-TLS только для сервера WFA» . hostapd . Архивировано из оригинала на 2014-09-30 . Проверено 6 мая 2014 .
  9. ^ "HS 2.0R2: Добавить метод сервера EAP-TLS только для сервера WFA" . hostapd . Архивировано из оригинала на 2014-09-30 . Проверено 6 мая 2014 .
  10. ↑ Берд, Кристофер (1 ноября 2011 г.). «Откройте Secure Wireless 2.0» . Архивировано из оригинального 26 ноября 2013 года . Проверено 14 августа 2013 .
  11. ^ Рэнд Моримото; Кентон Гардинье; Майкл Ноэль; Джо Кока (2003). Microsoft Exchange Server 2003 Unleashed . Sams. п. 244. ISBN 978-0-672-32581-6.
  12. ^ «Альтернативные схемы шифрования: устранение недостатков статического WEP» . Ars Technica . Проверено 17 февраля 2008 .
  13. ^ "922574" , База знаний , Microsoft
  14. ^ «Протокол аутентификации EAP-POTP» . Juniper.net . Проверено 17 апреля 2014 .
  15. ^ Модуль FreeRADIUS EAP rlm_eap_pwd
  16. ^ Добавлена ​​поддержка EAP-PWD согласно RFC 5931
  17. ^ Безопасная аутентификация только с паролем
  18. ^ Настройки расширяемого протокола аутентификации (EAP) для доступа к сети
  19. ^ «Поддержка 802.1x / EAP TTLS? - Центральные форумы Windows Phone» . Forums.wpcentral.com . Проверено 17 апреля 2014 .
  20. ^ «Корпоративная аутентификация Wi-Fi (EAP)» . Microsoft.com . Проверено 23 апреля 2014 .
  21. ^ Интернет-проект TTLSv1
  22. ^ «Полное руководство по безопасности беспроводной сети: учебник по аутентификации Cisco EAP-FAST» . techrepublic.com. Архивировано из оригинала на 2008-03-24 . Проверено 17 февраля 2008 .
  23. ^ «EAP-FAST> Протоколы аутентификации EAP для WLAN» . Ciscopress.com . Проверено 17 апреля 2014 .
  24. ^ [1] Архивировано 10 февраля 2009 года в Wayback Machine.
  25. ^ Как мне установить CISCO EAP-FAST на свой компьютер?
  26. ^ EAPHost в Windows
  27. ^ Аура, Туомас; Сетхи, Мохит (21.07.2020). «Быстрая внеполосная аутентификация для проекта EAP (EAP-NOOB)» . IETF Trust.
  28. ^ Модель EAP-NOOB на GitHub
  29. ^ «HTTPS, безопасный HTTPS». Ссылка Springer. SpringerReference . Springer-Verlag. 2011. DOI : 10.1007 / springerreference_292 .
  30. ^ Plumb, Мишель, CAPPS: сеть HTTPS , OCLC 944514826 
  31. ^ RFC 3748, § 3.3
  32. ^ RFC 3748, § 7.12
  33. ^ IEEE 802.1X-2001, § 7
  34. ^ IEEE 802.1X-2004, § 3.2.2
  35. ^ IEEE 802.1X-2010, § 5
  36. ^ Microsoft PEAP версии 0, draft-kamath-pppext-peapv0-00 , §1.1
  37. ^ a b Защищенный протокол EAP (PEAP) версии 2, draft-josefsson-pppext-eap-tls-eap-10 , аннотация
  38. ^ Защищенный протокол EAP (PEAP) версии 2, draft-josefsson-pppext-eap-tls-eap-10 , §1
  39. ^ Защищенный протокол EAP (PEAP) версии 2, draft-josefsson-pppext-eap-tls-eap-07 , §1
  40. ^ Защищенный протокол EAP (PEAP), draft-josefsson-pppext-eap-tls-eap-05 , §2.3
  41. ^ Защищенный протокол EAP (PEAP), draft-josefsson-pppext-eap-tls-eap-06 , §2.3
  42. ^ Защищенный протокол EAP (PEAP) версии 2, draft-josefsson-pppext-eap-tls-eap-10 , §2

Дальнейшее чтение [ править ]

  • «AAA и сетевая безопасность для мобильного доступа. RADIUS, DIAMETER, EAP, PKI и мобильность IP». М Нахджири. John Wiley and Sons, Ltd.

Внешние ссылки [ править ]

  • RFC 3748: Extensible Authentication Protocol (EAP) (июнь 2004 г.)
  • RFC 5247: Структура управления ключами Extensible Authentication Protocol (EAP) (август 2008 г.)
  • Настройте RADIUS для безопасной беспроводной сети 802.1x
  • Как самостоятельно подписать сервер RADIUS для безопасной аутентификации PEAP или EAP-TTLS
  • Расширяемый протокол аутентификации в Microsoft TechNet
  • EAPHost в Windows Vista и Windows Server 2008
  • ПРОВОД1x
  • «Рабочая группа по обновлению метода IETF EAP (emu)»
  • [2]