rfc2865[1] (1027731), страница 4
Текст из файла (страница 4)
Допускается также возврат сервером другого откликаAccess-Challenge.2.2. Взаимодействие с PAP и CHAPДля PAP сервер NAS принимает PAP ID и пароль, передавая их в запросе Access-Request как атрибуты User-Name и UserPassword. NAS может включать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP как указание серверу RADIUS наиспользование сервиса PPP.Для CHAP сервер NAS генерирует случайное число - challenge (предпочтительно 16 октетов) и передает его пользователю,который возвращает CHAP-отклик вместе с CHAP ID и CHAP username. После этого NAS передает запрос Access-Request серверуRADIUS со значением CHAP username для атрибута User-Name и значениями CHAP ID и CHAP-отклик в качестве CHAP-Password(атрибут 3).
Случайное число (challenge) может быть включено в атрибут CHAP-Challenge или (если размер числа равен 16октетам) в поле Request Authenticator пакета Access-Request. Сервер NAS может включать атрибуты Service-Type = Framed-User иFramed-Protocol = PPP как указание серверу RADIUS на использование сервиса PPP.Сервер RADIUS находит пароль для пользователя, указанного атрибутом User-Name, шифрует значение challenge сиспользованием алгоритма MD5, октета CHAP ID, найденного пароля и CHAP challenge (из атрибута CHAP-Challenge или RequestAuthenticator при отсутствии этого атрибута) и сравнивает результат с атрибутом CHAP-Password. При совпадении сервервозвращает Access-Accept, в противном случае - Access-Reject.Если сервер RADIUS не способен выполнить запрошенную идентификацию, он должен возвращать Access-Reject.
Например,CHAP требует чтобы пользовательский пароль был доступен серверу в открытом виде для шифрования CHAP challenge исравнения с откликом CHAP. Если незашифрованный пароль недоступен, сервер RADIUS должен возвращать клиенту AccessReject.2.3. Сервер-посредник (Proxy)При работе в режиме посредника (proxy) сервер RADIUS принимает от клиента (например, NAS) запросы идентификации илиучета и пересылает эти запросы другому серверу RADIUS, а получив от этого сервера отклики, пересылает их клиенту (возможнос внесением изменений в соответствии с локальной политикой администрирования).
Наиболее распространенным вариантом5Аналог обмена “пароль – отзыв”, используемого часовыми. Прим. перев.www.bilim.com4www.protocols.ruПеревод RFC 2865Разумные сети от компании BiLiM Systemsиспользования RADIUS-посредников является организация систем роуминга (roaming), когда два (или более) провайдерапринимают запросы не только от своих клиентов, но и от клиентов своих партнеров.NAS передает серверу RADIUS запрос Access-Request, который сервер-посредник переправляет “удаленному серверу”.Последний возвращает серверу-посреднику отклик (Access-Accept, Access-Reject или Access-Challenge), который пересылаетсяNAS.
Атрибут User-Name может содержать идентификатор NAI[8] для работы с RADIUS Proxy. Выбор сервера, которому будутпересылаться клиентские запросы следует производить на основе областей идентификации (authentication "realm"). Областьидентификации может быть частью идентификатора NAI6 (named realm). Кроме того, возможен выбор сервера для пересылкизапросов на основе других параметров, например, Called-Station-Id (numbered realm).Сервер RADIUS может работать одновременно в режиме посредника (forwarding server) и отвечающего сервера (remote server),выбирая тот или иной режим в зависимости от области идентификации. Один сервер-посредник может пересылать запросынеограниченному числу удаленных серверов.
Точно так же отвечающий сервер может принимать запросы от любого числасерверов-посредников. Сервер-посредник даже может пересылать запросы другому посреднику для создания proxy-цепочек, ноэтого следует остерегаться во избежание возникновения петель.Ниже приведен пример обмена информацией между NAS, сервером-посредником и отвечающим сервером RADIUS:1. NAS передает запрос Access-Request серверу-посреднику.2. Посредник пересылает запрос удаленному серверу.3. Удаленный сервер возвращает посреднику отклик Access-Accept, Access-Reject или Access-Challenge (для нашего примерапусть это будет Access-Accept).4. Посредник передает полученный отклик серверу NAS.Пересылающий сервер должен трактовать имеющиеся атрибуты Proxy-State как непонятные данные (opaque data). Зависимостьработы пересылающего сервера от ранее добавленных атрибутов Proxy-State недопустима.Если атрибуты Proxy-State присутствуют в запросе, полученном от клиента, сервер-посредник должен включить эти атрибуты ввозвращаемый клиенту отклик.
Сервер-посредник может включать атрибуты Proxy-State в Access-Request при пересылке запросаили опускать такие атрибуты при пересылке. Если при пересылке запроса атрибуты Proxy-State были опущены, сервер-посредникдолжен включить их в отклик, возвращаемый клиенту.Рассмотрим этапы процесса более детально.1. NAS передает свой запрос Access-Request серверу-посреднику. Пересылающий сервер расшифровывает значение атрибутаUser-Password (если атрибут присутствует) с использованием известного ему разделяемого ключа для данного NAS.
Если впакете присутствует атрибут CHAP-Password и нет атрибута CHAP-Challenge, пересылающий сервер должен сохранитьатрибут Request-Authenticator неизменным или скопировать его значение в атрибут CHAP-Challenge.Пересылающий сервер может добавить в пакет атрибут Proxy-State, но добавление каких-либо других атрибутов недопустимо.При добавлении атрибута Proxy-State этот атрибут должен помещаться в пакет после всех имеющихся в пакете атрибутовProxy-State. Для пересылающего сервера недопустимо изменение имеющихся в пакете атрибутов Proxy-State (сервер можетотказаться от пересылки этих атрибутов, но менять их недопустимо). Также недопустимо для пересылающего сервераизменять порядок любых однотипных атрибутов, включая Proxy-State.2.
Пересылающий сервер шифрует User-Password (если этот атрибут присутствует) с использованием ключа, разделяемого судаленным сервером, устанавливает значение поля Identifier и передает пакет Access-Request удаленному серверу.3. Удаленный сервер (если он не является посредником) проверяет пользователя с помощью атрибутов User-Password, CHAPPassword или иных методов, которые могут появиться в будущих версиях, и возвращает серверу посреднику пакет AccessAccept, Access-Reject или Access-Challenge.
В нашем примере передается отклик Access-Accept. Удаленный сервер долженскопировать из запроса Access-Request все атрибуты Proxy-State (и только Proxy-State) с сохранением их порядка.4. Сервер-посредник проверяет Response Authenticator с использованием ключа, разделяемого с удаленным сервером, и принесоответствии отбрасывает пакет без уведомления. При успешной проверке пересылающий сервер удаляет последнийатрибут Proxy-State (если он был добавлен), подписывает Response Authenticator с использованием ключа, разделяемого сNAS, восстанавливает Identifier в соответствии с исходным запросом от NAS и передает отклик Access-Accept серверу NAS.Пересылающему серверу может потребоваться изменение атрибутов в соответствии с локальной политикой.
Такие вопросывыходят за пределы данного документа, однако спецификация протокола вносит ряд ограничений на изменение атрибутовпересылающими серверами. Для серверов посредников недопустимо изменять существующие атрибуты Proxy-State, State, Class.Разработчикам таких серверов следует внимательно относиться к принимаемым сервером значениям атрибута Service-Type.Особая осторожность требуется для атрибута Service-Type со значениями NAS-Prompt или Administrative в пересылаемых пакетахAccess-Accept и разработчики могут использовать механизмы блокирования таких сообщений, а также сообщений иных типов.Рассмотрение механизмов блокировки выходит за пределы настоящей спецификации.2.4. Почему UDP?Достаточно часто спрашивают, почему протокол RADIUS использует транспорт UDP, а не TCP. Выбор протокола UDP былобусловлен техническими причинами.Здесь нужно разобраться со множеством вопросов.
Протокол RADIUS работает на основе транзакций, что ведет к рядуинтересных особенностей:1. При отказе основного сервера идентификации запросы должны передаваться резервному серверу.Для выполнения этого требования копия запроса должна сохраняться выше транспортного уровня чтобы обеспечитьвозможность повторного запроса. Это требует поддержки таймеров повтора передачи.2. Временные требования протокола существенно отличаются от обеспечиваемых TCP временных параметров.С одной стороны, RADIUS не требует “нести ответственность” за детектирование потери данных.
Пользователь можетподождать завершения процедуры идентификации в течение нескольких секунд. Не требуется агрессивная политика TCP вчасти передачи повторов (на основе среднего времени кругового обхода), а также передача подтверждений, увеличивающая6Network Access Identifier – идентификатор доступа в сеть.www.bilim.com5www.protocols.ruРазумные сети от компании BiLiM SystemsПеревод RFC 2865уровень служебного трафика.С другой стороны, пользователя вряд ли устроит процедура идентификации, занимающая несколько минут. Следовательногарантированная доставка данных на основе TCP в течение 2 минут не принесет пользы.
Передача запроса альтернативномусерверу позволит пользователю быстрее завершить процедуру идентификации.3. Протокол по своей природе не требует организации прямых соединений.Клиенты и серверы “приходят и уходят”. Системы могут перезагружаться или выключаться. В общем случае это не вызываетпроблем и средства обнаружения обрыва соединений TCP вкупе с механизмами тайм-аутов позволяют обрабатыватьаномальные ситуации. Однако использование протокола UDP полностью избавляет от таких ситуаций без какой-либоспециальной обработки. Каждый клиент или сервер может активизировать свой транспорт UDP и сохранять его в активномсостоянии независимо от возникающих в сети проблем.4. UDP упрощает реализацию серверов.Первые реализации серверов RADIUS были однопотоковыми.
Это означало, что запросы принимались и обрабатывались поодному. Такое решение оказалось неприемлемым для сред, где реализация механизмов безопасности занимала достаточнопродолжительное время (1 секунду или более). Очередь запросов сервера могла содержать достаточно много запросов и всредах, где каждую минуту проверяется идентификация сотен пользователей, пользователи были вынуждены ждатьзавершения идентификации слишком долго. Ожидание увеличивалось дополнительно при обращении к базам данных илисерверам DNS и могло затянуться на 30 секунд и более того. Обычно такие проблемы решаются путем созданиямногопотоковых (multi-threaded) серверов. Реализация таких серверов существенно упрощается при использовании протоколаUDP.
Для обработки каждого запроса порождается отдельный процесс и этот процесс может напрямую взаимодействовать склиентом NAS, обмениваясь с ним пакетами UDP.Однако ничего не достается даром и отказ от использования TCP приводит к необходимости реализации протоколом некоторыхфункций, которые в TCP поддерживаются транспортным уровнем. В частности, при работе по протоколу UDP требуетсяподдержка таймеров повторной передачи для сервера, хотя и не со столь жесткими требованиями, как в TCP. Это достаточноневысокая плата за те преимущества, которые обеспечивает работа на основе протокола UDP.Для протокола RADIUS транспорт UDP является оптимальным решением.2.5.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
