Пояснительная записка к дипломному проекту


Протокол аутентификации RADIUS



страница3/9
Дата09.11.2016
Размер0.62 Mb.
Просмотров1569
Скачиваний0
1   2   3   4   5   6   7   8   9

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




  1. Пользователь инициирует соединение PPP с сервером доступа.

  2. Сервер доступа запрашивает у пользователя имя и пароль.

  3. Пользователь отвечает на запрос.

  4. Клиент RADIUS посылает имя пользователя и зашифрованный пароль серверу RADIUS.

  5. Сервер RADIUS отвечает сообщениями Accept, Reject или Challenge.

  6. Клиент 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+.




  1. Пользователь инициирует соединение PPP с сервером доступа.

  2. Сервер доступа запрашивает у пользователя имя и пароль.

  3. Пользователь отвечает на запрос.

  4. Клиент TACACS+ посылает зашифрованный пакет серверу TACACS+.

  5. Сервер TACACS+ сообщает результаты идентификации.

  6. Клиент и сервер обмениваются авторизационной информацией.

  7. Клиент 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, как на наиболее распространенном и функциональном протоколе.

Каталог: data -> 2013
2013 -> Федеральное государственное автономное образовательное
2013 -> «Визуальный образ персонажей массового кинематогрфа в историческом контексте»
2013 -> 2 раздел анализ предметной области 5
2013 -> Магистерская диссертация
2013 -> Влияние вовлеченности на готовность платить за коллекционные товары
2013 -> Выражение гендерных характеристик в англоязычном "глянцевом" дискурсе
2013 -> Продакт Плейсмент и перспективы его развития в сети Интернет
2013 -> 1Лекции первого полугодия
2013 -> «Правовое рассмотрение компьютерного мошенничества», Ницца, 22 октября 1992 года, грамота «весьма достойно»


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал