✖


Jump to content

РАДИУС

Эта статья о сетевом протоколе аутентификации. Чтобы узнать о других значениях, см. Радиус (значения) .
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

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

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

Атака Blast-RADIUS нарушает работу RADIUS, когда она запускается по незашифрованному транспортному протоколу, такому как UDP. [ 3 ]

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

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

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

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

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

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

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

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

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

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

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

Доступ отклонен
Пользователю безоговорочно отказывается в доступе ко всем запрошенным сетевым ресурсам. Причины могут включать непредоставление удостоверения личности или неизвестную или неактивную учетную запись пользователя.
Доступ к вызову
Запрашивает дополнительную информацию от пользователя, такую ​​как дополнительный пароль, PIN-код, токен или карту. Access Challenge также используется в более сложных диалогах аутентификации, где между компьютером пользователя и Radius-сервером устанавливается безопасный туннель таким образом, что учетные данные доступа скрыты от 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 , сигнал начала учета NAS отправляет на сервер RADIUS (пакет запроса учета RADIUS, содержащий атрибут Acct-Status-Type со значением «start»), чтобы сигнализировать о начале доступ пользователя к сети. «Начальные» записи обычно содержат идентификатор пользователя, сетевой адрес, точку подключения и уникальный идентификатор сеанса. [ 5 ]

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

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

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

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

Роуминг

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

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

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

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

Царства

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

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

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

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

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

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

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

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

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

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

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

Структура пакета

[ редактировать ]
Формат пакетных данных RADIUS.

RADIUS передается через UDP/IP через порты 1812 и 1813. [ 8 ]

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

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

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

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

Поле «Длина» указывает длину всего пакета RADIUS, включая поля «Код», «Идентификатор», «Длина», «Аутентификатор» и дополнительные поля «Атрибут».

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

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

[ редактировать ]
Расположение AVP RADIUS

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

Атрибуты, специфичные для поставщика

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

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

В разделе 5.26 RFC 2865 представлена ​​рекомендуемая кодировка, которой придерживается большинство поставщиков:

26 (1 октет) Длина (1 октет) Идентификатор поставщика (4 байта с прямым порядком байтов) Тип/атрибут поставщика (1 октет) Длина поставщика (1 октет) = 2 + длина (значения) Ценить

Некоторые поставщики используют разные форматы. Например, некоторые поставщики опускают поле «Длина поставщика» или используют 2 октета для полей «Тип поставщика» и/или «Длина поставщика».

Раздел 3.14 RFC 8044 определяет тип данных «vsa», который требует использования формата раздела 5.26 RFC 2865.

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

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

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

Протокол RadSec решает проблему устаревшей безопасности RADIUS/UDP путем «обертывания» протокола RADIUS в TLS . Однако пакеты внутри транспорта TLS по-прежнему используют MD5 для проверки целостности пакетов и для запутывания содержимого определенных атрибутов.

Атака Blast-RADIUS нарушает RADIUS, когда он транспортируется по простому UDP, атакуя MD5 внутри RADIUS. [ 3 ] RadSec блокирует эту атаку. [ 3 ] Еще одним рекомендуемым решением является требование атрибутов Message-Authenticator для всех запросов и ответов. [ 3 ] CVE - номер 2024-3596 Для атаки Blast-RADIUS назначен .

История

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

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

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

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

Сейчас существует несколько коммерческих серверов 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.

