Служба удаленной аутентификации пользователей с телефонным подключением ( RADIUS ) — это сетевой протокол, который обеспечивает централизованное управление аутентификацией, авторизацией и учетом ( AAA ) для пользователей, которые подключаются и используют сетевую службу. RADIUS был разработан компанией Livingston Enterprises в 1991 году как протокол аутентификации и учета сервера доступа. Позже он был включен в стандарты IEEE 802 и IETF .
RADIUS — это протокол клиент/сервер , который работает на уровне приложений и может использовать TCP или UDP . Серверы доступа к сети , управляющие доступом к сети, обычно содержат клиентский компонент RADIUS, который взаимодействует с сервером RADIUS. [1] RADIUS часто используется в качестве серверной части для аутентификации 802.1X . [2] Сервер RADIUS обычно представляет собой фоновый процесс , работающий в UNIX или Microsoft Windows . [1]
RADIUS — это протокол AAA (аутентификация, авторизация и учет), который управляет доступом к сети. RADIUS использует два типа пакетов для управления полным процессом AAA: Access-Request, который управляет аутентификацией и авторизацией; и Accounting-Request, который управляет бухгалтерским учетом. Аутентификация и авторизация определены в RFC 2865, а учет описан в RFC 2866.
Пользователь или компьютер отправляет запрос на сервер доступа к сети (NAS) для получения доступа к определенному сетевому ресурсу, используя учетные данные доступа. Учетные данные передаются на устройство NAS через протокол канального уровня , например протокол «точка-точка» (PPP) в случае многих провайдеров коммутируемого доступа или DSL , или публикуются в защищенной веб-форме HTTPS .
В свою очередь, NAS отправляет сообщение запроса доступа RADIUS на сервер RADIUS, запрашивая авторизацию для предоставления доступа по протоколу RADIUS. [3]
Этот запрос включает учетные данные доступа, обычно в форме имени пользователя и пароля или сертификата безопасности, предоставленного пользователем. Кроме того, запрос может содержать другую информацию о пользователе, которую NAS знает, например его сетевой адрес или номер телефона, а также информацию о физической точке подключения пользователя к NAS.
Сервер RADIUS проверяет правильность информации, используя такие схемы аутентификации, как PAP , CHAP или EAP . Подтверждение личности пользователя проверяется вместе с, при необходимости, другой информацией, связанной с запросом, такой как сетевой адрес или номер телефона пользователя, состояние учетной записи и права доступа к конкретным сетевым услугам. Исторически сложилось так, что серверы RADIUS сверяли информацию пользователя с локально хранимой базой данных в виде плоских файлов. Современные серверы RADIUS могут это делать или могут обращаться к внешним источникам — обычно SQL , Kerberos , LDAP или серверам Active Directory — для проверки учетных данных пользователя.
Затем сервер RADIUS возвращает NAS один из трех ответов: 1) отказ в доступе, 2) запрос доступа или 3) принятие доступа.
Каждый из этих трех ответов RADIUS может включать атрибут ответного сообщения, который может указывать причину отклонения, запрос на вызов или приветственное сообщение для принятия. Текст в атрибуте может быть передан пользователю на возвращаемой веб-странице.
Атрибуты авторизации передаются в NAS, определяя условия предоставления доступа. Например, в Access-Accept могут быть включены следующие атрибуты авторизации:
Когда клиент настроен на использование RADIUS, любой пользователь клиента предоставляет клиенту информацию аутентификации. Это может быть настраиваемое приглашение для входа в систему, где пользователь должен ввести свое имя пользователя и пароль. В качестве альтернативы пользователь может использовать протокол формирования канала связи, такой как протокол «точка-точка» (PPP), который имеет пакеты аутентификации, которые несут эту информацию.
Как только клиент получит такую информацию, он может выбрать аутентификацию с использованием RADIUS. Для этого клиент создает «Запрос доступа», содержащий такие атрибуты, как имя пользователя, пароль пользователя, идентификатор клиента и идентификатор порта, к которому обращается пользователь. Если пароль присутствует, он скрывается с помощью метода, основанного на алгоритме дайджеста сообщений RSA MD5.
Учет описан в RFC 2866.
Когда NAS предоставляет пользователю доступ к сети , NAS отправляет на сервер RADIUS сигнал начала учета (пакет запроса учета RADIUS, содержащий атрибут Acct-Status-Type со значением «start»), чтобы сигнализировать о начале доступ пользователя к сети. «Начальные» записи обычно содержат идентификатор пользователя, сетевой адрес, точку подключения и уникальный идентификатор сеанса. [4]
Периодически записи промежуточного обновления (пакет запроса учета RADIUS, содержащий атрибут Acct-Status-Type со значением «interim-update») могут отправляться NAS на сервер RADIUS для обновления его состояния активного сеанса. «Промежуточные» записи обычно содержат текущую продолжительность сеанса и информацию о текущем использовании данных.
Наконец, когда доступ пользователя к сети закрыт, NAS выдает окончательную запись остановки учета (пакет запроса учета RADIUS, содержащий атрибут Acct-Status-Type со значением «stop») на сервер RADIUS, предоставляя информацию об окончательном использовании. с точки зрения времени, переданных пакетов, переданных данных, причины отключения и другой информации, связанной с доступом пользователя к сети.
Обычно клиент отправляет пакеты Accounting-Request до тех пор, пока не получит подтверждение Accounting-Response, используя некоторый интервал повтора.
Основная цель этих данных состоит в том, чтобы пользователю можно было выставить соответствующий счет ; данные также обычно используются в статистических целях и для общего мониторинга сети.
RADIUS обычно используется для облегчения роуминга между интернет-провайдерами , в том числе:
RADIUS облегчает это за счет использования областей , которые определяют, куда сервер RADIUS должен пересылать запросы AAA для обработки.
Область обычно добавляется к имени пользователя и ограничивается знаком «@», напоминающим доменное имя адреса электронной почты. Это известно как постфиксная нотация области. Другое распространенное использование — это префиксная запись, которая включает в себя добавление области к имени пользователя и использование «\» в качестве разделителя. Современные серверы RADIUS позволяют использовать любой символ в качестве разделителя области, хотя на практике обычно используются «@» и «\».
Области также можно объединять с использованием как префиксной, так и постфиксной нотации, чтобы обеспечить сложные сценарии роуминга; например, somedomain.com\[email protected] может быть допустимым именем пользователя с двумя областями.
Хотя области часто напоминают домены, важно отметить, что области на самом деле представляют собой произвольный текст и не обязательно должны содержать настоящие доменные имена. Форматы областей стандартизированы в RFC 4282, который определяет идентификатор доступа к сети (NAI) в форме «user@realm». В этой спецификации часть «область» должна быть доменным именем. Однако эта практика не всегда соблюдается. RFC 7542 [5] заменил RFC 4282 в мае 2015 года.
Когда сервер RADIUS получает запрос AAA на имя пользователя, содержащее область, сервер будет ссылаться на таблицу настроенных областей. Если область известна, сервер затем передаст запрос настроенному домашнему серверу для этого домена. Поведение прокси-сервера в отношении удаления области из запроса («зачистки») зависит от конфигурации большинства серверов. Кроме того, прокси-сервер можно настроить на добавление, удаление или перезапись запросов AAA при их повторном проксировании.
В RADIUS возможно объединение прокси-серверов, а пакеты аутентификации/авторизации и учета обычно маршрутизируются между устройством NAS и домашним сервером через ряд прокси-серверов. Некоторые из преимуществ использования цепочек прокси включают улучшение масштабируемости, реализацию политик и настройку возможностей. Но в сценариях роуминга NAS, прокси-серверы и домашний сервер обычно могут управляться разными административными объектами. Следовательно, фактор доверия среди прокси приобретает большее значение в таких междоменных приложениях. Кроме того, отсутствие сквозной безопасности в RADIUS повышает критичность доверия между участвующими прокси-серверами. Цепочки прокси описаны в RFC 2607.
Роуминг с использованием RADIUS подвергает пользователей различным проблемам безопасности и конфиденциальности. В более общем плане некоторые партнеры по роумингу устанавливают безопасный туннель между серверами RADIUS, чтобы гарантировать, что учетные данные пользователей не могут быть перехвачены во время прокси-сервера через Интернет. Это вызывает беспокойство, поскольку хэш MD5, встроенный в RADIUS, считается небезопасным. [6]
RADIUS передается через UDP/IP через порты 1812 и 1813. [7]
Формат пакетных данных RADIUS показан справа. Поля передаются слева направо, начиная с кода, идентификатора, длины, аутентификатора и атрибутов.
Назначенные коды RADIUS (десятичные) включают следующее: [8]
Поле «Идентификатор» помогает сопоставлять запросы и ответы.
Поле «Длина» указывает длину всего пакета RADIUS, включая поля «Код», «Идентификатор», «Длина», «Аутентификатор» и дополнительные поля «Атрибут».
Аутентификатор используется для аутентификации ответа от сервера RADIUS и используется для шифрования паролей; его длина составляет 16 байт.
Пары значений атрибутов RADIUS (AVP) переносят данные как в запросе, так и в ответе для транзакций аутентификации, авторизации и учета. Длина пакета радиуса используется для определения конца AVP.
RADIUS является расширяемым; многие поставщики аппаратного и программного обеспечения RADIUS реализуют свои собственные варианты, используя атрибуты, специфичные для поставщика (VSA). Microsoft опубликовала некоторые из своих VSA. [9] Определения VSA от многих других компаний остаются частными и/или специальными, тем не менее, многие словари VSA можно найти, загрузив исходный код реализаций RADIUS с открытым исходным кодом, например FreeRADIUS .
RFC 2865 обеспечивает базовую кодировку, которой должен следовать атрибут, в пределах значения описания поля «Длина поставщика», которое не является явным, но должно пониматься в контексте значения атрибута. Длина поставщика представляет собой длину значения в байтах плюс 2 байта, эти два байта учитываются для типа поставщика и длины поставщика. Количество октетов для кодирования типа поставщика и длины поставщика зависит от реализации, и некоторые поставщики используют 2 октета для типа, длины или того и другого. Конкретные значения определяются с помощью ключевого слова format=2,2 в словаре freeradius.
Атрибуты, специфичные для поставщика, соответствуют этой кодировке, которая используется реализацией freeradius с использованием словарей, специфичных для поставщика.
Протокол RADIUS передает запутанные пароли, используя общий секрет и алгоритм хеширования MD5 . Поскольку эта конкретная реализация обеспечивает лишь слабую защиту учетных данных пользователя, [10] для дальнейшей защиты трафика RADIUS между устройством NAS и сервером RADIUS следует использовать дополнительную защиту, например туннели IPsec или физически защищенные сети центров обработки данных. Кроме того, учетные данные пользователя являются единственной частью, защищаемой самим RADIUS, однако другие специфичные для пользователя атрибуты, такие как идентификаторы туннельных групп или членство в VLAN, передаваемые через RADIUS, могут считаться конфиденциальными (полезными для злоумышленника) или частными (достаточными для идентификации индивидуальный клиент) информация, а также. [ нужна цитация ] Протокол RadSec утверждает, что решает вышеупомянутые проблемы безопасности.
Поскольку все больше клиентов коммутируемого доступа стали использовать NSFNET, в 1991 году Merit Network разослала запрос на предложение по консолидации своих различных собственных систем аутентификации, авторизации и учета. Среди первых респондентов была компания Livingston Enterprises, и ранняя версия RADIUS была написана после встречи. Ранний сервер RADIUS был установлен в операционной системе UNIX . Компания Livingston Enterprises была приобретена Lucent , и вместе с Merit были предприняты шаги по обеспечению признания RADIUS в качестве протокола промышленностью. Обе компании предложили сервер RADIUS бесплатно. [11] В 1997 году RADIUS был опубликован как RFC 2058 и RFC 2059, текущие версии — RFC 2865 и RFC 2866. [12]
В исходном стандарте RADIUS указано, что RADIUS не имеет состояния и должен работать через протокол пользовательских дейтаграмм (UDP). Для аутентификации предполагалось, что RADIUS должен поддерживать протокол аутентификации по паролю (PAP) и протокол аутентификации с вызовом и рукопожатием (CHAP) по протоколу «точка-точка» . Пароли скрываются путем взятия MD5 -хеша пакета и общего секрета, а затем выполнения XOR этого хеша с паролем. Исходный RADIUS также предоставлял более 50 пар атрибут-значение с возможностью для поставщиков настраивать свои собственные пары. [13]
Выбор модели безопасности «шаг за шагом» вместо сквозного шифрования означал, что если используется несколько прокси-серверов RADIUS, каждый сервер должен проверять, выполнять логику и передавать все данные в запросе. Это предоставляет такие данные, как пароли и сертификаты, на каждом прыжке. Серверы RADIUS также не имели возможности прекращать доступ к ресурсам после выдачи авторизации. Последующие стандарты, такие как RFC 3576 и его преемник RFC 5176, позволяли серверам RADIUS динамически изменять авторизацию пользователей или полностью отключать пользователя. [14]
Сейчас существует несколько коммерческих серверов RADIUS с открытым исходным кодом. Функции могут различаться, но большинство из них могут искать пользователей в текстовых файлах, серверах LDAP , различных базах данных и т. д. Учетные записи могут записываться в текстовые файлы, различные базы данных, пересылаться на внешние серверы и т. д. SNMP часто используется для удаленного мониторинга и постоянная проверка RADIUS-сервера. Прокси-серверы RADIUS используются для централизованного администрирования и могут перезаписывать пакеты RADIUS на лету из соображений безопасности или для преобразования между диалектами поставщиков.
Протокол Diameter был задуман как замена RADIUS. Хотя оба протокола являются протоколами аутентификации, авторизации и учета (AAA), варианты использования этих двух протоколов с тех пор разошлись. Диаметр широко используется в пространстве 3G . RADIUS используется в другом месте. Одним из самых серьезных препятствий на пути замены Diameter RADIUS является то, что коммутаторы и точки доступа обычно реализуют RADIUS, а не Diameter. Diameter использует SCTP или TCP , тогда как RADIUS обычно использует UDP в качестве транспортного уровня . С 2012 года RADIUS также может использовать TCP в качестве транспортного уровня с TLS для обеспечения безопасности.
Протокол RADIUS в настоящее время определен в следующих документах IETF RFC.
{{cite journal}}: Требуется цитировать журнал |journal=( помощь )