РАДИУС - RADIUS

Служба удаленной аутентификации пользователей с телефонным подключением ( RADIUS ) - это сетевой протокол, который обеспечивает централизованное управление аутентификацией, авторизацией и учетом ( AAA ) для пользователей, которые подключаются к сетевой службе и используют ее. RADIUS был разработан Livingston Enterprises в 1991 году как протокол аутентификации и учета сервера доступа. Позже он был внесен в стандарты IEEE 802 и IETF .

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

Компоненты протокола

RADIUS - это протокол 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) Access Reject, 2) Access Challenge или 3) Access Accept.

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

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

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

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

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

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

Бухгалтерия

Поток учета RADIUS

Бухгалтерский учет описан в RFC 2866.

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

Периодически записи промежуточного обновления (пакет запроса учета RADIUS, содержащий атрибут 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 \ username@anotherdomain.com может быть действительным именем пользователя с двумя областями.

Хотя области часто напоминают домены, важно отметить, что области на самом деле представляют собой произвольный текст и не обязательно должны содержать настоящие доменные имена. Форматы областей стандартизированы в 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 передается через UDP / IP на порты 1812 и 1813.

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

Назначенные коды RADIUS (десятичные) включают следующее:

Код Назначение
1 Доступ-Запрос
2 Доступ-Принять
3 Доступ-отклонить
4 Бухгалтерия-Запрос
5 Бухгалтерия-Ответ
11 Доступ-вызов
12 Статус-сервер (экспериментальный)
13 Статус-Клиент (экспериментальный)
40 Disconnect-Request
41 год Отключить-ACK
42 Отключить-НАК
43 год CoA-Request
44 год CoA-ACK
45 CoA-NAK
255 Зарезервированный

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

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

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

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

Макет RADIUS AVP

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

Атрибуты, зависящие от поставщика

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

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

Протокол RADIUS передает запутанные пароли с использованием общего секрета и алгоритма хеширования MD5 . Поскольку эта конкретная реализация обеспечивает только слабую защиту учетных данных пользователя, следует использовать дополнительную защиту, такую ​​как туннели IPsec или физически защищенные сети центров обработки данных, для дальнейшей защиты трафика RADIUS между устройством NAS и сервером RADIUS. Кроме того, учетные данные пользователя являются единственной частью, защищенной самим 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 пар атрибут-значение с возможностью для поставщиков настраивать свои собственные пары.

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

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

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

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

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

RFC Заголовок Дата публикации Связанная статья Связанные RFC Примечания
RFC 2058 Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) Январь 1997 г. РАДИУС Устарело в соответствии с RFC 2138
RFC 2059 Учет RADIUS Январь 1997 г. РАДИУС Устарело в соответствии с RFC 2139
RFC 2138 Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) Апрель 1997 г. РАДИУС Устарело в соответствии с RFC 2865
RFC 2139 Учет RADIUS Апрель 1997 г. РАДИУС Устарело RFC 2866
RFC 2548 Атрибуты RADIUS, зависящие от поставщика Microsoft Март 1999 г. РАДИУС
RFC 2607 Создание цепочки прокси и реализация политик в роуминге Июнь 1999 г.
RFC 2618 MIB клиента аутентификации RADIUS База управленческой информации Устарело в соответствии с RFC 4668
RFC 2619 MIB сервера аутентификации RADIUS База управленческой информации Устарело в соответствии с RFC 4669
RFC 2620 MIB клиента бухгалтерского учета RADIUS Июнь 1999 г. База управленческой информации Устарело в соответствии с RFC 4670
RFC 2621 MIB сервера учета RADIUS Июнь 1999 г. База управленческой информации Устарело в соответствии с RFC 4671
RFC 2809 Внедрение принудительного туннелирования L2TP через RADIUS Апрель 2000 г.
RFC 2865 Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) Июнь 2000 г. РАДИУС Обновлено RFC 2868, RFC 3575, RFC 5080 Этот стандарт описывает аутентификацию и авторизацию RADIUS между сервером доступа к сети (NAS) и общим сервером аутентификации RADIUS. Этот протокол также используется для передачи информации о конфигурации с сервера RADIUS на NAS.
RFC 2866 Учет RADIUS Июнь 2000 г. РАДИУС Этот стандарт описывает, как учетная информация переносится с NAS на общий учетный сервер RADIUS.
RFC 2867 Модификации учета RADIUS для поддержки туннельного протокола Июнь 2000 г. РАДИУС Обновления 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 г. Расширяемый протокол аутентификации Обновления RFC 2869
RFC 3580 Рекомендации по использованию IEEE 802.1X RADIUS Сентябрь 2003 г. 802.1X
RFC 4014 Подопция атрибутов RADIUS для параметра информации агента ретрансляции DHCP Февраль 2005 г.
RFC 4372 Платная идентификация пользователя Январь 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 для виртуальной локальной сети и приоритетной поддержки Сентябрь 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 Использование пакетов Status-Server в протоколе RADIUS Август 2010 г. Обновления RFC 2866
RFC 6158 Рекомендации по проектированию RADIUS Март 2011 г.
RFC 6218 Атрибуты RADIUS, определяемые поставщиком Cisco для доставки ключевого материала Апрель 2011 г.
RFC 6421 Требования к крипто-гибкости для службы удаленной аутентификации пользователей с телефонным подключением (RADIUS) Ноябрь 2011 г.
RFC 6613 РАДИУС через TCP Май 2012 г. Экспериментальный
RFC 6614 Шифрование транспортного уровня (TLS) для RADIUS Май 2012 г. Экспериментальный
RFC 6911 Атрибуты RADIUS для сетей доступа IPv6 апрель 2013 Трек стандартов
RFC 6929 Расширения протокола удаленной аутентификации пользователей с коммутируемым доступом (RADIUS) апрель 2013 Обновления RFC 2865, RFC 3575, RFC 6158
RFC 7360 Datagram Transport Layer Security (DTLS) как транспортный уровень для RADIUS Сентябрь 2014 г. Экспериментальный
RFC 7585 Динамическое обнаружение одноранговых узлов для RADIUS / TLS и RADIUS / DTLS на основе идентификатора доступа к сети (NAI) Октябрь 2015 Экспериментальный
RFC 8044 Типы данных в RADIUS Январь 2017 г. Обновления: 2865, 3162, 4072, 6158, 6572, 7268
RFC 8559 Прокси динамической авторизации в протоколе RADIUS Апрель 2019 Трек стандартов

Смотрите также

использованная литература

Библиография

внешние ссылки