1.1.2 Протокол аутентификации RADIUS
RADIUS – сетевой протокол для решения вопросов аутентификации, авторизации и сбора сведений об использованных ресурсах, разрабатывался специально для системы тарификации использованных ресурсов конкретным пользователем. [2]
Протокол RADIUS основан на клиент-серверной архитектуре. RADIUS сервер хранит список валидных клиентов и таким образом может проверять на подлинность запрашиваемые сервера. Между RADIUS-сервером и RADIUS-клиентами имеется общий ключ. Этот ключ не может быть пустым и используется для проверки подлинности RADIUS сервера и Network Access Server (далее NAS), что позволяет сокрыть пароль от конечного пользователя. Клиентом RADIUS выступает NAS, а сервером RADIUS считается “демон”, работающий на машине UNIX или NT. Если возникает потребность в сетевом ресурсе или услуге, RADIUS-клиент отправляет пользовательскую информацию на определенные RADIUS-серверы, которые в свою очередь отправляют ответ, после чего RADIUS-клиенты действует в соответствии с полученными от сервера указаниями.
Серверы RADIUS принимают запросы от пользователей на подключение, производят аутентификацию пользователей, а затем отправляют конфигурационные данные, которые необходимы клиенту для обслуживания пользователя. Для других серверов RADIUS сервер RADIUS выступает в роли клиента-посредника (proxy).
На рисунке 3 показано взаимодействие между пользователем с одной стороны и клиентом и сервером RADIUS с другой.
Рис. 3 Взаимодействие между пользователем и системой RADIUS
Пользователь инициирует соединение PPP с сервером доступа.
Сервер доступа запрашивает у пользователя имя и пароль.
Пользователь отвечает на запрос.
Клиент RADIUS посылает имя пользователя и зашифрованный пароль серверу RADIUS.
Сервер RADIUS отвечает сообщениями Accept, Reject или Challenge.
Клиент RADIUS обрабатывает параметры, полученные от сервера вместе с сообщениями Accept или Reject.
Регистрация пользователя состоит из поступающего от NAS на RADIUS-сервер запроса (Access Request), и соответствующего (положительного или отрицательного) ответа от RADIUS-сервера. В пакете Access Request содержится имя пользователя, зашифрованный пароль, IP-адрес системы NAS и соответствующий номер порта.
После того, как RADIUS-сервер получает от NAS запрос Access Request, начинается поиск указанного имени пользователя в базе данных. Если в базе данных такого имени нет, то сервер загружает пользовательский профиль по умолчанию, или же отправляет пользователю отрицательный ответ. В отрицательном ответе могут быть указаны причины отрицательного ответа.
В случае, если же имя пользователя в базе данных нашлось и указанный пароль верный, то RADIUS-сервер выдает положительный ответ, в котором содержится список атрибутов для данной сессии. Типичными атрибутами являются тип услуги (shell или framed), тип протокола, IP-адрес, список объектов к которым разрешен доступ или же статический маршрут, который нужно добавить в таблицу маршрутизации NAS. На рисунке №4 показана процедура аутентификации и авторизации RADIUS.
Рис. 4 Процедура идентификации и авторизации RADIUS
С помощью учетных функций RADIUS можно отслеживать количество ресурсов (количество времени, байтов и т.д.) использованных в данной сессии.
Транзакции между клиентом и сервером RADIUS идентифицируются с помощью общего “секрета”, который никогда не передается по сетевым каналам. Кроме того обмен любыми пользовательскими паролями между клиентом и сервером RADIUS производит только в зашифрованном виде.
1.1.3 Протокол аутентификации TACACS+
TACACS+ это сетевой протокол последнего поколения серии протоколов TACACS. [2]
TACACS - это простой протокол управления доступом, основанный на стандартах User Datagram Protocol (UDP) и разработанных компанией Bolt, Beranek, and Newman, Inc. для военной сети Military Network (MILNET). Компания Cisco улучшала и расширяла протокол TACACS, в итоге появилась собственная версия протокола TACACS, известная как TACACS+.
Для своей работы TACACS+ использует транспортный протокол TCP. Демон сервера "прослушивает" порт №49 протокола IP (специально выделенный для протокола TACACS). Этот порт зарезервирован для специальных номеров RFC в протоколах UDP и TCP. Все текущие версии TACACS и расширенные версии этого протокола используют порт № 49.
Протокол TACACS+ основан на клиент-серверной архитектуре, где клиентом TACACS+ выступает Network Access Server (далее NAS), а в роли сервера выступает “демон” (daemon) TACACS+.
Процесс аутентификации между клиентом TACACS+ и сервером происходит с помощью общего ключа, который не передается по каналам связи. Данный ключ администратор задает на сервере и на клиенте вручную. TACACS+ можно настроить таким образом, чтобы весь трафик между клиентом TACACS+ и демоном сервера TACACS+ шифровался. На рисунке 5 изображено взаимодействие клиентом и сервером TACACS+.
Рис. 5 Взаимодействие между пользователем и системой TACACS+.
Пользователь инициирует соединение PPP с сервером доступа.
Сервер доступа запрашивает у пользователя имя и пароль.
Пользователь отвечает на запрос.
Клиент TACACS+ посылает зашифрованный пакет серверу TACACS+.
Сервер TACACS+ сообщает результаты идентификации.
Клиент и сервер обмениваются авторизационной информацией.
Клиент TACACS+ обрабатывает параметры, полученные во время авторизации.
В процессе аутентификации TACACS+ посылает пакеты трех типов: START, CONTINUE и REPLY. START и CONTINUE которые отправляет клиент, а REPLY отправляет сервер.
Аутентификация начинается, когда клиент отправляет серверу сообщение START. В сообщении START описывается тип аутентификации имя пользователя и некоторые идентификационные данные. Пакет START является первым сообщением процесса аутентификации или сразу же после повторного запуска этого процесса. (Повторный запуск может запуститься по запросу сервера, который находится в пакете REPLY). Пакет START всегда имеет порядковый номер равный единице.
В ответ на пакет START сервер высылает пакет REPLY. В сообщении REPLY указывается, закончилась ли аутентификация или ее следует продолжить. Если же пакет REPLY требует продолжения аутентификации, то указывается, какую дополнительную информацию необходимо предоставить. Клиент собирает эту информацию и отправляет ее серверу в сообщении CONTINUE.
По окончании аутентификации клиент может начать процесс авторизации (если она требуется). Сессия авторизации состоит из двух сообщений: сообщения REQUEST (запрос) и следующего за ним сообщения RESPONSE (ответ). Сообщение REQUEST содержит фиксированное количество полей, которые описывают пользователя или процесс, и переменный набор аргументов, которые описывают услуги и опции, требующие авторизации.
На рисунках №6, №7 показаны процессы идентификации и авторизации TACACS+.
.
Рис. 6 Процесс авторизации TACACS+
Рис. 7 Процесс идентификации TACACS+
Остановимся на протоколе Kerberos, как на наиболее распространенном и функциональном протоколе.
|
