Алгоритмы аутентификации, авторизации и учета radius

Базовая схема работы протокола

При использовании протокола RADIUS-клиентом (NAS-сервером) пользо­ватель должен передать ему свою аутентификационную информацию. Это может производиться посредством приглашения в систему (login promt) или при помощи встроенных механизмов передачи данной информации канальным протоколом (например, РРР). На участке «пользователь - NAS» используются различные технологии передачи необходимых данных, например, РАР [60], CHAP [69], и ЕАР [11].

Обобщенные схемы обмена сообщениями при входе пользователя в систе­му приведены на рис. 2.2 и рис. 2.3.

Рис. 2.2. Процесс обмена сообщениями по протоколу RADIUS, успешный исход

Рис. 2.3. Процесс обмена сообщениями по протоколу RADIUS, неуспешный исход

После получения аутентификационных данных NAS-сервер проводит аутен­тификацию с использованием протокола RADIUS. При этом NAS формирует пакет Access-Request.

Пакет Access-Request передается по сети серверу. Если через некоторое время ответ на него не приходит, то запрос передается повторно.

Защита паролей при передаче по сети обеспечивается благодаря шифро­ванию RSA MD5 с использованием разделяемого ключа (shared secret).

Для каждой пары клиент-сервер имеется свой разделяемый ключ. Он кон­фигурируется администратором и по сети никогда не передается. После получе­ния клиентского запроса RADIUS-сервер проверяет, имеется ли для этого клиента (NAS-сервера) разделяемый ключ. Если он не находит ключа, то пакеты отбрасы­ваются без уведомления. Если проверка завершается успешно, то сервер присту­пает к поиску профиля пользователя в базе данных.

Пользовательская запись (профиль) в базе данных содержит список требо­ваний, необходимых для работы данного клиента с определенным перечнем услуг. К таким требованиям может относиться проверка пароля, порта или идентифика­тора NAS-сервера, через который разрешен доступ к услугам для запросившего услугу пользователя.

RADIUS-сервер в некоторых ситуациях может выступать в качестве пос­редника и пересылать запросы другим серверам. Специфика работы по такой схеме будет раскрыта ниже. При невыполнении любого из условий, приведенных в запросе, NAS-серверу, передается сообщение Access-Reject, показывающее не­корректность запроса пользователя. В сообщение может включаться атрибут или вложенное сообщение, которое должно быть передано пользователю от NAS-сер­вера. При выполнении всех условий NAS-серверу передается сообщение Access- Accept, включая список необходимых конфигурационных параметров.

Схема Challenge/Response

Режим Challenge/Response необходим для проверки прав доступа или за­проса дополнительной информации у пользователя. В случае использования схе­мы Challenge/Response процедура аутентификации пользователя несколько ус­ложняется по сравнению с базовой и выглядит следующим образом. Сервер NAS передает RADIUS-серверу пакет Access-Request с заданными атрибутами, на что тот возвращает ответ - сообщение Access-Challenge. Обычно оно содержит поле Reply-Message, включающее запрос (challenge), который необходимо передать конечному пользователю; это поле заполняется случайным числом специального вида. Запрос обычно получают от внешнего сервера, которому известен иденти­фикатор, используемый пользователем, и который сможет генерировать случай­ное число с подходящим основанием и длиной.

У пользователя, в свою очередь, установлено приложение, которое позво­ляет по имеющемуся запросу вычислить ответ по определенному алгоритму. Этот ответ (вычисленное число) включается в повторный пакет Access-Request наряду с атрибутом State, взятым из запроса. Так делается для того, чтобы сервер смог правильно интерпретировать полученное сообщение. Если отклик совпадает с ожидаемым сервером, то в ответ посылается пакет Access-Accept, иначе переда­ется Access-Reject. В случае необходимости допускается также повторная посыл­ка сервером пакета Access-Challenge. Схематично процедура Challenge/Response изображена на рис. 2.4.

Рис. 2.4. Общая схема реализации режима Challenge/Response для протокола RADIUS

Взаимодействие с технологиями РАР и CHAP

Механизмы аутентификации PAP (Password Authentication Protocol) [60], CHAP (Challenge Handshake Authentication Protocol) [69], а позже - EAP (Extensible Authentication Protocol) [11], были специально разрабо­таны для проведения процедуры аутентификации на участке «пользователь - NAS- сервер». При этом в протокол RADIUS были включены специальные атрибуты [67], [68], которые позволяют прозрачно передавать пользовательские параметры от NAS-сервера на RADIUS-сервер.

При использовании протокола РАР сервер доступа NAS принимает PAP ID и пароль, передавая их в запросе Access-Request на RADIUS-сервер в полях атрибу­тов User-Name и User-Password.

Использование протокола CHAP считается более безопасным методом ау­тентификации, в силу того, что пароль пользователя не передается в этом случае по сети. Для его реализации NAS-сервер генерирует случайное число - challenge (предпочтительно длиной - 16 байтов) и отправляет его пользователю, который генерирует и возвращает СНАР-отклик вместе с CHAP ID и CHAP username.

После этого NAS-сервер передает запрос Access-Request к RADIUS-сер­веру с атрибутом User-Name, содержащим значение CHAP username, и атрибут CHAP-Password с параметрами CHAP ID и СНАР-отклик.

На основании атрибута User-Name сервер RADIUS определяет пароль для пользователя, шифрует значение Challenge, применяя алгоритм MD5 к октету CHAP ID, найденному паролю и CHAP Challenge (из атрибута CHAP-Challenge) и сравнивает полученные результаты с атрибутом CHAP-Password. При совпаде­нии сервер возвращает на NAS-сервер сообщение Access-Accept, в противном случае - Access-Reject. Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он отправляет пакет Access-Reject. Например, требуется, чтобы пользовательский пароль был доступен серверу в открытом виде для шифрования CHAP challenge и сравнения с откликом CHAP. Если правила защиты, установ­ленные в сети, не позволяют использовать незашифрованный пароль, то сервер RADIUS возвращает клиенту сообщение Access-Reject.

Рис. 2.5. Аутентификация при работе технологии CHAP

Работа посредников (прокси) в протоколе RADIUS

Мы рассмотрели работу RADIUS в обычном режиме взаимодействия с клиентами (например, NAS). Теперь, об­судим режим посредника (прокси), когда RADIUS-сервер принимает от клиентов запросы аутентификации и пересылает их дальше другому RADIUS-серверу, а, получив отклик, направляет его обратно отправителю (NAS-серверу).

Наиболее часто посредники (прокси) используются для организации роу­минга между Операторами. В этой ситуации в одном сеансе связи несколько Операторов связи принимают ряд запросов не только от своих пользователей, но и от клиентов своих партнеров, которые необходимо обрабатывать и переправ­лять дальше.

Работа RADIUS-сервера в режиме прокси достаточно проста. NAS передает к RADIUS-серверу запрос Access-Request, который переправляется удаленному серверу. Последний в зависимости от результата прохождения операции аутенти­фикации возвращает ответ. В сообщении обязательно присутствует атрибут User- Name, который может содержать идентификатор NAI (Network Access Identifier) для работы с RADIUS-прокси. Выбор сервера, к которому будут пересылаться запросы, следует производить на основе областей аутентификации (authentication realm). Наименование области аутентификации может быть геа1т-частью NAI. Кроме того возможен выбор сервера для пересылки на основе других параметров, например, Called-Station-ld (numbered realm). На практике чаще всего используется named realm, когда имя пользователя указывает на сервер для пересылки. Наиболее простой метод - это использование имени с явным указанием области, например, master@protei. Значение после @ указывает, к какому серверу необходимо пере­сылать запросы.

RADIUS-сервер может работать одновременно и в режиме посредника (прокси), и в качестве самостоятельно сервера - обработчика сообщений. Режим выбирается в зависимости от области аутентификации. В нашем примере это может выглядеть так: для локальных пользователей в именах не используется символ Втаком случае пользователь, который проходит аутентификацию локаль­но, будет иметь имя master, а пользователь, запросы которого необходимо пересы­лать, - master@protei. Сервер RADIUS может использоваться для пересылки за­просов неограниченному числу удаленных серверов. Отвечающий сервер также может принимать запросы от неограниченного числа посредников.

В стандартизующих документах предусмотрена ситуация, при которой пос­реднику (прокси) разрешено пересылать запрос другому посреднику (прокси), однако, этого не рекомендуется делать во избежание образования петель и уве­личения времени аутентификации. Рассмотрим процесс обмена сообщениями более подробно (рис. 2.6).

NAS передает посреднику запрос Access-Request, в который могут быть включены атрибуты Proxy-State. Сервер-посредник (прокси) должен трактовать эти атрибуты как нераспознаваемые данные (opaque data).

Возможная зависимость функционирования сервера-посредника от содер­жимого этих атрибутов недопустима. Если данный атрибут имеется в запросе, то посредник должен включить его и в отклик. При передаче запроса на следующий узел эти атрибуты могут быть включены в него, или не включены, однако изменять их посредник не имеет права. Прокси-сервер может добавить в пакет новый ат­рибут Proxy-State. При добавлении новый атрибут должен помещаться после уже имеющихся атрибутов Proxy-State, изменение порядка любых однотипных атрибу­тов для сервера-посредника недопустимо.

