RADIUS

редактировать
Протокол компьютерной сети

Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS ) является сетевым протокол, работающий на порту 1812, который обеспечивает централизованное управление аутентификацией, авторизацией и учетом (AAA или Triple A) для пользователей, которые подключаются и используют сетевой сервис. RADIUS был разработан Livingston Enterprises, Inc. в 1991 году как протокол аутентификации и учета сервера доступа, а затем внесен в стандарты Internet Engineering Task Force (IETF).

RADIUS - это протокол клиент / сервер, который работает на уровне приложений и может использовать TCP или UDP <123.>как транспорт. Серверы доступа к сети, шлюзы, управляющие доступом к сети, обычно содержат клиентский компонент RADIUS, который взаимодействует с сервером RADIUS. RADIUS часто является сервером для аутентификации 802.1X.

Сервер RADIUS обычно является фоновым процессом, работающим на сервер UNIX или Microsoft Windows.

Содержание
  • 1 Компоненты протокола
    • 1.1 Аутентификация и авторизация
    • 1.2 Учет
  • 2 Роуминг
    • 2.1 Области
    • 2.2 Прокси-операции
    • 2.3 Безопасность
  • 3 Структура пакета
    • 3.1 Пары значений атрибутов
  • 4 Атрибуты, зависящие от производителя
  • 5 Безопасность
  • 6 История
  • 7 Документация по стандартам
  • 8 См. Также
  • 9 Ссылки
  • 10 Библиография
  • 11 Внешние ссылки
Компоненты протокола

RADIUS - это протокол AAA, который управляет доступом к сети. AAA означает «Аутентификация, авторизация и учет». RADIUS использует два типа пакетов для управления полным процессом AAA: Access-Request, который управляет аутентификацией и авторизацией; и Accounting-Request, который управляет бухгалтерским учетом. Аутентификация и авторизация определены в RFC 2865, в то время как учет описан в RFC 2866.

Аутентификация и авторизация

Пользователь или машина отправляет запрос на сервер доступа к сети (NAS), чтобы получить доступ к определенному сетевому ресурсу с использованием учетных данных для доступа. Учетные данные передаются на устройство NAS по протоколу канального уровня, например, протокол точка-точка (PPP) в случае большого количества коммутируемых соединений или поставщиков DSL или размещены в защищенной веб-форме HTTPS.

В свою очередь, NAS отправляет сообщение запроса доступа RADIUS на сервер RADIUS, запрашивая авторизацию для предоставления доступа по протоколу RADIUS.

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

Сервер RADIUS проверяет правильность информации с помощью таких схем аутентификации, как PAP, CHAP или EAP. Подтверждение идентификации пользователя проверяется вместе с (необязательно) другой информацией, относящейся к запросу, такой как сетевой адрес или номер телефона пользователя, статус учетной записи и определенные привилегии доступа к сетевым службам. Исторически серверы RADIUS сверяли информацию пользователя с локально хранимой базой данных плоских файлов. Современные серверы RADIUS могут это делать или могут обращаться к внешним источникам - обычно к серверам SQL, Kerberos, LDAP или Active Directory - для проверки учетных данных пользователя.

Процесс аутентификации и авторизации RADIUS

Затем сервер RADIUS возвращает один из трех ответов NAS: 1) отказ в доступе, 2) запрос доступа или 3) принятие доступа.

Отклонение доступа
Пользователю безоговорочно запрещен доступ ко всем запрошенным сетевым ресурсам. Причины могут включать невозможность предоставить подтверждение личности или неизвестную или неактивную учетную запись пользователя.
Запрос доступа
Запрашивает дополнительную информацию от пользователя, такую ​​как дополнительный пароль, PIN-код, токен или карту. Access Challenge также используется в более сложных диалогах аутентификации, где между пользовательским компьютером и Radius Server устанавливается безопасный туннель таким образом, что учетные данные для доступа скрыты от NAS.
Access Accept
Пользователю предоставлен доступ. После аутентификации пользователя сервер RADIUS часто проверяет, имеет ли пользователь право использовать запрошенную сетевую службу. Данному пользователю может быть разрешено использовать, например, беспроводную сеть компании, но не ее службу VPN. Опять же, эта информация может храниться локально на сервере RADIUS или может быть найдена во внешнем источнике, таком как LDAP или Active Directory.

