✖


Jump to content

Расширяемый протокол аутентификации

(Перенаправлено с EAP-TTLS )

Расширяемый протокол аутентификации ( EAP ) — это платформа аутентификации, часто используемая в сети и подключениях к Интернету. Это определено в RFC   3748 , который сделал RFC   2284 устарел и обновлен РФК   5247 . EAP — это платформа аутентификации, обеспечивающая транспортировку и использование материалов и параметров, созданных методами EAP. Существует множество методов, определенных в RFC, а также существует ряд методов, специфичных для конкретных поставщиков, и новых предложений. EAP не является проводным протоколом; вместо этого он определяет только информацию из интерфейса и форматов. Каждый протокол, использующий EAP, определяет способ инкапсуляции сообщений EAP пользователя в сообщения этого протокола.

EAP широко используется. Например, в IEEE 802.11 (Wi-Fi) стандарты 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, используемым при аутентификации в беспроводной локальной сети, описаны в разделе РФК   4017 . Список типов и кодов пакетов, используемых в EAP, доступен в реестре IANA EAP. [ 2 ]

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

Облегченный расширяемый протокол аутентификации (LEAP)

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

Метод облегченного расширяемого протокола аутентификации (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 (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 и мобильной операционной системе Apple iOS.

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

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

EAP-MD5

[ редактировать ]

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

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

[ редактировать ]

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

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

Предварительный общий ключ 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). Это во FreeRADIUS [ 16 ] и радиатор [ 17 ] RADIUS-серверы, и он находится в hostapd и wpa_supplicant. [ 18 ]

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

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

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

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

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

EAP Интернет-обмен ключами версии 2 (EAP-IKEv2)

[ редактировать ]

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 через безопасное туннелирование (EAP-FAST)

[ редактировать ]

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

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

Фаза Функция Описание Цель
0 Внутриполосная подготовка — предоставьте партнеру общий секрет для использования в безопасном разговоре на этапе 1. Использует аутентифицированный протокол Диффи-Хеллмана (ADHP). Эта фаза не зависит от других фаз; следовательно, в будущем можно использовать любую другую схему (внутриполосную или внеполосную). Устраните необходимость в клиенте устанавливать главный секрет каждый раз, когда клиенту требуется доступ к сети.
1 Устройство туннеля Аутентифицируется с использованием PAC и устанавливает туннельный ключ. Создание ключа для обеспечения конфиденциальности и целостности во время процесса аутентификации на этапе 2.
2 Аутентификация Аутентифицирует партнера Множественные туннелированные безопасные механизмы аутентификации (обмен учетными данными)

Когда включена автоматическая подготовка PAC, EAP-FAST имеет уязвимость, позволяющую злоумышленнику перехватить PAC и использовать его для компрометации учетных данных пользователя. Эта уязвимость устраняется путем ручной подготовки PAC или использованием сертификатов сервера на этапе подготовки PAC.

Стоит отметить, что PAC-файл выдается индивидуально для каждого пользователя. Это требование в RFC   4851 раздел 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 ]

Туннельный расширяемый протокол аутентификации (TEAP)

[ редактировать ]

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

Помимо одноранговой аутентификации, TEAP позволяет одноранговому узлу запрашивать у сервера сертификат, отправляя запрос в PKCS#10 формате . После получения запроса на сертификат и аутентификации узла сервер может предоставить сертификат узлу в формате PKCS#7 ( RFC   2325 ). Сервер также может распространять доверенные корневые сертификаты одноранговому узлу в формате PKCS#7 ( RFC   2325 ). Обе операции заключены в соответствующие TLV и безопасно выполняются в уже установленном туннеле TLS.

Модуль идентификации абонента EAP (EAP-SIM)

[ редактировать ]

EAP Модуль идентификации абонента (EAP-SIM) используется для аутентификации и распределения сеансовых ключей с использованием модуля идентификации абонента (SIM) из Глобальной системы мобильной связи ( GSM ).

Сотовые сети GSM используют карту модуля идентификации абонента для аутентификации пользователя. EAP-SIM использует алгоритм аутентификации SIM между клиентом и сервером аутентификации, авторизации и учета (AAA), обеспечивая взаимную аутентификацию между клиентом и сетью.

В EAP-SIM связь между SIM-картой и центром аутентификации (AuC) заменяет необходимость заранее установленного пароля между клиентом и сервером AAA.

Алгоритмы A3/A8 запускаются несколько раз с разными 128-битными задачами, поэтому будет больше 64-битных Kc-ов, которые будут комбинироваться/смешиваться для создания более сильных ключей (Kc-s не будет использоваться напрямую). Также было преодолено отсутствие взаимной аутентификации в GSM.

EAP-SIM описан в РФК   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, или EAP-GTC, — это метод EAP, созданный Cisco в качестве альтернативы PEAPv0/EAP-MSCHAPv2 и определенный в RFC   2284 и РФК   3748 . EAP-GTC передает текстовый запрос от сервера аутентификации и ответ, генерируемый токеном безопасности . Механизм аутентификации PEAP-GTC позволяет выполнять общую аутентификацию для ряда баз данных, таких как Novell Directory Service (NDS) и облегченный протокол доступа к каталогам (LDAP), а также использовать одноразовый пароль .

Обмен зашифрованными ключами EAP (EAP-EKE)

[ редактировать ]

EAP с обменом зашифрованными ключами , или EAP-EKE, — один из немногих методов EAP, обеспечивающих безопасную взаимную аутентификацию с использованием коротких паролей и без необходимости использования сертификатов открытых ключей . Это трехраундовый обмен, основанный на варианте Диффи-Хеллмана известного протокола EKE.

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

Удобная внеполосная аутентификация для EAP (EAP-NOOB)

[ редактировать ]

Удобная внеполосная аутентификация для 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 ]

ИЭЭЭ 802.1Х

[ редактировать ]
Основная статья: IEEE 802.1X

Инкапсуляция EAP через IEEE 802 определена в IEEE 802.1X и известна как «EAP через локальные сети» или EAPOL. [ 32 ] [ 33 ] [ 34 ] EAPOL изначально был разработан для IEEE 802.3 Ethernet в 802.1X-2001, но был уточнен для соответствия другим технологиям локальных сетей IEEE 802, таким как беспроводная связь 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, таким как точка беспроводного доступа (WAP) IEEE 802.11i-2004 , современные методы EAP могут обеспечить безопасный механизм аутентификации и согласовать безопасный закрытый ключ (парный Главный ключ, PMK) между клиентом и NAS, который затем можно использовать для сеанса беспроводного шифрования с использованием шифрования TKIP или CCMP (на основе AES ).

ПЭАП

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