RFC Заголовок Дата публикации Связанная статья Связанные RFC Примечание
РФК 2058 Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) Январь 1997 г. РАДИУС Устарело согласно RFC 2138.
РФК 2059 RADIUS-учет Январь 1997 г. РАДИУС Устарело согласно RFC 2139.
РФК 2138 Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) апрель 1997 г. РАДИУС Устарело по RFC 2865.
РФК 2139 RADIUS-учет апрель 1997 г. РАДИУС Устарело по RFC 2866.
RFC 2548 Атрибуты RADIUS, зависящие от поставщика Microsoft март 1999 г. РАДИУС
RFC 2607 Цепочка прокси и реализация политики в роуминге июнь 1999 г.
РФК 2618 MIB клиента аутентификации RADIUS Информационная база управления Устарело по RFC 4668.
РФК 2619 MIB сервера аутентификации RADIUS Информационная база управления Устарело по RFC 4669.
РФК 2620 Клиент учета RADIUS MIB июнь 1999 г. Информационная база управления Устарело по RFC 4670.
RFC 2621 Сервер учета RADIUS MIB июнь 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 РАДИУС и 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 сентябрь 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 г.
РФК 5997 Использование пакетов статуса-сервера в протоколе RADIUS август 2010 г. Обновления RFC 2866
RFC 6158 Рекомендации по проектированию RADIUS март 2011 г.
RFC 6218 Атрибуты RADIUS, зависящие от поставщика Cisco, для доставки ключевого материала апрель 2011 г.
RFC 6421 Требования к криптогибкости для службы удаленной аутентификации пользователей с телефонным подключением (RADIUS) ноябрь 2011 г.
RFC 6613 РАДИУС через TCP май 2012 г. Экспериментальный
RFC 6614 Шифрование Transport Layer Security (TLS) для RADIUS май 2012 г. Экспериментальный
RFC 6911 Атрибуты RADIUS для сетей доступа IPv6 апрель 2013 г. Стандарты трека
RFC 6929 Расширения протокола службы удаленной аутентификации пользователей с телефонным подключением (RADIUS) апрель 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.
RFC 8559 Проксирование динамической авторизации в протоколе RADIUS апрель 2019 г. Стандарты трека

См. также

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

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б «Как работает RADIUS?» . Циско . 19 января 2006 г. Проверено 15 апреля 2009 г.
  2. ^ Эдвин Лайл Браун (2006). Аутентификация на основе порта 802.1X . Тейлор и Фрэнсис. п. 17. ISBN  978-1-4200-4465-2 .
  3. ^ Перейти обратно: а б с д «Взрыв-РАДИУС» . 9 июля 2024 г. . Проверено 10 июля 2024 г.
  4. ^ RFC 2865 Удаленная аутентификация в службе пользователей (RADIUS)
  5. ^ RFC 2866 Учет RADIUS
  6. ^ Декок, А. (май 2015 г.). «Идентификатор доступа к сети» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7542 . Проверено 8 мая 2021 г.
  7. ^ Александр Сотиров; Марк Стивенс; Джейкоб Аппелбаум; Арьен Ленстра; Дэвид Молнар; Привет, Арне Освик! Бенне де Вегер (08 декабря 2008 г.). «MD5 сегодня считается вредным — создание мошеннического сертификата ЦС» . Эйндховенский технологический университет . Проверено 19 апреля 2009 г.
  8. ^ «Настройка информации о UDP-порте NPS» . Майкрософт . 07.08.2020 . Проверено 20 июня 2021 г.
  9. ^ «Соображения IANA для RADIUS (служба удаленной аутентификации пользователей)» . Ietf Datatracker . Целевая группа инженеров Интернета (IETF). Июль 2003 года . Проверено 8 мая 2021 г.
  10. ^ RFC 2548
  11. ^ Анализ протокола аутентификации RADIUS
  12. ^ Джонатан Хассел (2003). RADIUS: Обеспечение публичного доступа к частным ресурсам . О'Рейли Медиа. стр. 15–16. ISBN  9780596003227 .
  13. ^ Джон Волбрехт (2006). «Начало и история RADIUS» (PDF) . Интерлинк Сети . Проверено 15 апреля 2009 г.
  14. ^ Джонатан Хассел (2003). RADIUS: Обеспечение публичного доступа к частным ресурсам . О'Рейли Медиа. п. 16. ISBN  9780596003227 .
  15. ^ «Расширения динамической авторизации для удаленной аутентификации в службе пользователей (RADIUS)» . Ietf Datatracker . Рабочая группа по интернет-инжинирингу. Январь 2008 года . Проверено 8 мая 2021 г.

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

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=RADIUS&oldid=1235292001"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b8105e0f3825631117a55d6e48051c85__1721306760
URL1:https://arc.ask3.ru/arc/aa/b8/85/b8105e0f3825631117a55d6e48051c85.html
Заголовок, (Title) документа по адресу, URL1:
RADIUS - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)