|
RADIUS
1. Описание
Название протокола RADIUS - аббревиатура
от Remote Authentication Dial In User Service (служба удалённой аутентификации
входящих звонков пользователей). Название называет область, где чаще всего
применяется RADIUS: аутентификация входящих модемных подключений пользователей
к серверу удалённого доступа.
Протокол разработан в 1989 году фирмой Livingston (как раз и являющейся
крупным производителем серверов удалённого доступа), затем доработа в
Мичиганском университете, а затем принят IETF и описан в RFC 2138 и 2139.
Таким образом, RADIUS в данный момент - открытый стандарт, что обеспечило
ему популярность среди самых разных производителей оборудования.
RADIUS представляет собой клиент-серверный
протокол, работающий поверх UDP. Выбор UDP, а не TCP обусловлен тем, что
в случае отказа сервера аутентификации, UDP позволяет быстрее переключиться
на запасной сервер. В то же время, использование UDP диктует необходимость
реализации схем контроля доставки и повторной передачи средствами самого
протокола RADIUS.
2. Формат пакета
Пакет RADIUS выглядит следующим
образом:
Назначение полей пакета:
- Code - код запроса/ответа (8 бит);
- Identifier - идентификатор (должен совпадать у запроса и соотв. ответа;
8 бит);
- Length - длина всего пакета (16 бит);
- Autheticator - поле проверки подлинности ответа сервера (16 байт);
- Attributes - данные запроса/ответа.
Обмен между сервером и клиентом (клиентом
RADIUS является сервер доступа, а не непосредственно модемный пользователь)
поисходит по принципу запрос-ответ.
Возможные варианты запросов и ответов на
них:
1. access-request: запрос на доступ пользователя к определённым службам
- access-accept: положительный ответ, доступ разрешён.
- access-reject: отрицательный ответ, доступ запрещён.
- access-challenge: запрос дополнительной информации сервером, которую
клиент (сервер доступа) должен предоставить в следующем запросе.
2. accounting request, запрос на размещение данных учёта на сервере.
- accounting response, данные успешно размещены на сервере.
3. Схема обмена информацией
Ниже приведен пример обмена
информацией между сервером доступа и сервером RADIUS при подключении и
отключении пользователя.
Комментарии к рисунку:
1. Сервер доступа получает пару имя:пароль от пользователя, шифрует общим
(с RADIUS-сервером) секретным ключом и отправляет в пакете access-request.
2. В ответ на правильную комбинацию, RADIUS-сервер посылает accept-accept
и дополнительную информацию (IP-адрес, допустимое время сеанса и т.п.)
3. Сервер доступа посылает accounting-request (start), отмечая таким образом
подключение пользователя к сети.
4. RADIUS-сервер сохраняет время начала сеанса пользователя и отвечает
серверу доступа сообщением accounting-response.
5. По окончании сеанса сервер доступа посылает accounting-request (stop)
вместе со следующей информации о состоявшемся сеансе:
- Время задержки (посылки этого сообщения)
- Число байт, полученных пользователем.
- Число байт, полученных от пользователя байт.
- Продолжительность сеанса связи.
- Число пакетов, полученных ползователем.
- Число пакетов, полученных от пользователя.
- Причина отключения пользователя от сети.
6. Сервер сохраняет эту информацию и отсылает серверу доступа accounting-response.
DIAMETER
1. Описание
Протокол DIAMETER во многом напоминает RADIUS,
однако имеет ряд преимуществ, которые приведены в конце этого раздела.
DIAMETER разрабатывался для применения в одной среде с уже распространённым
проотоколом RADIUS.
Базовая версия, описанная в документе draft-calhoun-diameter-10, обеспечивает
следующую функциональность:
- Надёжную доставку сообщений в виде UDP-дейтаграмм
- Управление потоком ("окно" приёма)
- Своевременное обнаружение отказа серверов
- Доставку пар атрибут-значение (attribute-value pair, AVP)
- Расширяемость за счёт добавления новых видов AVP
2. Формат пакета
Сервер доступа и DIAMETER-сервер обмениваются
сообщениями по протоколу UDP.
Одному UDP-пакету соответствует одно сообщение. Формат пакета представлени
ниже.
Описание полей пакета:
1. RADIUS PCC: Поле совместимости с RADIUS (Packet Compatibility Code,
1 байт). Содержит значение 254, что обозначает пакет DIAMETER.
2. Флаги (3 бита): в базовом протоколе назначение не определено.
3. Флаг A (1 бит): сообщение является квитанцией и не содержит команд
4. Флаг W (1 бит): устанавливается, когда используются транспортные функции
DIAMETER.
5. Version (Версия, 3 бита): номер версии протокола, в настоящее время
1.
6. Packet length (Длина пакета, 2 байта): длина всего пакета
7. Identifier (Идентификатор, 4 байта): значение, исп. для сопоставления
ответов запросам.
8. NS (2 байта): поле, используемое при работе в кач-ве транспортного
протокола.
9. NR (2 байта): поле, используемое при работе в кач-ве транспортного
протокола.
- AVP Code (Код AVP, 4 байта): код команды
- AVP Length (Длина AVP, 2 байта): длина этой AVP
- Флаги (6 бит): используются в зависимости от команды
- Резерв (6 бит)
- Флаг T (1 бит): флаг присутствия поля Tag, используемого для объединения
AVP.
- Флаг V (1 бит): обозначает наличие необязательного поля Vendor ID.
- Флаг H (1 бит): флаг использования шифрования AVP.
- Флаг M (1 бит): флаг обязательности поддержки данной AVP.
- Vendor ID (4 байта, необязательное): идентификатор производителя.
- Tag (4 байта, необязательное).
3. Схема обмена информацией
Ниже приведена схема обмена информацией при
регистрации и последующем выходе пользователя из системы. Сообщения, изображённые
на схеме, пересылаются с использованием UDP, поверх которого работает
собственная реализация механизма оконного управления потоком. На каждый
полученный пакет принимающей стороной высылается подтверждение (на схеме
не отражено).
Описание процесса:
1. Сервер доступа посылает полученные от
пользователя имя:пароль в пакете AA-Request.
2. Если от пользователя полученные правильные имя/пароль, то сервер отвечает
AA-Response вместе с доп. информацией (IP адрес, маска подсети и т.п.)
3. Сервер доступа посылает сообщение ADIF (Accounting Data Interchange
Format).
4. Сервер DIAMETER подтверждает получение сообщения ADIF.
5. По окончании сеанса сервер доступа отправляет ещё одно ADIF-сообщение
со статистикой соединения.
6. Сервер DIAMETER подтверждает получение ADIF-сообщения и заносит данные
о сеансе в БД.
4. Преимущества DIAMETER
Как видно, протоколы RADIUS и DIAMETER похожи
в принципе работы и даже в формате пакетов. Однако есть и существенные
отличия.
Алгоритм повторной передачи.
В пакетах RADIUS под идентификатор отводится 1 байт, что ограничивает
число запросов, ожидающих подтверждения (255). В DIAMETER на ID отводятся
4 байта.
Средства управления потоком.
RADIUS не предусматривает никаких средств управления потоком сообщений
между клиентом и сервером, в то время как DIAMETER использует эффективную
оконную схему управления потоком.
Подтверждения
RADIUS предусматривает подтверждение сообщений, но в случае работы прокси
установить, получил ли сервер сообщение не представляется возможным.
DIAMETER требует от сервера подтверждения получения сообщения и вто же
время позволяет работать прокси.
Уведомление об ошибках
Для участвующих в RADIUS-обмене сторон не предусмотрена отсылка уведомлений
об ошибках, что может позволить одной из сторон полагать, что команда
была выполнена, в том время как на самом деле в сообщении была обнаружена
ошибка и он был отброшен.
DIAMETER даёт возможность стороне уведомить другую об ошибке.
Уведомление о прекращении работы
Хотя RADIUS и позволяет обнаружить выход сервер из строя, однако DIAMETER
даёт возможность уведомить клиентов о прекращении работы сервера и таким
образом осуществить переход на запасной сервер без задержек.
Атаки типа "повтор авторизации"
Использование PPP CHAP позволяет любому RADIUS-клиенту или прокси перехватить
данные, используемые при аутентификации и воспроизвести их в другой раз
(проблем частично решена расширением RADIUS, использующим протокол EAP).
Защита данных от сервера до клиента
RADIUS предусматривает защиту данных лишь между непосредственно обменивающимися
узлами. Любой промежуточный узел (прокси) может изменить данные и такое
изменение не может быть обнаружено. DIAMETER же не позволяет прокси менять
информацию.
Поддержка дополнительных команд
RADIUS не поддерживает дополнительных к определённым в протоколе команд.
DIAMETER изначально проектировался с учётом возможности расширения (предусмотрена
возможность добавления новых AVP).
Сложность обработки
RADIUS не определяет требований по выравниванию данных.
DIAMETER требует выравнивания по 32-битной границе, что облегчает обработку
на большинстве процессоров.
TACACS
1. Описание
TACACS (Terminal Access Controller Access
Control System) - протокол, использовавшийся ещё в староглиняные времена
на серверах доступа ещё аж ARPANET. Тем не менее, идея всё та же самая:
центральный сервер, который принимает решение, разрешить или не разрешить
определённому пользователю подключиться к сети. TACACS не предусматривает
сбора какой-либо статистики. Таким образом от AAA остаётся AA.
TACACS описан в документе RFC 1492.
Существуют 2 версии TACACS: исходная, использовавшаяся в ARPANET и более
новая, доработанная и пременявшаяся (до появления TACACS+) Cisco.
2. Формат пакета
Прежде всего, сделаем необходимлое уточнение:
здесь описывается оригинальный вариант TACACS, без расширений Cisco (т.н.
simple form of packet, простая форма).
Кое-какие замечания по расширениям, сделанным Cisco, будут даны в конце
раздела.
Сообщения TACACS пересылаются в детаграммах
UDP - строго по одному в каждой.
Клиент (сервер доступа) отправляет серверу
запросы в следующем формате:
Поля запроса:
" Version (Версия, 1 байт): простая
форма (0)
" Type (Тип запроса, 1 байт): в простой форме - только LOGIN, SUPERUSER
и LOGOUT
" Nonce (Номер, 2 байта): произвольное число, поволяющее сопоставить
запрос и ответ.
" Username length (Длина имени пользователя, 1 байт)
" Password length (Длина пароля, 1 байт)
" Data (Данные, длина переменная): имя пользователя и пароль.
Сервер отвечает сообщением следующего формата:
Назначения полей те же, за исключением:
- Response (Ответ, 1 байт): код ответа - пароль принят или отвергнут.
- Reason (Причина, 1 байт): дополнительная информация при Response = rejected.
- Поле данных отсутствует.
3. Схема обмена TACACS
Работа TACACS предельно проста:
1. Клиент (сервер доступа) посылает запрос
LOGIN с именем и паролем, полученными от пользователя.
2. Сервер TACACS отвечает либо кодом accepted (и тогда Reason = 0), либо
rejected и тогда Reason содержит дополнительный код: expiring, password
или denied.
2.1. Во время сенса связи (после успешного LOGIN) пользователь может затребовать
дополнительные привилегии (SUPERUSER). Интерпретация этого понятия зависит
от реализации.
3. По окончании сеанса сервер доступа отправляет сообщение LOGOUT (и устанавливает
Reason = quit, idle, drop или bad)
4. Сервер TACACS подтверждает получение LOGOUT успешшным кодом завершения.
4. Расширения Cisco
Cisco расширила функциональность TACACS для
своих нужд. Была введена т.н. расширенная форма запроса (Version = 128):
добавлены несколько новых полей, добавлена поддержка SLIP, а также работа
по протоколу TCP с другим форматом запросов и ответов (текстовым, похожим
на FTP и SMTP).
Описывать эти расширения особого смысла нет, т.к. сама Cisco уже давно
использует TACACS+.
TACACS+
1. Описание
TACACS+ - результат дальнейшего усовершенствования
TACACS, предпринятого Cisco. Улучшена безопасность протокола (шифрование),
а также введно разделение функций аутентификации, авторизации и учёта,
которые теперь можно использовать по отдельности.
TACACS+ использует понятия сеансов. В рамках TACACS+ возможно установление
трёх различных типов сеансов: authentication, authorization и accounting.
Установление одного типа сеанса в общем случае не требует предварительного
успешного установления какого-либо другого. Конкретно: спецификация протокола
не требует для открытия сеанса authorization открыть сначала сеанс authentication.
Сервер TACACS+ может потребовать authentication, но сам протокол этого
не оговаривает.
2. Формат пакетов
Т.к. TACACS+ является сеансовым протоколом,
то и работает он поверх TCP.
Для всех передачи всех типов сообщений в обоих направлениях используется
один формат TACACS+ пакета.
Поле Type определяет тип сеанса,
которому принадлежит данный пакет: Authentication, Authorization или Accounting.
Session ID позволяет устанавливать в рамках одного TCP-соединения несколько
сессий.
3. Схема работы
Как уже было сказано, TACACS+ состоит из
трёх частей, которые могут работать независимо друг от друга. Опишем их
работу.
3.1. Процесс аутентификации (утановление
сеанса authentication).
Для сеанса authentication определены три
типа пакетов: START, CONTINUE и REPLY.
Клиент направляет серверу пакеты START и CONTINUE, сервер отвечает REPLY.
Сеанс начинается с посылки клиентом пакета
START, содержащий:
- Используемый метод аутентификации: ASCII, PAP, CHAP, ARAP, MSCHAP.
- Уровень доступа, для которогу будет выполняться аутентификация. Предопределены
4 уровня доступа: MIN, USER, ROOT и MAX.
- Данные (или часть, или ничего - в зависимости от метода и желания клиента)
для аутентификации.
В ответ на START сервер должен послать REPLY,
с одним из возможных результатов (зависящих от метода аутентификации):
- PASS - сообщение об успешном прохождении
аутентификации.
- FAIL - о недачной попытке.
- GETUSER - запрос имени пользователя. Например, если был выбран метод
ASCII, но имя пользователя не было включено в пакет START.
- GETPASS - запрос пароля.
- GETDATA - запрос дополнительных сведений. Используется в других методах.
Разные методы аутентификации могут потребовать
обмена различным числом сообщений между клиентом (сервером доступа) и
сервером TACACS+.
Все последующие (после START) пакеты от клиента должны быть CONTINUE.
Клиент может прервать сеанс в любое время, установив флаг ABORT в очередном
пакете CONTINUE.
Сервер может запросить переустановку сеанса (статус RESTART в пакете REPLY),
а также перенаправить клиента (статус FOLLOW в пакете REPLY). В этом случае
сервер в поле данных пакета передаёт список серверов.
3.2. Авторизация.
Авторизация подразумевает обмен всего двумя
пакетами:
- Клиент пакетом REQUEST запрашивает права
на использование опрелённых служб.
- Сервер отвечает пакетом RESPONSE, содержащим код ответа.
Сервер также может изменять параметры запроса
клиента (например, авторизовать доступ, но с другим IP адресом) или добавить
свои. Для этих случае есть свои коды статуса: PASS_REPL, PASS_ADD.
3.3. Учёт.
Клиент направляет серверу REQUEST, в котором
определяет набор параметров учёта.
Information is borrowed from:
1. http://www.securitytechnet.com/security/auth.html
2. http://ing.ctit.utwente.nl/WU5/D5.1/Technology/
3. http://www.lanbilling.ru/radius_tacacs.html
4. [RFC2865] Rigney, C., Rubens, A., Simpson, W, and Willens, S.; "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000
(http://www.ietf.org/rfc/rfc2865.txt?number=2865)
5. [RFC1492] Finseth, C.; "An access Control Protocol, Sometimes
called TACACS", RFC 1492, July 1993
6. D. Carrel, Lol Grant, "The TACACS+ Protocol Version 1.78",
January, 1997
(http://ing.ctit.utwente.nl/WU5/D5.1/Technology/tacacs+/draft-grant-tacacs-02.txt)
7. Pat R. Calhoun, Allan C. Rubens, Haseeb Akhtar, "DIAMETER Base
Protocol", October 1999
(http://ing.ctit.utwente.nl/WU5/D5.1/Technology/diameter/draft-calhoun-diameter-10.txt)
8. http://la-optic.narod.ru
|