Каждый из этих трех ответов RADIUS может включать атрибут Reply-Message, который может указывать причину для отклонения, приглашение к вызову или приветственное сообщение для принятия. Текст в атрибуте может быть передан пользователю на веб-странице возврата.

Авторизация , атрибуты передаются NAS, определяя условия предоставления доступа. Например, следующие атрибуты авторизации могут быть включены в Access-Accept:

  • Конкретный IP-адрес, который должен быть назначен пользователю
  • Пул адресов, из которого IP-адрес пользователя должен быть выбран
  • Максимальный период времени, в течение которого пользователь может оставаться подключенным
  • Список доступа, приоритетная очередь или другие ограничения на доступ пользователя
  • L2TP параметры
  • Параметры VLAN
  • Параметры качества обслуживания (QoS)

Когда клиент настроен на использование RADIUS, любой пользователь клиента представляет клиенту информацию аутентификации. Это может быть настраиваемая подсказка входа в систему, где пользователь должен ввести свое имя пользователя и пароль. В качестве альтернативы пользователь может использовать протокол кадровой связи, такой как протокол точка-точка (PPP), который имеет пакеты аутентификации, которые несут эту информацию.

После того, как клиент получил такую ​​информацию, он может выбрать аутентификацию с использованием RADIUS. Для этого клиент создает «запрос доступа», содержащий такие атрибуты, как имя пользователя, пароль пользователя, идентификатор клиента и идентификатор порта, к которому пользователь обращается. Если пароль присутствует, он скрывается с помощью метода, основанного на алгоритме дайджеста сообщений RSA MD5.

Учет

Поток учета RADIUS

Учет описан в RFC 2866.

Когда доступ к сети предоставляется пользователю с помощью NAS, запуск учета ( пакет RADIUS Accounting Request, содержащий атрибут Acct-Status-Type со значением «start»), отправляется NAS на сервер RADIUS, чтобы сигнализировать о начале доступа пользователя к сети. «Начальные» записи обычно содержат идентификацию пользователя, сетевой адрес, точку подключения и уникальный идентификатор сеанса.

Периодически, записи промежуточного обновления (пакет RADIUS Accounting Request, содержащий атрибут Acct-Status-Type со значением «промежуточное обновление») может быть отправлено NAS на сервер RADIUS для обновления статуса активного сеанса. «Промежуточные» записи обычно содержат текущую продолжительность сеанса и информацию о текущем использовании данных.

Наконец, когда доступ пользователя к сети закрыт, NAS выдает последнюю запись об остановке учета (пакет RADIUS Accounting Request, содержащий атрибут Acct-Status-Type со значением «stop») серверу RADIUS, предоставление информации о конечном использовании с точки зрения времени, переданных пакетов, переданных данных, причины отключения и другой информации, связанной с доступом пользователя к сети.

Обычно клиент отправляет пакеты Accounting-Request до тех пор, пока он не получит подтверждение ответа Accounting-Response, используя некоторый интервал повтора.

Основная цель этих данных состоит в том, чтобы пользователю был выставлен счет соответственно; данные также обычно используются для статистических целей и для общего мониторинга сети.

Роуминг
Роуминг с использованием прокси-сервера RADIUS AAA.

RADIUS обычно используется для облегчения роуминга между интернет-провайдерами, например:

  • по компании, которые предоставляют единый глобальный набор учетных данных, которые можно использовать во многих общедоступных сетях;
  • независимыми, но сотрудничающими учреждениями, выдающими свои собственные учетные данные своим собственным пользователям, которые позволяют посетителю от одного к другому проходить аутентификацию своим домашним учреждением, например, в eduroam.

RADIUS облегчает это за счет использования областей, которые определяют, куда сервер RADIUS должен пересылать запросы AAA для обработки.

Области