Рис. 2.6. Использование посредника (прокси) в работе RADIUS

При передаче запроса от NAS-сервера посредник (прокси) с помощью известного ему ключа расшифровывает значение атрибута User-Password (если он присутствует). Если в пакете имеется атрибут CHAP-Password и нет атрибута CHAP-Challenge, то сервер должен сохранить значение Request-Authenticator или скопировать его значение в создаваемый им самим атрибут CHAP-Challenge.

Пересылающий прокси-сервер шифрует User-Password с использовани­ем известного ему разделяемого ключа для удаленного сервера, устанавливает значение поля Identifier и передает пакет Access-Request удаленному серверу. Удаленный сервер (если он является конечным узлом для данного пакета) про­веряет достоверность идентификатора пользователя с помощью User-Password, Chap-Password или другого метода, определяемого будущими расширениями протокола, и возвращает Access-Accept, Access-Reject или Access-Challenge на прокси-сервер. Он должен также скопировать в ответ все атрибуты Proxy-State из запроса с сохранением их порядка.

Прокси производит проверку с использованием разделяемого ключа значе­ние Response-Authenticator и в случае несовпадения отбрасывает его без уведом­ления. При успешной проверке он удаляет последний атрибут Proxy-State, если он был добавлен, подписывает Response-Authenticator в соответствии с разделяе­мым ключом, используемым с NAS-сервером, восстанавливает Identifier в соот­ветствии с исходным запросом и передает его NAS.

Пересылающему серверу (прокси) может потребоваться изменение ат­рибутов в соответствии с локальной политикой, однако эти вопросы выходят за пределы стандарта и зависят от политики защиты, принятой в сети. Единственное ограничение, накладываемое на атрибуты Proxy-State, State и Class, - изменять их посреднику (прокси) недопустимо.

Протокол учета RADIUS (RADIUS Accounting)

Процедура учета работы пользователя является одним из наиболее рас­пространенных механизмов протокола RADIUS и очень часто используется Операторами для начисления платы за услуги связи, оказываемые своим абонен­там, и для отслеживания их работы в сети.

Общая схема реализации процедуры учета приведена на рис. 2.7. В слу­чае, когда клиент (NAS-сервер) настроен на использование процедуры RADIUS accounting на начальном этапе, он передает пакет Accounting-Request Start (т.е. Acct-Status-Type = start), описывающий тип предоставляемой услуги. RADIUS-сер­вер должен сформировать и отправить соответствующий отклик на него.

При завершении пользовательского сеанса NAS-сервер генерирует пакет Accounting-Request Stop, который может содержать статистические данные о сес­сии - продолжительность сеанса, число пакетов и байтов, принятых и переданных пользователем. В ответ RADIUS-сервер также должен отправить необходимый отк­лик. В случае отсутствия ответного сообщения клиенту (NAS-серверу) рекомен­дуется повторять передачу пакета Accounting-Request до тех пор, пока не будет получен ответ от RADIUS-сервера.

Клиент может также переслать запрос резервным RADIUS-серверам, если основной сервер не работает или недоступен. Если RADIUS-сервер не может запи­сать пакет учета, то он не должен посылать отклик. В механизме учета предусмот­рена возможность использования RADIUS-серверов в режиме прокси.

Рис. .2.7. Обмен сообщениями по протоколу RADIUS Accounting

Алгоритм работы сервера-посредника RADIUS в режиме accounting приве­ден ниже:

Шаг 1. NAS передает пакеты Accounting-Request пересылающему RADIUS- серверу (прокси).

Шаг 2. Пересылающий сервер, в свою очередь, протоколирует пакет Accounting-Request, добавляет атрибут Proxy-State (если в этом есть необходи­мость) после имеющихся в пакете атрибутов Proxy-State, обновляет значение Request Authenticator и пересылает запрос удаленному серверу.

Шаг 3. Удаленный сервер протоколирует пакет Accounting-Request, копиру­ет все атрибуты Proxy-State, не изменяя их порядка, в пакет отклика и передает отклик Accounting-Response прокси-серверу.

Шаг 4. Пересылающий прокси-сервер удаляет из пакета последний атри­бут Proxy-State (если он был добавлен на шаге 2), обновляет значение Response Authenticator и передает пакет Accounting-Response NAS-серверу.

Для прокси-сервера недопустимо изменение присутствующих в пакете атрибутов Proxy-State или Class. Прокси-сервер может прозрачно пересылать пакеты, передавая повторные пакеты по мере их получения, или принять на себя ответственность за передачу повторных пакетов (это удобно в тех случаях, когда сетевое соединение между посредником и удаленным сервером по своим харак­теристикам существенно отличается отсоединения между посредником и NAS).