Протоколы RADIUS и TACACS+: сравнение и принципы функционирования

Для начала необходимо определиться, что это за протоколы, для чего они нужны (кто не знает). Все, кто знает, о чем пойдет речь, могут смело пропустить несколько следующих абзацев.
Итак, данные протоколы используются для обмена информацией между Network Access Server'ом (NAS) и 3A (Authentication, Authorization, Accounting) сервером. Далее NAS я часто буду назвать клиентом, поскольку NAS является клиентом по отношению к 3A-серверу. Собственно, в общем случае у 3А-сервера несколько клиентов. Пользователем по тексту я буду называть нечто, запрашивающее доступ к некому ресурсу у клиента. Не понятно?
Поясню на рисунке:


Для начала необходимо определиться с понятиями, я их постараюсь объяснить попроще (как когда-то объяснили мне), без всяких там "формул" и т.д, а на обыкновенном человеческом языке.

Аутентификация (Authentication) — процесс проверки имени пользователя и пароля. Жизненный пример: приходит в охраняемое здание некий Вася и показывает охране свой паспорт — вот он я, вот паспорт, вот фотография на паспорте. Все сходится ?
Авторизация (Authorization) — процесс проверки пользователя на предмет возможности использования какого-либо ресурса. Ну то есть: ты конечно Вася и паспорт с фотографией у тебя в порядке, да вот только вот в этот кабинет тебе вход разрешен, а вот в этот — нет.
Эккаунтинг (Accounting) — процесс учета используемого сервиса: вошел наш Вася в какую-то комнату — сделал заметку в книге учета (вошел Вася в такое-то время), вышел — опять оставил пометку (Вася вышел в такое-то время).
Итак вернемся к рисунку: на этом рисунке Вася является пользователем, охрана — NAS (клиентом к 3A-серверу), а сам 3А-сервер — это некое хранилище информации о всех пользователях (кто есть кто и сколько чего кому разрешено). На практике обычно это выглядит так:

1.Пользователь Mokromax дозванивается до своего провайдера услуг (как правило, NAS'ы фирмы CISCO или Lucent) и вводит свой пароль.
2.В этот момент NAS формирует и посылает запрос аутентификации к 3A-серверу, далее ожидает ответа.
3.3А-сервер получает запрос, лезет в какое-либо хранилище данных (хранилищем может быть все, что угодно — Oracle, MS SQL, MySQL, просто таблица или нечто другое) и проверяет имя пользователя и пароль. 
4.3A-сервер формирует и посылает ответ NAS'у. 
5.NAS принимает ответ и пропускает пользователя (устанавливает с ним связь) или нет (разрывает соединение).
Пункты 2-5 как раз и являются процессом аутентификации. Давайте предположим, что пользователь прошел аутентификацию успешно. 
6.Пользователь Mokromax хочет попользоваться услугой доступа к Интернету. 
7.В этот момент NAS формирует и посылает запрос авторизации к 3A-серверу, далее ожидает ответа. 
8.3А-сервер получает запрос, опять лезет в какое-либо хранилище данных и проверяет возможность пользователя пользоваться данным ресурсом, а также устанавливает количество сервиса, которое доступно пользователю (Mokromax может пользоваться Интернетом еще 33 минуты). 
9.3A-сервер формирует и посылается ответ NAS'у. 
10.NAS подключает пользователя к ресурсу (к Интеренту) и запускает таймер (через 33 минуты пользователь будет принудительно отключен).
Пункты 7-10 являются процессом авторизации. 
11.В момент начала пользования ресурсом 3A-сервер информируется NAS'ом об этом. 
12.3A-сервер подтверждает прием данной учетной информации. 
13.В момент окончания пользования ресурсом 3A-сервер также информируется NAS'ом об этом. При этом NAS указывает количество потребленного сервиса. 
14.3А-сервер предпринимает какие-либо действия связанные с учетом потребленного сервиса (Mokromax пользовался Интернетом 16 минут, остаток: 33-16=17 минут). 
15.3A-сервер подтверждает прием данной учетной информации.
Пункты 11-15 являются процессом эккаунтинга. Причем возможна настройка клиентов, при которых они не будут отсылать пакеты о начале пользования сервисом или ресурсом — иногда это бывает удобно. Так вот, как я говорил раньше, описываемые ниже протоколы используются для обмена информацией NAS и 3А-сервером. Чем же эти протоколы так хороши?
Прежде всего, эти протоколы предоставляют возможность шифрования (пароля в случае с RADIUS'ом или всего пакета в случае с TACACS+), надежной передачи информации (квитирование), а так же оптимизированы для передачи именно 3A-информации.

RADIUS (Remote Authentication Dial In User Service)

Полное описание данного протокола находится в RFC-2138 и RFC-2139, которые можно найти здесь (http://www.ietf.org) и еще в куче мест в Интернете. Это протокол (в отличие от TACACS+) был разработан независимой группой разработчиков (на данный момент протокол не модифицируется) и поэтому получил широкое распространение у сторонних разработчиков. Как правило, все производители программных и аппаратных клиентов поддерживают данный протокол. Кратко о протоколе можно сказать следующее: использует в своей основе протокол UDP (а поэтому относительно быстр), процесс авторизации происходит в контексте процесса аутентификации (т.е. авторизация как таковая отсутствует), реализация RADIUS-сервера ориентирована на однопроцессное обслуживание клиентов (хотя возможно и многопроцессное — вопрос до сих пор открытый), поддерживает довольно ограниченное число типов аутентификации (сleartext и CHAP), имеет среднюю степень защищенности.

TACACS+

Данный протокол является разработкой фирмы Cisco Systems и его реализация периодически модифицируется. Этот протокол является новым витком развития более ранних версий протоколов TACACS и XTACACS: хоть в официальных выпусках и говорится, что всего-то повышена безопасность протокола, но реально весь протокол технически был переписан заново (осталась разве только идеология), поэтому не путайте между собой эти протоколы (в повседневной жизни и в описаниях очень часто оконечный "+" опускают, откуда и появляется неразбериха; более старый протокол TACACS практически никто сейчас не использует, поэтому если вы видите ссылку на протокол TACACS, скорее всего кто-то проигнорировал "+" и речь идет о TACACS+). Протокол основан на использовании протокола TCP, поэтому потенциально медленнее RADIUS'а (все-таки установление TCP-соединения довольно накладная операция), но зато позволяет вести мультипроцессную обработку запросов (в каждый момент времени могут обслуживаться несколько пользователей). Степень защищености — высокая (зашифровано все тело пакета).
А теперь хотелось бы поподробнее сравнить возможности обоих протоколов.
Для начала таблица:

	RADIUS	TACACS+
базовый протокол	UDP	TCP
поддерживаемые сервисы	AuthenticationAccounting	AuthenticationAuthorizationAccounting
безопасность	Шифруется пароль	Шифруется все тело пакета
поддерживаемые типы аутентификации	Clear text (ASCII, PAP) CHAP	Clear text (ASCII, PAP) CHAP ARAP
возможность перенаправления запроса	Есть	Нет

базовый протокол

RADIUS базируется на протоколе UDP (пакетная передача данных без гарантии передачи пакета). Отсюда вытекает тот факт, что RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в течение некоторого времени (timeout'а) и в случае отсутствия ответа перепослать пакет еще раз. Собственно TACACS+ клиент тоже должен всегда дожидаться ответа от сервера, да вот только гарантией передачи пакета он не озабочен. Зато у TACACS+ имеет место другой момент: для обработки какого-либо запроса TACACS+ сервер и клиент должны установить TCP-соединение (даже если весь процесс будет состоять из посылки и приема 2-ух небольших пакетов!), а с точки зрения времени это довольно накладный процесс (кстати именно поэтому TACACS+ по определению относительно медленен). На основе приведенного примера можно сразу сказать, что RADIUS будет более эффективен в сетях, где процент потерянных пакетов не превышает 5-10%; в других сетях лучше использовать TACACS+. 

поддерживаемые сервисы

Протокол RADIUS не поддерживает авторизацию. То есть RADIUS есть смысл использовать только там, где заранее известно какой сервис предоставляет конкретный RADIUS-клиент. У TACACS+ заложена поддержка авторизации, да вот только количество авторизуемых сервисов тоже довольно ограничено в текущей версии (правда есть возможность расширения): "slip", "ppp", "arap", "shell", "tty-daemon", "connection", "system" и "firewall". То есть вот как получается: для доступа к какому-либо сервису RADIUS обрабатывает один запрос (аутентификацию), а TACACS+ — два (аутентификацию и авторизацию), но при этом при использовании TACACS+ есть возможность получить доступ к другому сервису. 

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

Здесь первым делом надо отметить, что в данной концепции ПОДРАЗУМЕВАЕТСЯ, что 3А-сервис доверяет клиенту, иначе все выкладки не имеют смысла. Следовательно, при написании любого 3A-сервера (будь то TACACS+ или RADIUS) нужно учитывать и проверять каждый приходящий запрос на состоятельность (то есть каждый 3А-сервер должен иметь в своем распоряжении таблицу IP-адресов известных клиентов). И в TACACS+, и в RADIUS есть такое понятие, как разделяемый секрет (shared secret): это последовательность символов (обычно печатных) произвольной длины, которая используются и клиентом и сервером для шифрования пакетов или паролей. Следовательно, в данную таблицу добавляются еще разделяемые секреты для каждого состоятельного клиента. 
Протокол TACACS+ не допускает наличия файрволла между клиентом и сервером в принципе. Дело все в том, что найти соответствующий разделяемый секрет для обработки пришедшего запроса можно только по IP-адресу клиента, а при работе через файрволл запрос будет приходить всегда с IP файрволла /* ну не всегда, конечно же; автор несколько вольно использует слово файрволл, он наверняка имел в виду прокси или NAT — прим. ред. */. RADIUS — другое дело. Там IP-адрес клиента содержится еще и в самом пакете, поэтому какой адрес использовать 3А-серверу (реальный или внутрипакетный) для поиска разделяемого секрета решать вам, но возможность работы через файрволл есть.
Теперь насчет шифрования: в RADIUS'е шифруется только cleartext-пароли, весь остальной пакет остается "открытым" (с точки зрения безопасности даже имя пользователя является очень важным параметром). В TACACS+ открытым является только заголовок пакета (не несущий никакой ценной информации), а все тело зашифровано. Но у TACACS+, как мне кажется, также есть одна небольшая "дырочка". Состоит она в следующем: TACACS+ поддерживает авторизацию, называемую в документации outbound (т.е. внешняя), то есть само решение аутентифицировать пользователя или нет, принимает клиент. При этом TACACS+ сервер должен прислать клиенту пароль (в том числе есть возможность запроса у сервера cleartext-пароля), а клиент будет сравнивать этот пароль с паролем, введенным пользователем. Вот и получается, что если выполняются следующие условия: 
1.TACACS+ сервер поддерживает эту опцию;
2.TACACS+ сервер не проверяет исходящие адреса приходящих запросов (а даже если и проверяет, IP-адреса могут быть поддельными);
3.Серьезный хакер пронюхал разделяемый секрет (что возможно, поскольку он лежит в открытом виде и на сервере, и на клиенте);
4.Тот же серьезный хакер пронюхал некоторое количество имен пользователей (что в принципе не сложно);
то этот самый взломщик может элементарно узнать пароли из TACACS+ сервера. Как с этим бороться пусть каждый решает сам. Я советую просто не поддерживать данный тип авторизации, поскольку такая возможность по определению является небезопасной — отдавать пароли из базы "наружу" !). 

поддерживаемые типы аутентификации

В этом смысле TACACS+ поддерживает на один тип больше RADIUS'а. Ну с cleartext-аутентификацией все ясно — пароль он и есть пароль, а CHAP и ARAP? Кто не понимает идеи этих типов аутентификации объясню: идея в том, что бы cleartext-ароль ни в каком виде никогда не передавался бы через сеть. А именно: при аутентификации пользователя клиент посылает пользовательской машине некий Challenge (произвольная случайная последовательность символов), пользователь вводит пароль и с этим Challengе'ем пользовательская машина производит некие шифрующий действия используя введенный пароль (как правило это обыкновенное шифрование по алгоритму MD5 (RFC-1321). Получается Response. Этот Response отправляется назад клиенту, а клиент все в совокупности (Challenge и Response) отправляет на аутентификацию 3A-серверу. Тот (также имея на своей стороне пользовательский пароль) производит те же самые действия с Challeng'ем и сравнивает свой Response с полученным от клиента: сходится — пользователь аутентифицирован, нет — извиняйте. Таким образом, cleartext-пароль знают только сам пользователь и 3А-сервер и пароль открытым текстом не "ходит" через сеть и не может быть взломан.

возможность перенаправления запроса

В TACACS+ такая возможность просто отсутствует. RADIUS же имеет такую возможность: RADIUS-сервер должен уметь перенаправлять запрос к другому RADIUS-серверу. Если вдуматься, возможность очень полезная: предположим, что мы продаем доступ к Интернет или услуги Интернет-телефонии (VoIP) и наша единая система имеет представителей в регионах. Купил Петя у нас карточку в городе Саратове и поехал с ней в город Тулу (где также есть наши представители). Хочет он в Туле воспользоваться нашим сервисом и набирает номер, а потом свое имя и пароль (если это доступ к Интернет) или просто несколько цифр кода (если это VoIP). Местный Тулький RADIUS-сервер смотрит на введенные значения и понимает: "пользователь-то наш, да вот только я о нем ничего не знаю, спрошу ка я у того, кто знает" — и перенаправляет запрос к Саратовскому RADIUS-серверу. Тот аутентифицирует нашего Петю, ну и далее обратный путь пакета и поведение Тульского сервера понятно. Таким образом, RADIUS позволяет проектировать гибкую распределенную систему.

Максим Мокроусов, Владислав Пинженин, компания «Сетевые решения».