Область обычно добавляется к имени пользователя и разделяется знаком '@', напоминая доменное имя адреса электронной почты. Это известно как постфиксное обозначение области. Другое распространенное использование - это префиксная нотация, которая включает добавление области к имени пользователя и использование '\' в качестве разделителя. Современные серверы RADIUS позволяют использовать любой символ в качестве разделителя области, хотя на практике обычно используются '@' и '\'.

Области также могут быть объединены с использованием как префиксной, так и постфиксной нотации, чтобы учесть сложные сценарии роуминга; например, somedomain.com \ [email#160;protected] может быть действительным именем пользователя с двумя областями.

Хотя области часто напоминают домены, важно отметить, что области на самом деле представляют собой произвольный текст и не обязательно должны содержать настоящие доменные имена. Форматы областей стандартизированы в RFC 4282, который определяет идентификатор доступа к сети (NAI) в форме 'user @ realm'. В этой спецификации требуется, чтобы часть «область» была доменным именем. Однако эта практика соблюдается не всегда. RFC 7542 заменил RFC 4282 в мае 2015 года.

Прокси-операции

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

Связь прокси возможна в RADIUS, а пакеты аутентификации / авторизации и учета обычно маршрутизируются между устройством NAS и домашним сервером через серию прокси-серверов. Некоторые из преимуществ использования цепочек прокси включают улучшения масштабируемости, реализацию политик и корректировку возможностей. Но в сценариях роуминга NAS, прокси и домашний сервер обычно могут управляться разными административными объектами. Следовательно, фактор доверия между прокси-серверами приобретает большее значение в таких междоменных приложениях. Кроме того, отсутствие сквозной безопасности в RADIUS повышает критичность доверия между задействованными прокси-серверами. Цепочки прокси описаны в RFC 2607.

Безопасность

Роуминг с RADIUS подвергает пользователей различным проблемам безопасности и конфиденциальности. В более общем плане некоторые партнеры по роумингу устанавливают безопасный туннель между серверами RADIUS, чтобы гарантировать, что учетные данные пользователей не могут быть перехвачены во время проксирования через Интернет. Это вызывает беспокойство, поскольку хэш MD5, встроенный в RADIUS, считается небезопасным.

Структура пакета
Формат пакетных данных RADIUS.

Формат пакетных данных RADIUS показан справа. Поля передаются слева направо, начиная с кода, идентификатора, длины, аутентификатора и атрибутов.

Коды RADIUS (десятичные) назначаются следующим образом:

CodeAssignment
1Access-Request
2Access-Accept
3Access-Reject
4Учет- Запрос
5Accounting-Response
11Access-Challenge
12Status-Server (экспериментальный)
13Status-Client (экспериментальный)
40Disconnect-Request
41Disconnect-ACK
42Disconnect-NAK
43CoA-Request
44CoA-ACK
45CoA-NAK
255Зарезервировано

Поле идентификатора помогает в сопоставлении запросов и ответов.

Поле длины указывает длину всего пакета RADIUS, включая поля кода, идентификатора, длины, аутентификатора и дополнительных атрибутов.

Аутентификатор используется для аутентификации ответа от сервера RADIUS и используется для шифрования паролей; его длина составляет 16 байт.

Пары значений атрибутов

Схема RADIUS AVP

Пары значений атрибутов RADIUS (AVP) переносят данные как в запросе, так и в ответе для транзакций аутентификации, авторизации и учета. Длина радиуса пакета используется для определения конца AVP.

Тип AVPНазначение
1Имя пользователя
2Пароль пользователя
3CHAP -Пароль
4IP-адрес NAS
5Порт NAS
6Service-Type
7Framed-Protocol
8Framed-IP-Address
9Framed-IP-Netmask
10Framed-Routing
11Filter-Id
12Framed-MTU
13Framed-Compression
14Login-IP-Host
15Login-Service
16Login-TCP-Port
18Reply-Message
19Callback-Number
20Callback-Id
22Framed-Route
23Framed- IPX-Network
24State
25Class
26Vendor-Specific
27Session-Timeout
28Idle-Timeout
29Termination-Action
30Called-Station-Id
31Calling-Station- Id
32NAS-Identifier
33Proxy-State
34Login-LAT-Service
35Login-LAT-Node
36Login-LAT-Group
37Framed-AppleTalk-Link
38Framed- AppleTalk-Network
39Framed-AppleTalk-Zone
40Acct-Status-Type
41Acct-Delay-Time
42Acct-Input-Octets
43Acct-Output-Octets
44Acct-Session- Id
45Acct-Authentic
46Acct-Session-Time
47Acct-Input-Packets
48Acct-Output-Packets
49Acct-Terminat e-Cause
50Acct-Multi-Session-Id
51Acct-Link-Count
52Acct-Input-Gigawords
53Acct-Output-Gigawords
55Event-Timestamp
56Egress-VLANID
57Ingress-Filters
58Egress-VLAN-Name
59User-Priority-Table
60CHAP -Challenge
61NAS-Port-Type
62Port-Limit
63Login-LAT -Port
64Tunnel-Type
65Tunnel-Medium-Type
66Tunnel-Client-Endpoint
67Tunnel-Server-Endpoint
68Acct-Tunnel-Connection
69Tunnel-Password
70ARAP -Password
71ARAP-Features
72ARAP-Zone-Access
73ARAP-Security
74ARAP-Security-Data
75Password-Retry
76Prompt
77Connect-Info
78Configuration -Token
79EAP-Message
80Message-Authenticator
81Tunnel-Private-Group-ID
82Tunnel-Assignment-ID
83Tunnel-Preference
84ARAP-Challenge-Response
85Acct -Interim-Interval
86Acct-Tunnel-Packets-Lost
87NAS-Port-Id
88Framed-Pool
89CUI
90Tunnel-Client-Auth-ID
91Tunnel-Server-Auth -ID
92Правило-фильтра NAS
94Информация об исходной линии
95IPv6-адрес NAS
96Framed-Interface-Id
97Framed-IPv6-Prefix
98Login-IPv6-Host
99Framed-IPv6-Route
100Framed-IPv6-Pool
101Атрибут причины ошибки
102EAP-Key-Name
103Digest-Response
104Digest-Realm
105Digest-Nonce
106Digest-Response-Auth
107Digest-Nextnonce
108Digest-Method
109Digest-URI
110Digest-Qop
111Digest-Algorithm
112Digest-Entity-Body-Hash
113Digest-CNonce
114Digest-Nonce-Count
115Digest- Имя пользователя
116Digest-Opaque
117Digest-Auth-Param
118Digest-AKA-Auts
119Digest-Domain
120Digest-Stale
121Digest-HA1
122SIP-AOR
123Делегированный префикс IPv6
124MIP6-Feature-Vector
125Префикс MIP6-Home-Link
126Имя оператора
127Информация о местоположении
128Данные о местоположении
129Основные правила политики местоположения
130Правила расширенной политики местоположения
131Location-Capable
132Requested-Location-Info
133Framed-Management-Protocol
134Management-Transport-Protection
135Management-Policy-Id
136Management-Privilege-Level
137PKM-SS-Cert
138PKM-CA-Cert
139PKM-Config-Settings
140PKM-Cryptosuite-List
141PKM- SAID
142PKM-SA-Descriptor
143PKM-Auth-Key
144DS-Lite-Tunnel-Name
145Идентификатор мобильного узла
146Выбор службы
147PMIP6-Home-LMA-IPv6-Address
148PMIP6-Visited-LMA-IPv6-Address
149PMIP6-Home-LMA-IPv4-Address
150PMIP6-Visited-LMA-IPv4 -Address
151PMIP6-Home-HN-Prefix
152PMIP6-Visited-HN-Prefix
153PMIP6-Home- ID интерфейса
154PMIP6- Идентификатор посещенного интерфейса
155PMIP6-Home-IPv4-HoA
156PMIP6-Visited-IPv4-HoA
157PMIP6 -Home-DHCP4-Server-Address
158PMIP6-Visited-DHCP4-Server-Address
159PMIP6-Home-DHCP6-Server-Address
160PMIP6-Visited-DHCP6-Server-Address
161PMIP6-Home-IPv4-Gateway
162PMIP6-Visited-IPv4-Gateway
163EAP-нижний уровень
164GSS-Acceptor-Service-Name
165GSS-Acceptor-Host-Name
166GSS-Acceptor-Service-Specifics
167GSS-Acceptor-Realm-Name
168Framed-IPv6-Address
169DNS-сервер-IPv6-адрес
170Маршрут-IPv6-информация
171Пул префиксов делегированного IPv6
172Stateful-IPv6-Address-Pool
173IPv6-6rd-Configuration
174Allowed-Called-Station-Id
175EAP-Peer-Id
176EAP-Server-Id
177Mobility-Domain-Id
178Тайм-аут преаутентификации
179Network-Id-Name
180EAPoL-Announcement
181WLAN-HESSID
182WLAN-Venue-Info
183WLAN-Venue-Language
184WLAN-Venue-Name
185Код-причины-WLAN
186WLAN-Pairwise-Cipher
187WLAN-Group-Cipher
188WLAN-AKM-Suite
189WLAN-Group- Mgmt-Cipher
190WLAN-RF-Band
Атрибуты, зависящие от производителя

RADIUS является расширяемым; многие производители оборудования и программного обеспечения RADIUS реализуют свои собственные варианты с использованием атрибутов, зависящих от поставщика (VSA). Microsoft опубликовала некоторые из своих VSA. Определения VSA от многих других компаний остаются собственными и / или специальными, тем не менее, многие словари VSA можно найти, загрузив исходный код реализаций RADIUS с открытым исходным кодом, например FreeRADIUS или openRADIUS.

Безопасность

Протокол RADIUS передает зашифрованные пароли с использованием общего секрета и алгоритма хеширования MD5. Поскольку эта конкретная реализация обеспечивает только слабую защиту учетных данных пользователя, для дальнейшей защиты трафика RADIUS между устройством NAS и RADIUS следует использовать дополнительную защиту, такую ​​как туннели IPsec или физически защищенные сети центров обработки данных. сервер. Кроме того, учетные данные пользователя являются единственной частью, защищенной самим RADIUS, однако другие специфические для пользователя атрибуты, такие как идентификаторы туннельных групп или членство в vlan, передаваемые через RADIUS, могут считаться конфиденциальными (полезными для злоумышленника) или частными (достаточными для идентификации индивидуального клиента). Протокол RadSec утверждает, что решает вышеупомянутые проблемы безопасности.

История

По мере того, как все больше клиентов коммутируемого доступа использовали NSFnet, запрос предложения был отправлен Merit Network в 1991 г., чтобы объединить свои различные проприетарные системы аутентификации, авторизации и учета. Среди первых респондентов была компания Livingston Enterprises, и ранняя версия RADIUS была написана после встречи. Ранний сервер RADIUS был установлен в операционной системе UNIX . Компания Livingston Enterprises была приобретена Lucent, и вместе с Merit были предприняты шаги для получения отраслевого признания RADIUS в качестве протокола. Обе компании предложили сервер RADIUS бесплатно. В 1997 году RADIUS был опубликован как RFC 2058 и RFC 2059, текущие версии - RFC 2865 и RFC 2866.

Исходный стандарт RADIUS указывал, что RADIUS является без сохранения состояния и должен работать по протоколу пользовательских дейтаграмм (UDP). Для аутентификации было предусмотрено, что RADIUS должен поддерживать протокол аутентификации паролей (PAP) и протокол аутентификации вызов-рукопожатие (CHAP) по протоколу точка-точка. Пароли скрываются путем взятия хэша MD5 пакета и общего секрета, а затем выполнения XOR этого хэша с паролем. Исходный RADIUS также предоставлял более 50 пар атрибутов или значений с возможностью для поставщиков настраивать свои собственные пары.

Выбор модели безопасности по этапам, а не сквозной -end encryption, означало, что если используются несколько прокси-серверов RADIUS, каждый сервер должен проверить, выполнить логику и передать все данные в запросе. Это предоставляет такие данные, как пароли и сертификаты, на каждом этапе. Серверы RADIUS также не имели возможности прекратить доступ к ресурсам после выдачи авторизации. Последующие стандарты, такие как RFC 3576 и его преемник RFC 5176, позволяли серверам RADIUS динамически изменять авторизацию пользователей или полностью отключать пользователя.

Сейчас существует несколько коммерческих серверов RADIUS с открытым исходным кодом. Возможности могут различаться, но большинство из них может искать пользователей в текстовых файлах, LDAP серверах, различных базах данных и т. Д. Учетные записи могут быть записаны в текстовые файлы, различные базы данных, пересылаться на внешние серверы и т.>SNMP часто используется для удаленного мониторинга и проверки активности сервера RADIUS. Прокси-серверы RADIUS используются для централизованного администрирования и могут на лету перезаписывать пакеты RADIUS по соображениям безопасности или для преобразования между диалектами поставщика.

Протокол Diameter был предназначен для замены RADIUS. Хотя оба являются протоколами аутентификации, авторизации и учета (AAA), с тех пор варианты использования этих двух протоколов разошлись. Диаметр в основном используется в пространстве 3G. RADIUS используется в другом месте. Одним из самых серьезных препятствий к замене RADIUS на Diameter является то, что переключает и точки доступа обычно реализуют RADIUS, но не Diameter. Diameter использует SCTP или TCP, тогда как RADIUS обычно использует UDP в качестве транспортного уровня. С 2012 года RADIUS также может использовать TCP в качестве транспортного уровня с TLS для безопасности.

Документация по стандартам

Протокол RADIUS в настоящее время определен в следующих документах IETF RFC.

RFCНазваниеДата публикацииСтатья по темеСвязанные RFCПримечания
RFC 2058 Служба удаленной аутентификации для пользователей с набором номера (RADIUS)январь 1997 г.RADIUSОтменено RFC 2138
RFC 2059 RADIUS AccountingЯнварь 1997 г.RADIUSОтменено в соответствии с RFC 2139
RFC 2138 Служба удаленной аутентификации пользователей с набором номера (RADIUS)апрель 1997 г.RADIUSОтменено RFC 2865
RFC 2139 RADIUS Accountingапрель 1997 г.RADIUSУстарело в соответствии с RFC 2866
RFC 2548 Атрибуты RADIUS, зависящие от поставщика MicrosoftМарт 1999 г.RADIUS
RFC 2607 Создание цепочки прокси и реализация политики в роумингеиюнь 1999 г.
RFC 2618 MIB клиента аутентификации RADIUSБаза информации управления Устарело в соответствии с RFC 4668
RFC 2619 MIB сервера аутентификации RADIUSБаза управляющей информации Устарела в соответствии с RFC 4669
RFC 2620 RAD MIB клиента учета IUSиюнь 1999 г.База управленческой информации Устарела в соответствии с RFC 4670
RFC 2621 MIB сервера учета RADIUSиюнь 1999 г.База управляющей информации Устарела в соответствии с RFC 4671
RFC 2809 Реализация L2TP принудительного туннелирования через RADIUSапрель 2000 г.
RFC 2865 Служба удаленной аутентификации для пользователей с набором номера (RADIUS)июнь 2000 г.RADIUSОбновлено в соответствии с RFC 2868, RFC 3575, RFC 5080 Этот стандарт описывает аутентификацию и авторизацию RADIUS между сервером доступа к сети (NAS) и общим сервером аутентификации RADIUS. Этот протокол также используется для передачи информации о конфигурации с сервера RADIUS на NAS.
RFC 2866 Учет RADIUSиюнь 2000 г.RADIUSЭтот стандарт описывает, как учетная информация переносится с NAS на общий учетный сервер RADIUS.
RFC 2867 Модификации учета RADIUS для поддержки туннельного протоколаиюнь 2000 г.RADIUSОбновления RFC 2866
RFC 2868 Атрибуты RADIUS для поддержки туннельного протоколаиюнь 2000 г.Обновления RFC 2865
RFC 2869 Расширения RADIUSиюнь 2000 г.Обновлено RFC 3579, RFC 5080
RFC 2882 Требования к серверам доступа к сети: расширенная практика RADIUSиюль 2000
RFC 3162 RADIUS и IPv6 Август 2001
RFC 3575 Соображения IANA для RADIUSИюль 2003 г.
RFC 3576 Расширения динамической авторизации для RADIUSИюль 2003 г.Устранено RFC 5176
RFC 3579 Поддержка RADIUS для EAPсентябрь 2003 г.Extensible Authentication Protocol Обновления RFC 2869
RFC 3580 IEEE 802.1X Рекомендации по использованию RADIUSсентябрь 2003 г.802.1X
RFC 4014 Подопция атрибутов RADIUS для параметра информации агента ретрансляции DHCPфевраль 2005 г.
RFC 43 72 Платная идентификация пользователяЯнварь 2006 г.
RFC 4590 Расширение RADIUS для дайджест-аутентификациииюль 2006 г.Отменено RFC 5090
RFC 4668 MIB клиента аутентификации RADIUS для IPv6август 2006 г.База управляющей информации
RFC 4669 MIB сервера аутентификации RADIUS для IPv6Август 2006 г.Управление информационная база
RFC 4670 MIB клиента учета RADIUS для IPv6август 2006 г.База данных управления
RFC 4671 MIB сервера учета RADIUS для IPv6Август 2006 г.База управленческой информации
RFC 4675 Атрибуты RADIUS для виртуальной LAN и приоритетной поддержкиСентябрь 2006 г.
RFC 4679 Атрибуты RADIUS, зависящие от поставщика DSL ForumСентябрь 2006 г.
RFC 4818 Атрибут делегированного IPv6-префикса RADIUSАпрель 2007 г.
RFC 4849 Атрибут правила фильтра RADIUSапрель 2007 г.
RFC 5080 Общие проблемы реализации RADIUS и предлагаемые исправлениядекабрь 2007 г.Обновления RFC 3579
RFC 5090 Расширение RADIUS для дайджест-аутентификацииФевраль 2008 г.
RFC 5176 Расширения динамической авторизации для RADIUSЯнварь 2008
RFC 5607 Авторизация RADIUS для управления NASиюль 2009 г.
RFC 5997 Использование пакетов сервера состояния в протоколе RADIUSавгуст 2010 г.Обновления RFC 2866
RFC 6158 Рекомендации по проектированию RADIUSмарт 2011 г.
RFC 6218 Атрибуты RADIUS, специфичные для поставщика Cisco, для доставки ключевого материалаапрель 2011
RFC 6421 Требования к крипто-гибкости для службы удаленной аутентификации пользователей с телефонным подключением (RADIUS)ноябрь 2011
RFC 6613 RADIUS через TCPмай 2012 г.экспериментальный
RFC 6614 шифрование TLS для RADIUSмай 2012 г.экспериментальный
RFC 6911 атрибуты RADIUS для доступа IPv6 СетиАпрель 2013 г.Отслеживание стандартов
RFC 6929 Служба удаленной аутентификации пользователей с телефонным подключением (RADI США) Protocol ExtensionsАпрель 2013 г.Обновления RFC 2865, RFC 3575, RFC 6158
RFC 7360 Транспортный уровень дейтаграмм Безопасность (DTLS) как транспортный уровень для RADIUSсентябрь 2014 г.Экспериментальный
RFC 7585 Динамическое обнаружение одноранговых узлов для RADIUS / TLS и RADIUS / DTLS на основе идентификатора доступа к сети (NAI)Октябрь 2015 г.Экспериментальные
RFC 8044 Типы данных в RADIUSЯнварь 2017 г.Обновления: 2865, 3162, 4072, 6158, 6572, 7268
См. Также
Ссылки
Библиография
Внешние ссылки
Последняя правка сделана 2021-06-03 04:12:06
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте