Протокол RADIUS

Московский Физико-Технический Институт
Эссе по курсу «Защита Информации»:
Протоколы RADIUS и DIAMETER»
«
Выполнил студент 411 группы
Самуйлов Дмитрий Олегович
г. Долгопрудный, 2008
Протокол RADIUS
RADIUS(англ. Remote Authentication in Dial-In User Service) — наиболее распространенный
сейчас протокол AAA (authentication, authorization и accounting), разработанный для передачи
сведений между программами-сервисами (NAS, Network Access Server) и системой биллинга.
Своей популярностью это протокол с основном обязан своей открытости, в отличие от
TACACS+ (Cisco) и Kerberos (Merit).
RADIUS позволяет осуществлять централизованное администрирование, что особенно важно
при большом числе пользователей и устройств(учетные записи пользователей могут быть
записаны в текстовые файлы, различные базы данных, пересланы на внешние сервера). Многие
поставщики услуг интернета имеют сотни и тысячи пользователей, которые постоянно
добавляются и удаляются.
 Authentication — процесс, позволяющий идентифицировать (узнать) субъекта по его
данным, например, по логину и паролю.
 Authorization — процесс, определяющий полномочия идентифицированного субъекта на
доступ к определенным объектам или сервисам.
 Accounting — процесс, позволяющий вести учет доступа к услугам.
RADIUS был разработан Livingston Enterprises для их серии серверов доступа к сети PortMaster,
но позже, в 1997, был опубликован как RFC 2058 и RFC 2059 (текущая версия RFC 2865 и RFC
2866).
Основные особенности RADIUS




Client-server-based operations. Клиентская часть RADIUS находится на Network Access
Server’е и взаимодействует по сети с сервером RADIUS’а. Кроме того, сервер RADIUS’а
может действовать как Proxy клиент для другого RADIUS’а или другого сервера
аутентификации.
Network security. Все операции между клиентом RADIUS’а а сервером авторизируются
посредством shared secret key который никогда не передается по сети. Также, пароль
пользователя, содержащийся в сообщениях RADIUS’а, шифруется, чтобы нельзя было
узнать его мониторингом сети.
Flexible authentication. RADIUS поддерживает несколько механизмов аутентификации,
например PAP (Password Authentication Protocol), CHAP(Challenge Handshake
Authentication Protocol) и EAP (Extended Authentication Protocol).
Attribute/value pairs. Сообщения RADIUS содержат в себе информацию, закодированную
в виде полей тип-длина–значение, называемых атрибутами, или парами
атрибут/значение. Типичных значение атрибутов – имя пользователя, пароль, ip-адрес
конечного пользователя и т.д.
г. Долгопрудный, 2008
Заголовок пакета RADIUS
Первые 8 бит - поле с кодом, который определяет какого типа пакет.
Вторые 8 бит – идентификатор, которые различить Reaust и Response – пакеты.
Следующие 32 бита – поле аутентификтора, которое используется, чтобы аутентифицировать
ответ сервера RADIUS и также используется как часть алгоритма скрытия пароля пользователя
в запросе.
Рисунок 1. RADIUS пакет
Пары attribute-value в RADIUS’е содержат специфическую информацию для Аутентификации,
Авторизации и Биллинге, и подробные сведения, касающиеся запросов или ответов
Пары attribute-value состоят из трех полей.
Рисунок 2. Attribute-Value Pair
Примеры кодов:
Value Description
1
Access-Request
2
Access-Accept
3
Access-Reject
4
Accounting-Request
5
Accounting-Response
11
Access-Challenge
12
Status-Server (experimental)
13
Status-Client (experimental)
255
Reserved
Схема работы протокола
Процесс авторизации. Сторона клиента:
Rлиент создает Access-Request пакет RADUIS, включающий в себя по крайней атрибуты «UserName» и «User-Password».
Генерируется поле идентификатор пакета. Как он генерируется, в спецификации протокола не
оговорено, но обычно используется просто увеличение на 1 предыдущего идентификатора
г. Долгопрудный, 2008
Поле аутентификатора запроса выбирается случайным образом.
Такой пакет полностью незащищен. За исключением атрибута «User-Password»б который
защищается следующим алгоритмом:
Клиент и сервер имеют секретный ключ. От этого секретного ключа, сложенного с
идентификатором запроса берется MD5 хэш, который XOR’ится с паролем, введенным
пользователем. Если пароль пользователя больше чем два байта, дополнительно вычисляется
MD5 хэш, используя уже полученный шифр вместо идентификатора запроса.
Например:
Пусть секретный ключ S, а сгенерированный идентификатор запроса RA. Пароль разбивается
на двухбайтные блоки p1, p2 … pn. Зашифрованные блоки c1, c2,..,cn.
c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
.
.
.
cn = pn XOR MD5(S + cn-1)
Тогда значение атрибута «User-Password» будет c1+c2+...+cn, где + означает конкатенацию.
Процесс авторизации. Сторона сервера:
получив, Access-Request пакет, сервер RADUIS’а проверяет, имеет ли он секретный ключ для
клиента, приславшего запрос. Если ключа нет. То сервер игнорирует такой пакет.
Так как сервер обладает секретным ключом, он, выполнив действия, аналогичные описанным
выше, проверяет, верный ли был прислан пароль. Если пароль верный, сервер создает AccessAccept пакет, иначе Access-Reject пакет. Оба пакета используют тот же идентификатор, что
был использован в клиентском Access-Request пакета.
Аутентификатор пакета – это MD5 хэш пакета–ответа, аутентификатора Request пакета, и
секретный ключ. То есть
ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) где + азначает
конкатенацию.
Процесс авторизации. Сторона клиента, окончание:
Когда клиент получает пакет с ответом сервера, он ищет соответствующий запрос по полюидентификатору. Если запрос не найден, то пришедший ответ сервера обрабатываться не будет.
Далее проверяется аутентификатор ответа, и при его несовпадении, пришедший пакет также не
будет обрабатываться.
И наконец, в соответствии с типом пришедшего ответа(Access-Accept или Access-Reject),
клиент получает доступ к ресурсам.
Некоторые уязвимости RADIUS:
 Response Authenticator Based Shared Secret Attack
