Взаимодействие с технологиями рар и 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, - изменять их посреднику (прокси) недопустимо.