Защищенный расширяемый протокол аутентификации , также известный как Protected 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. Они часто используются устройствами сервера доступа к сети (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 , ныне устаревший. РФК   3748 .

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б "Введение" . Расширяемый протокол аутентификации (EAP) . сек. 1. дои : 10.17487/RFC3748 . РФК 3748 .
  2. ^ «Реестр расширяемого протокола аутентификации (EAP)» . www.iana.org . Проверено 1 июня 2021 г.
  3. ^ Джордж Оу (11 января 2007 г.). «Полное руководство по безопасности беспроводной сети: введение в аутентификацию LEAP» . Техреспублика . Проверено 17 февраля 2008 г.
  4. ^ Дэн Джонс (1 октября 2003 г.). «Посмотри, прежде чем прыгнуть» . Без струн. Архивировано из оригинала 9 февраля 2008 года . Проверено 17 февраля 2008 г.
  5. ^ «Понимание обновленных стандартов WPA и WPA2» . techrepublic.com . Проверено 17 февраля 2008 г.
  6. ^ Перейти обратно: а б Берд, Кристофер (5 мая 2010 г.). «Открытая безопасная беспроводная связь» (PDF) . Архивировано из оригинала (PDF) 12 декабря 2013 года . Проверено 14 августа 2013 г.
  7. ^ Перейти обратно: а б Протокол аутентификации EAP-TLS . Март 2008 г. doi : 10.17487/RFC5216 . РФК 5216 . Сообщение certificate_request включается, когда сервер желает, чтобы партнер аутентифицировал себя с помощью открытого ключа. Хотя сервер EAP ДОЛЖЕН требовать аутентификацию однорангового узла, это не является обязательным, поскольку существуют обстоятельства, при которых аутентификация однорангового узла не потребуется (например, службы экстренной помощи, как описано в [UNAUTH]) или когда одноранговый узел будет аутентифицироваться с помощью каких-либо других средств. .
  8. ^ «Добавить тип EAP, специфичный для поставщика UNAUTH-TLS» . хостапд . Архивировано из оригинала 13 февраля 2013 г. Проверено 14 августа 2013 г.
  9. ^ «HS 2.0R2: добавить одноранговый метод EAP-TLS только для сервера WFA» . хостапд . Архивировано из оригинала 30 сентября 2014 г. Проверено 6 мая 2014 г.
  10. ^ «HS 2.0R2: добавить метод сервера EAP-TLS только для сервера WFA» . хостапд . Архивировано из оригинала 30 сентября 2014 г. Проверено 6 мая 2014 г.
  11. ^ Берд, Кристофер (1 ноября 2011 г.). «Открытая безопасная беспроводная связь 2.0» . Архивировано из оригинала 26 ноября 2013 года . Проверено 14 августа 2013 г.
  12. ^ Рэнд Моримото; Кентон Гардинье; Майкл Ноэль; Джо Кока (2003). Выпуск Microsoft Exchange Server 2003 . Сэмс. п. 244. ИСБН  978-0-672-32581-6 .
  13. ^ «Альтернативные схемы шифрования: устранение недостатков статического WEP» . Арс Техника . Проверено 17 февраля 2008 г.
  14. ^ «922574» , База знаний , Microsoft
  15. ^ «Протокол аутентификации EAP-POTP» . Джунипер.нет . Проверено 17 апреля 2014 г.
  16. ^ Модуль EAP FreeRADIUS rlm_eap_pwd
  17. ^ МакКоли, Майк. «Добавлена ​​поддержка EAP-PWD согласно RFC 5931» . радиатор-анонс (список рассылки).
  18. ^ Безопасная аутентификация только с паролем.
  19. ^ Настройки расширяемого протокола аутентификации (EAP) для доступа к сети
  20. ^ «Поддержка 802.1x/EAP TTLS? – Центральные форумы Windows Phone» . Forums.wpcentral.com . Проверено 17 апреля 2014 г.
  21. ^ «Корпоративная проверка подлинности Wi-Fi (EAP)» . Microsoft.com . Проверено 23 апреля 2014 г.
  22. ^ EAP-туннельный протокол аутентификации TLS версии 1 (EAP-TTLSv1) . Идентификатор черновика-funk-eap-ttls-v1-01.
  23. ^ «Полное руководство по безопасности беспроводной сети: введение в систему аутентификации Cisco EAP-FAST» . techrepublic.com. Архивировано из оригинала 24 марта 2008 г. Проверено 17 февраля 2008 г.
  24. ^ «EAP-FAST > Протоколы аутентификации EAP для сетей WLAN» . Ciscopress.com . Проверено 17 апреля 2014 г.
  25. ^ «Руководство администратора EAP-FAST для Windows Vista» . Архивировано из оригинала 10 февраля 2009 года.
  26. ^ Как установить CISCO EAP-FAST на свой компьютер?
  27. ^ EAPHost в Windows
  28. ^ Аура, Туомас; Сетхи, Мохит; Пелтонен, А. (декабрь 2021 г.). Шустрая внеполосная аутентификация для EAP (EAP-NOOB) . дои : 10.17487/RFC9140 . РФК 9140 .
  29. ^ Модель EAP-NOOB на GitHub
  30. ^ Педерсен, Торбен (2005). «HTTPS, безопасный HTTPS». Энциклопедия криптографии и безопасности . стр. 268–269. дои : 10.1007/0-387-23483-7_189 . ISBN  978-0-387-23473-1 .
  31. ^ Пламб, Мишель, CAPPS: сеть HTTPS , OCLC   944514826
  32. ^ «Использование EAP в IEEE 802» . Расширяемый протокол аутентификации (EAP) . сек. 3.3. дои : 10.17487/RFC3748 . РФК 3748 .
  33. ^ «Связной уровень» . Расширяемый протокол аутентификации (EAP) . сек. 7.12. дои : 10.17487/RFC3748 . РФК 3748 .
  34. ^ IEEE 802.1X-2001, § 7.
  35. ^ IEEE 802.1X-2004, § 3.2.2.
  36. ^ IEEE 802.1X-2010, § 5.
  37. ^ «Инкапсуляция EAP» . PEAP версии 0 от Microsoft (реализация в Windows XP SP1) . сек. 1.1. Идентификатор черновика-kamath-pppext-peapv0-00.
  38. ^ Перейти обратно: а б Защищенный протокол EAP (PEAP), версия 2 . Абстрактный. Идентификатор проекта-josefsson-pppext-eap-tls-eap-10.
  39. ^ "Введение" . Защищенный протокол EAP (PEAP), версия 2 . сек. 1. Идентификатор черновика-josefsson-pppext-eap-tls-eap-10.
  40. ^ "Введение" . Защищенный протокол EAP (PEAP), версия 2 . сек. 1. Идентификатор Draft-josefsson-pppext-eap-tls-eap-07.
  41. ^ Защищенный протокол EAP (PEAP) . сек. 2.3. Идентификатор проекта-josefsson-pppext-eap-tls-eap-05.
  42. ^ «Согласование версии» . Защищенный протокол EAP (PEAP) . сек. 2.3. Идентификатор черновика-josefsson-pppext-eap-tls-eap-06.
  43. ^ «Обзор протокола» . Защищенный протокол EAP (PEAP), версия 2 . п. 11. Идентификатор проекта-josefsson-pppext-eap-tls-eap-10.

Дальнейшее чтение

[ редактировать ]
  • «AAA и сетевая безопасность для мобильного доступа. RADIUS, DIAMETER, EAP, PKI и IP-мобильность». М Нахджири. Джон Уайли и сыновья, Ltd.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Extensible_Authentication_Protocol&oldid=1220628330#EAP-TTLS"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 3343df5c5f01254883e40677dbe8a16f__1713989880
URL1:https://arc.ask3.ru/arc/aa/33/6f/3343df5c5f01254883e40677dbe8a16f.html
Заголовок, (Title) документа по адресу, URL1:
Extensible Authentication Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)