Можно проанализировать Access-Request и связанный с ним Access-Accept пакеты, то можно
запустить проверку на полный перебор секретного ключа.
 User-Password Attribute Based Shared Secret Attack
Можно получить секретный ключ, зная имея возможность посылать запросы к серверу и
анализировать отправленные пакеты: отсылать запросы с известным паролем, полученный
шифр пароля XOR’ить с переданным паролем. Тогда, так как аутентификатор запроса известен.
Можно запустить полный перебор секретного ключа.
 Существует несколько атак, основанных на возможности предсказать аутентификатор
запроса(во многих реализациях протокола он генерируется недостаточно случайно)
г. Долгопрудный, 2008
Diameter
С появлением новых технологий и приложений, таких как беспроводные сети и Mobile IP,
требования к аутентификации и авторизации значительно повысились, а механизмы контроля
доступа стали более сложными. Протокола RADIUS стало недостаточно для удовлетворения
этих новых требований; стало ясно что необходим новый протокол, обладающий новыми
возможностями контроля доступа, сохраняющий в то же время гибкость для последующих
расширений. На основе RADIUS был создан протокол Diameter, предназначенный для того,
чтобы стать общей структурной основой для последующих AAA-приложений. Он широко
используется в IMS-архитектуре(IP Multimedia Subsystem) для обмена AAA-информацией
между IMS-объектами.
Узлы и агенты протокола Diameter
Diameter имеет одноранговую архитектуру (Peer-To-Peer), и каждый хост, реализующий
протокол Diameter, может выступать либо клиентом, либо сервером, в зависимости от сетевой
инфраструктуры. Поэтому термин Diameter-узел используется для ссылки на Diameter-клиент,
на Diameter-сервер или на Diameter-агент. Узел протокола Diameter, принимающий
пользовательский запрос на соединение, выступает как Diameter-клиент. В большинстве
случаев Diameter-клиентом является Network Access Server. После сбора информации,
удостоверяющей пользователя, такой как имя пользователя и пароль, он передаст сообщение
запроса на доступ одному Diameter-узлу, обслуживающему запрос. Для простоты
предположим, что это Diameter-сервер. Diameter-сервер выполняет аутентификацию
пользователя на основе предоставленной информации. Если процесс аутентификации
выполняется успешно, в ответное сообщение включаются полномочия пользователя, и это
сообщение передается обратно соответствующему Diameter-клиенту. В противном случае
передается сообщение об отказе.
В протоколе четко определен специальный Diameter-узел, называемый Diameter-агентом.
Обычно существует три типа Diameter-агентов:
Relay Agent (агент-ретранслятор)
Relay Agent используется для перенаправления сообщения соответствующему адресату в
зависимости от информации, содержащейся в сообщении. Relay Agent является полезным,
поскольку он может объединять запросы от различных областей (или регионов) в
определенную область, что устраняет обременительную настройку серверов сетевого доступа
при каждом изменении Diameter-сервера.
Proxy Agent (прокси-агент)
Рисунок 3. Diameter Proxy Agent
г. Долгопрудный, 2008
Proxy Agent может также использоваться для перенаправления сообщений, но, в отличие от
Relay Agent, Proxy Agent может изменить содержимое сообщения и, следовательно,
предоставлять дополнительные службы, применять правила для различных сообщений или
выполнять задачи администрирования для различных областей. На рисунке 3 показано, как
используется Proxy Agent для перенаправления сообщения в другой домен. Если Proxy Agent не
изменяет содержимое оригинального запроса, в достаточно было бы использования Relay
Agent.
Redirect Agent (агент перенаправления)
Redirect Agent выступает в роли централизованного репозитория конфигураций для других
Diameter-узлов. Принимая сообщение, он проверяет свою таблицу маршрутизации и
возвращает ответное сообщение вместе с информацией о перенаправлении оригинальному
отправителю сообщения. Это может быть очень полезно для других Diameter-узлов, поскольку
им не нужно хранить список записей о маршрутизации локально, и они могли бы, при
необходимости, искать Redirect Agent. На рисунке 4 изображена работа Redirect Agent.
Сценарий, показанный на рисунке 4, в основном идентичен сценарию, показанному на рисунке
3, но в этот раз Proxy Agent не знает адреса связанного Diameter-узла в example.com.
Следовательно, он ищет информацию в Redirect Agent своей собственной области для
получения адреса.
Рисунок 4. Diameter Redirect Agent
Translation Agent (агент преобразования)
Кроме этих агентов существует специальный агент, называемый Translation Agent.
Обязанностью этого агента является преобразование сообщения из одного AAA-протокола в
другой. Translation Agent полезен для компании, или провайдера служб для интеграции
пользовательской базы данных двух прикладных доменов, сохраняя их оригинальные AAAпротоколы. Другая ситуация: компания хочет выполнить миграцию на протокол Diameter, но
этот процесс состоит из нескольких фаз. Translation Agent мог бы обеспечить обратную
совместимость для плавной миграции. На рисунке 5 показано, как один агент преобразовывает
протокол RADIUS в протокол Diameter, но, естественно, возможны также и другие типы
преобразования протоколов (например, Diameter в RADIUS, Diameter в TACACS+).
г. Долгопрудный, 2008
Рисунок 5. Diameter Translation Agent
Diameter-сообщения
Diameter-сообщение - это элементарный модуль для передачи команды или доставки
уведомления другим Diameter-узлам. Для различных целей протокол Diameter имеет различные
типы Diameter-сообщений, которые определяются их кодом команды. Например, сообщение
Accounting-Request распознает, что сообщение содержит информацию об учетной записи, а
сообщение Capability-Exchange-Request распознает, что сообщение содержит информацию о
возможностях Diameter-узла, передающего сообщение.
Код команды используется для идентификации намерения сообщения, но реальные данные
передаются в виде набора пар атрибут-значение (Attribute-Value-Pair - AVP). Протокол Diameter
имеет предопределенный набор общих атрибутов и назначает каждому атрибуту
соответствующую семантику. Эти AVP передают подробности AAA (такую информацию как
маршрутизация, безопасность и возможности) между двумя Diameter-узлами. Кроме того,
каждая пара AVP ассоциируется с форматом AVP Data Format, который определен в протоколе
Diameter (например, OctetString, Integer32), поэтому значение каждого атрибута должно
следовать формату данных.
На рисунке 6 изображена структура Diameter-сообщения и его AVP.
Рисунок 6. Diameter Packet Format
В таблице 1 перечислены все сообщения, определенные в базовом протоколе Diameter:
Таблица 1. Сообщения, определенные в базовом протоколе Diameter
Название сообщения
Аббревиатура
Код команды
Abort-Session-Request
ASR
274
Abort-Session-Answer
ASA
274
Accounting-Request
ACR
271
г. Долгопрудный, 2008
Accounting-Answer
ACA
271
Capabilities-Exchanging-Request
CER
257
Capabilities-Exchanging-Answer
CEA
257
Device-Watchdog-Request
DWR
280
Device-Watchdog-Answer
DWA
280
Disconnect-Peer-Request
DPR
282
Disconnect-Peer-Answer
DPA
282
Re-Auth-Request
RAR
258
Re-Auth-Answer
RAA
258
Session-Termination-Request
STR
275
Session-Termination-Answer STA
STA
275
Соединение и сессия
Соединение - это физическая связь между двумя Diameter-узлами. Для протокола Diameter
является обязательным возможность работы по TCP или SCTP. В сравнении с UDP,
используемым в RADIUS, эти два протокола обеспечивают более надежную передачу, что
является критичным для приложений, обменивающихся информацией, связанной с учетными
записями.
Исходя из того, что Diameter, в основном, имеет одноранговую архитектуру, для конкретного
узла можно было бы установить более одного соединения.
По сравнению с соединением сессия представляет собой логическое соединение между двумя
Diameter-узлами и может пересекать несколько физических соединений. Сессия относится к
взаимодействиям между Diameter-клиентом и Diameter-сервером в течение определенного
периода времени. Каждая сессия в протоколе Diameter ассоциируется с генерируемым
клиентом идентификатором Session-Id, который уникален глобально и постоянно. Session-Id
используется затем для идентификации конкретной сессии во время дальнейшего обмена
информацией.
На рисунке 7 показаны концепции соединения и сессии:
Рисунок 7. Сессия и соединение в Diameter
Инициирование сессии
Как и в большинстве моделей взаимодействия клиент-сервер, Diameter-сессия начинается с
передачи сообщения запроса от клиента серверу. В контексте Diameter Diameter-клиент
передаст сообщение auth-request, содержащее уникальный Session-Id, Diameter-серверу (или
Diameter-прокси, если необходимо перенаправление сообщения). Используемые для
г. Долгопрудный, 2008
аутентификации и авторизации пары AVP зависят от приложения и что они не определены в
базовом протоколе.
После приема сообщения auth-request Diameter-сервер может включить Authorization-Lifetime
AVP в ответное сообщение. Эта пара AVP используется для указания количества времени в
секундах, которое требуется Diameter-клиенту для повторной авторизации. После истечения
лимита времени и допустимого Auth-Grace-Period, Diameter-сервер будет удалять сессию из
своего списка сессий и освобождать все ресурсы, выделенные для нее.
Сессия
Во время сессии Diameter-сервер может инициировать запрос повторной аутентификации или
повторной авторизации. Этот тип запросов используется для проверки продолжения
использования пользователем службы, и если ответ отрицателен, сервер удаляет сессию, чтобы
остановить начисление средств.
Кроме того, для догадки об исключительном закрытии сессии используется пара AVP OriginState-Id. Отправитель запроса будет включать эту AVP, и, поскольку необходимо, чтобы это
значение монотонно увеличивалось, получатель запроса может легко догадаться о том, что
предыдущая сессия была закрыта либо по аварийному завершению работы устройства доступа,
либо из-за каких-либо других исключительных ситуаций. Получатель запроса может затем
удалить сессию из своего списка, освободить ресурсы и, возможно, уведомить свои Diameterсерверы, если он работает как прокси-сервер.
Завершение сессии
Сообщения о завершении сессии используются только в контексте аутентификации и
авторизации и только тогда, когда поддерживалось состояние сессии. Для служб работы с
учетными записями вместо этого сообщения используется сообщение об остановке учета.
Сообщение о завершении сессии может быть инициировано либо Diameter-клиентом, либо
Diameter-сервером. Когда Diamete-клиент полагает, что нужно закрыть сессию, он передает
сообщение Session-Termination-Request Diameter-серверу. В этот запрос включается AVP
Termination-Clause, указывающая Diameter-серверу причину, почему сессия должна быть
закрыта. В свою очередь, если Diameter-сервер обнаруживает, что сессия должна быть закрыта
(возможно, из-за того, что клиент вышел за пределы предоставленного кредита, или просто для
административных целей), Diameter-сервер передает сообщение Abort-Session-Request Diameterклиенту. Однако, в зависимости от различной политики или сценариев использования,
Diameter-клиент может решить не закрывать сессию, даже при получении сообщения от сервера
о ее завершении, и позволить пользователю продолжать пользоваться своим сервисом.
В таблицу 2 сведены некоторые значительные отличия между протоколами Diameter и
RADIUS:
Таблица 2. Сравнение протоколов Diameter и RADIUS
Diameter
RADIUS
Транспортный
протокол
Ориентированные на соединение
протоколы (TCP и SCTP)
Протокол без установления
соединения (UDP)
Защита
Hop-to-Hop, End-to-End
Поддерживает защиту
транспортного и сетевого
уровней(TLS, IPSec)
Hop-to-Hop
Поддерживаемые
агенты
Relay, Proxy, Redirect, Translation
Полная поддержка, означающая,
что поведение агента может быть
реализовано на RADIUS-сервере
г. Долгопрудный, 2008
Возможности по
согласованию
Согласовывает поддерживаемые
приложения и уровень
безопасности
Не поддерживается
Сообщение инициации Поддерживается. Например,
сервера
сообщение повторной
аутентификации, завершения
сессии
Не поддерживается
Максимальный размер 16,777,215 октетов
данных атрибутов
255 октетов
Поддержка сторонних
производителей
Поддерживает только сторонние
атрибуты
Поддерживает сторонние
атрибуты и сообщения
Литература:
[1] http://en.wikipedia.org/wiki/RADIUS
[2] http://en.wikipedia.org/wiki/DIAMETER
[3] http://www-128.ibm.com/developerworks/library/wi-diameter/index.html
[4] http://www.untruth.org/~josh/security/radius/radius-auth.html
[5] http://www.diva-portal.org/diva/getDocument?urn_nbn_se_liu_diva-1195-1__fulltext.pdf
г. Долгопрудный, 2008