Авторизация:
E-Mail: Пароль:
Закрыть
RU | EN

к

Опубликовано: 2018-10-09 02:48:55
Этот текст доступен по адресу: http://ontext.info/105425
Реферат представляет собой самостоятельную работу, Реферат должен включать в себя:

- постановку задачи (краткую характеристику изучаемой проблемы, ее актуальность),

- перечень просмотренных источников и их краткое описание (резюме статьи или сведения о содержании книги),

- изложение проблемы, содержащее конкретные материалы по теме реферата, например, численные характеристики, статистические данные, алгоритмы процедур, рисунки, графики, технико-экономические показатели и т.п.

- краткие выводы.

Объем реферата должен составлять от 10 до 12 страниц.
Архитектура RADIUS


------------------------------------------------

История появления и становления протокола с оригинальным названием RADIUS являет собой пример кропотливой работы и постоянного совершенствования, которые привели к широкому распространению этой технологии в самых разнообразных сетях связи по всему миру. Название протокола складывается из первых букв слов - Remote Authentication Dial In User Service (услуги дистанционной аутентификации вызывающего пользователя). Это определение описывает скорее область, где чаще всего применяется протокол RADIUS: аутентификация подключений пользователей к серверу для получения доступа у Оператора связи, что упоминалось выше

Разработка протокола была начата в далеком 1989 году фирмой Livingston, специализирующейся на производстве серверов удалённого доступа. Протокол оказался интересным и перспективным проектом, который заметили и взяли на доработку специалисты из Мичиганского университета. А уже оттуда документация и все работы по описанию и оформлению технологии перешли в IETF. Работы по специфиации RADIUS увенчались успехом и были оформлены в виде двух базовых документов .С этого времени RADIUS стал и продолжает оставаться открытым стандартом, что обеспечило ему популярность среди производителей оборудования и возможность его доработки и модернизации. Сегодня RADIUS является одним из самых распространенных ААА-протоколов, используемых в сетях самых разных Операторов связи и провайдеров телекоммуникационных услуг. В этой главе рассмотриваются особенности, архитектура и структура организации протокола RADIUS.
Архитектура RADIUS
RADIUS представляет собой протокол, соответствующий архитектуре «клиент-сервер». Обмен сообщениями производится поверх протокола транспортного уровня UDP. Заметим, что использование UDP диктует необходимость реализации схем контроля доставки и повторной передачи средствами самого протокола RADIUS.

Общая схема взаимодействия элементов в архитектуре RADIUS представлена на рис. 2.1. Структурными единицами, участвующими в работе протокола являются:

RADIUS-cервер – элемент, отвечающий за прием клиентских запросов, аутентификацию и авторизацию пользователей, и возврат клиенту всех параметров, необходимых для предоставления услуги. Кроме того, он может выступать в качестве посредника (прокси) для других RADIUS-серверов или серверов иного типа.
Сервер доступа к сети NAS (Network Access Server) выступает в качестве клиента протокола RADIUS, отвечает за передачу информации о пользователе системы RADIUS-серверу и проведение дальнейших действий в соответствии с полученным ответом.
Пользователь – напрямую не входит в архитектуру RADIUS, но является неотъемлемой частью всей цепи взаимодействия. Подключается к NAS для передачи информации авторизации, аутентификации и учета.


Рис. 2.1. Архитектура протокола RADIUS

В протоколе RADIUS реализована схема авторизации, упомянутая в 1.2, согласно которой каждый из пользователей пытается получить доступ к услуге через NAS. При этом каждый из серверов доступа имеет связь не менее чем с одним сервером RADIUS. Однако их может быть и больше (как изображено на рис. 2.1). В этом случае они объединяются в кластер из нескольких серверов, который обычно использует специальные средства для распределения нагрузки между ними, например, по дисциплине RR (Round Robin), или для резервирования оборудования, на случай возникновения неисправностей. Кроме того, любой этот сервер может выступать посредником (прокси) по отношению к другим серверам.

Для своей работы протокол RADIUS использует стандартный порт 1812, а для расширения RADIUS Accounting выделен порт 1813. Кроме того для специального расширения RADIUS Dynamic Authorization Client [14] принято использовать порт 3799. Интересно, что в первых версиях протокола использовались порты 1645 и 1646, однако, это приводило к возникновению конфликтов с так называемыми службами Datametrics, поэтому в новой версии протокола порт был изменен.

В качестве транспортного протокола, как уже было сказано, используется протокол UDP. Его выбор обосновывается следующими обстоятельствами:

Необходимость повторной передачи запроса на резервный сервер требует, чтобы реализация RADIUS-протокола сохраняла копию отправленного запроса на прикладном уровне. При этом возникает необходимость добавления таймеров повторной посылки. Так как повторные посылки в таком случае контролируются выше транспортного уровня, RADIUS проще реализуется поверх протокола UDP.
Временные характеристики протокола UDP в значительной степени отличаются от временных характеристик TCP. С одной стороны, RADIUS не требует «мгновенного» детектирования проблемы на транспортном уровне (то есть детектирование за время порядка десятков или даже сотен миллисекунд не требуется). Время ожидания порядка одной-двух секунд вполне устроит пользователя, выполняющего аутентификацию. В этом отношении политика повторной передачи TCP с подтверждениями транспортного уровня является избыточной для задач, выполняемых протоколом RADIUS. С другой стороны, проблемы в сети, вызывающие рост параметра Round Trip Time (RTT), могут стать причиной слишком долгой доставки информации поверх TCP, так как механизм повторных посылок TCP протокола базируется на параметре RTT. В подобной ситуации быстрее переслать запрос на резервный сервер поверх ненадежного протокола UDP и получить ответ на запрос аутентификации.
Протокол RADIUS, как протокол без сохранения состояния, гораздо проще реализовать поверх UDP. В условиях «живой» сети клиенты и серверы RADIUS могут появляться и исчезать – плановые или аварийные перезагрузки, сетевые проблемы и прочие обстоятельства приводят к тому, что транспортные соединения TCP-протокола по разным причинам будут требовать переустановки или полного закрытия соединения. Это не является серьезной проблемой при грамотном конфигурировании процедур проверки соединений и таймеров повторных посылок, однако проще вообще исключить необходимость контроля состояния узлов в сети, используя UDP, в котором отсутствует понятие постоянного соединения.
UDP упрощает реализацию сервера. Ранние реализации серверов RADIUS были однопоточными, что подразумевало последовательную обработку запросов. При росте сетевой инфраструктуры стало понятно, что однопоточные серверы не могут выдерживать нагрузку, когда время обработки одного запроса имеет порядок секунд (при выполнении поиска в базе данных или при DNS-запросе). Переполнение очереди на обработку запросов пользователей в таком случае приведет к тому, что процедура аутентификации будет продолжаться полминуты и более, что является неприемлемым для конечного пользователя. Очевидным выходом из сложившейся ситуации стало использование многопоточных серверов, реализация которых проще выполнялась поверх UDP. Обработка запроса производится в рамках отдельного процесса, который отвечает на данный запрос UDP пакетом без какого-либо контроля TCP-соединений.
Следует отметить, что многие из перечисленных вопросов обеспечения надежной доставки ААА-информации обсуждались в процессе выбора протокола транспортного уровня для ААА-протокола нового поколения Diameter, о чем ниже. При этом были подняты такие вопросы как переход на резервные серверы, повторная посылка информации, обнаружение дублирующихся данных, разделение нагрузки и др. Результаты данной работы в 2003 году были оформлены в виде отдельной RFC 3539 . Кроме того, на момент стандартизации Diameter уже был разработан надежный протокол транспортного уровня SCTP (Stream Control Transmission Protocol), который включал в себя новые механизмы резервирования и проверки состояния соединений. В результате протокол Diameter стандартно работает поверх транспортных протоколов с надежной доставкой информации как SCTP, так и TCP, функционирование которых подразумевает установку и поддержание постоянного соединения. К этому вопросу мы вернемся ниже.
2.3. Общая схема взаимодействия при использовании протокола RADIUS
В ситуации, когда пользователи используют протокол RADIUS, каждый из них должен предоставить клиенту свою аутентификационную информацию. Это может выполняться в форме приглашения на вход в систему (login prompt), где пользователь должен ввести свое регистрационное имя и пароль. Другим вариантом может быть использование канальных протоколов типа PPP3, в которых поддерживаются специальные пакеты идентификации для передачи сведений о пользователе.

После того как клиент получит идентификационные данные пользователя, он имеет право провести процесс аутентификации с использованием RADIUS. Для этого клиент создает пакет Access-Request, содержащий такие атрибуты, как регистрационное имя пользователя, пароль, идентификатор клиента и порта (Port ID), через который регистрируется в системе данный пользователь; более подробное описание атрибутов будет приведено ниже. При наличии пароля он кодируется с использованием алгоритма RSA MD5, рассматриваемого ниже в этой главе.

Пакет Access-Request передается RADIUS-серверу через сеть. Если в течение продолжительного времени на запрос не будет получено отклика, передача запроса повторяется некоторое количество раз. Клиент может также пересылать запросы другим серверам в тех случаях, когда основной сервер не работает или недоступен. Дополнительные (альтернативные) серверы могут использоваться после некоторого числа неудачных попыток или в режиме кругового обхода известных серверов. Количественные характеристики этих алгоритмов зависят от конкретных реализаций оборудования производителями.

После получения клиентского запроса RADIUS-сервер производит проверку передавшего этот запрос клиента. Запросы от клиентов, для которых сервер RADIUS не имеет разделяемого ключа, отбрасываются без уведомления. Если проверка клиента завершилась успешно, RADIUS-сервер обращается к базе данных о пользователях для поиска указанного в запросе имени.

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

При невыполнении какого-либо из условий при обработке сообщений RADIUS-сервер передает отклик Access-Reject, показывающий некорректность пользовательского запроса. При желании сервер может включать в Access-Reject текстовое сообщение. Никакие иные атрибуты (за исключением Proxy-State) не могут включаться в Access-Reject.

Если все условия выполнены, и RADIUS-сервер хочет узнать дополнительную информацию, то он передает отклик Access-Challenge. Этот отклик может включать текстовое сообщение, выводимое клиентом для пользователя с приглашением ответить на вопросы сервера.

Если клиент получает отклик Access-Challenge и поддерживает режим challenge/response, он может вывести текстовое сообщение (если таковое имеется в пакете отклика) для пользователя. После этого клиент снова передает первоначальный запрос Access-Request с новым идентификатором (request ID), атрибутом User-Password и атрибутом State из Access-Challenge (если этот атрибут присутствовал в отклике). Сервер может передать в ответ на новый запрос Access-Request отклик типа Access-Accept, Access-Reject или Access-Challenge.

При выполнении всех условий в отклик Access-Accept включается список всех конфигурационных параметров для данного пользователя. К таким параметрам относятся тип сервиса, например, SLIP, PPP, Login User, и все требуемые для предоставления этого сервиса значения. Для протоколов SLIP и PPP могут включаться параметры IP-адреса, маски подсети, MTU и другие. Для терминальных пользователей эти параметры могут указывать желаемый протокол и хост.

При использовании режима challenge/response пользователю передается случайное число и ожидается возврат зашифрованного отклика на это число. У легитимных пользователей имеется специальное устройство (например, смарт-карта) или программа для вычисления корректного отклика. Пользователь, не имеющий нужного устройства или программы и не знающий секретного ключа, который позволит эмулировать устройство/программу, может лишь попытаться угадать правильный отклик.

Пакет Access-Challenge обычно содержит атрибут Reply-Message, содержащий передаваемый пользователю запрос (challenge), в качестве которого могут использоваться редко повторяющиеся числа. Обычно запрос получают от внешнего сервера, которому известен тип идентификатора, доступного пользователю и который, следовательно, может выбрать случайное или редко повторяющееся число с подходящим основанием и длиной. Пользователь вводит это число в свое устройство (или программу), вычисляющее отклик, которого ожидает сервер RADIUS во втором запросе Access-Request. Если полученное от пользователя значение соответствует ожидаемому, RADIUS-сервер возвращает отклик Access-Accept, а при несоответствии – отклик Access-Reject.
2.4. Алгоритмы аутентификации, авторизации и учета RADIUS
2.4.1. Базовая схема работы протокола

При использовании протокола RADIUS клиентом (NAS-сервером) каждый пользователь должен передать ему свою аутентификационную информацию. Это может производиться посредством приглашения в систему (login promt) или при помощи встроенных механизмов передачи данной информации канальным протоколом (например, РРР). На участке «пользователь - NAS» используется множество различных технологии передачи необходимых данных. Обобщенные схемы обмена сообщениями при входе пользователя в систему приведены на рис. 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, включая список необходимых конфигурационных параметров.

2.4.2. Схема 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

2.4.3. Взаимодействие с технологиями PAP и CHAP

Механизмы аутентификации PAP (Password Authentication Protocol) , CHAP (Challenge Handshake Authentication Protocol) , а позже - EAP (Extensible Authentication Protocol) были специально разработаны для проведения процедуры аутентификации на участке «пользователь – NAS-сервер». При этом в протокол RADIUS были включены специальные атрибуты, которые позволяют прозрачно передавать пользовательские параметры от NAS-сервера на RADIUS-сервер. Использование технологий PAP, CHAP и EAP позволило значительно обезопасить процесс обмена информацией между пользователем и NAS-сервером и упростить процесс аутентификации.

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

Использование алгоритма CHAP значительно повышает защиту передаваемой информации за счет шифрования и использования дополнительных параметров. Для его реализации NAS-сервер генерирует случайное число — challenge (предпочтительно длиной – 16 байтов) и отправляет его пользователю, который генерирует и возвращает CHAP-отклик вместе с CHAP ID и CHAP username. После этого NAS-сервер передает запрос Access-Request к RADIUS-серверу с атрибутом User-Name, содержащим значение CHAP username, и атрибут CHAP-Password с параметрами CHAP ID и CHAP-отклик.

На основании атрибута 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.

Как видно из описания процедуры, при использовании метода CHAP пароль пользователя вообще не передается по сети, что значительно увеличивает защиту конфиденциальности работы абонента. Однако этот алгоритм также значительно увеличивает нагрузку сети за счет увеличения числа передаваемых пакетов на RADIUS-сервер и их размера. Кроме того, увеличивается время обработки запроса, так как серверу приходится дополнительно вычислять отклик. Это накладывает также дополнительные ограничения на форму хранения пароля в базе данных сервера: пароль должен быть доступен в открытом виде, что тоже может быть брешью в безопасности.

Пример процедуры CHAP приведен на рис. 2.5.



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

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

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

Работа RADIUS-сервера в режиме прокси достаточно проста. NAS передает к RADIUS-серверу запрос Access-Request, который переправляется удаленному серверу. Последний в зависимости от результата прохождения операции идентификации возвращает ответ. В сообщении обязательно присутствует атрибут User-Name, который может содержать идентификатор NAI (Network Access Identifier) для работы с RADIUS-прокси. Выбор сервера, к которому будут пересылаться запросы, следует производить на основе областей аутентификации (authentication realm). Наименование области аутентификации может быть частью общего идентификатора NAI (named realm). Кроме того возможен выбор сервера для пересылки на основе других параметров, например, Called-Station-Id (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 удаленному серверу.

Удаленный сервер (если он не является прокси) проверяет с использованием определенного механизма идентичность пользователя и возвращает прокси-серверу пакет Access-Accept, Access-Reject или Access-Challenge, в зависимости от исхода проверки. Он должен также скопировать в ответ все атрибуты Proxy-State из запроса с сохранением их порядка.

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

2.4.5. Учет (Accounting) при помощи протокола RADIUS

Процедура учета работы пользователя (аккаунтинг) является одним из наиболее распространенных механизмов протокола 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-серверов в режиме прокси. Алгоритм работы сервера-посредника 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).

В общем случае серверы RADIUS для целей авторизации или аутентификации и RADIUS-серверы учета являются совершенно независимыми. Однако зачастую они используются совместно на одном физическом сервере, поскольку функции, выполняемые двумя логическими серверами очень плотно взаимосвязаны.



Рис. 2.7. Базовый алгоритм обмена сообщениями в режиме учета для протокола RADIUS
2.5. Сообщения и атрибуты RADIUS
2.5.1. Формат соощения

Вся информация, отражающая формат сообщений прокола RADIUS, их наполнение и последовательность передачи, приведена в документах IETF

Правила передачи сообщений RADIUS определяют, что в каждый пакет UDP инкапсулируется одно сообщение RADIUS, которое после обработки передается на стандартный порт 1812. Для функции учета (accounting) используется порт 1813, который заменил ранее использовавшийся порт 1646 по причинам, упомянутым в предыдущем параграфе (п.п. 2.2).

Ниже на рис. 2.8 приведен формат пакета RADIUS. Последовательность полей необходимо передавать слева направо, сверху вниз.



Рис.2.8. Формат сообщения протокола RADIUS

2.5.1.1. Поле Code

Поле code имеет размер 1 байт и содержит информацию о типе передаваемого пакета RADIUS. Поле является первичным при проверке сообщения. При получении пакета с некорректным значением типа, такие пакеты отбрасываются без уведомления. Значения кодов приведены в таблице 2.1.



Табл. 2.1. Сообщения протокола RADIUS

Код

Тип пакета

1

Access-Request

2

Access-Accept

3

Access-Reject

4

Accounting-Request

5

Accounting-Response

11

Access-Challenge

12

Status-Server (экспериментальный)

13

Status-Client (экспериментальный)

40

Disconnect-Request [RFC3576]

41

Disconnect-ACK [RFC3576]

42

Disconnect-NAK [RFC3576]

43

Change-of-Authorization-Request [RFC3576]

44

Change-of-Authorization-ACK [RFC3576]

45

Change-of-Authorization-NAK [RFC3576]

255

Резервирован



2.5.1.2. Поле Identifier

Это поле имеет размер 1 байт. Поле предназначено для сопоставления запросов с откликами. Сервер RADIUS может обнаружить повторные запросы по совпадению комбинации IP-адреса и номера порта отправителя со значением поля Identifier, если такие пакеты получены в течении короткого промежутка времени.

2.5.1.3. Поле Length

Поле Length имеет размер 2 байта и содержит значение общего размера всего пакета, начиняя с поля Code. Если длина пакета превышает величину, указанную в данном поле, то оставшиеся октеты трактуются как заполнение и информационной нагрузки не несут. Если размер пакета меньше указанного в Length, то такие пакеты отбрасываются без уведомления.

2.5.1.4. Поле Autenticator

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

2.5.1.5. Поле Request Autenticator

Поле Autenticator в пакетах Access-Request в качестве значения использует 16-байтовое случайное число. В целях безопасности следует, чтобы это число было непредсказуемым и уникальным в течении срока жизни ключа (secret). Хотя протокол RADIUS не обеспечивает защиту сеансов от перехвата путем прямого прослушивания, использование уникальных и непредсказуемых запросов защищает от множества типов атак на систему аутентификации пользователей.

2.5.1.6. Поле Response Autenticator

Поле Autenticator в пакетах Access-Accept, Access-Reject и Access-Challenge называют Response Autenticator. Это поле содержит необратимое хэш-значение MD5, рассчитанное из пакета RADIUS и разделяемого ключа.

Вычисляется значение по следующей формуле:

ResponseAuth = MD5(Code ID Length RequestAuth Attributes Secret),

где знак означает конкатенацию (объединение) строк.

Разделяемый ключ следует создавать с использованием обычных правил, предъявляемых к паролям. Предпочтительно использовать ключи длиной не менее 16 байтов. Использование пустых ключей недопустимо, поскольку в этом случае перехват пакетов и их дешифровка становится слишком простой задачей для возможного злоумышленника.

Для выбора используемого разделяемого ключа сервер RADIUS должен использовать IP-адрес отправителя. При использовании посредников (прокси) он должен отличать направление передачи пакета. При пересылке запросов посредник может добавить атрибут Proxy-State, а при пересылке ответа должен его удалить. Удаляемый или добавляемый атрибут является последним в списке одноименных атрибутов. При изменении содержимого пакета сигнатура становится некорректной, и сервер должен снова подписать пакет.

2.5.2. Типы пакетов

2.5.2.1. Access-Request

Пакеты Access-Request передаются в сторону RADIUS-сервера и содержат информацию для определения права пользователя на доступ к указанному серверу NAS и запрошенным службам. Данный пакет имеет поле Code=1.

При получении пакета Access-Request от подключенного клиента (NAS-сервера) ему должен передаваться соответствующий отклик. Пакет должен содержать один из атрибутов User-Password, CHAP-Password или State (в документах IETF рекомендуется использовать User-Password). Недопустимо помещать атрибуты User-Password и CHAP-Password в один запрос. Пакет должен также содержать один из атрибутов NAS-IP-Address и NAS-Identifier.

В пакет следует включать атрибут NAS-Port или NAS-Port-Type, за исключением случаев, когда запрашиваемый тип доступа не имеет портов или NAS их не различает.

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

2.5.2.2. Access-Accept

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

При получении пакета Access-Accept (Code=2) клиентом сначала необходимо сравнить значение поля Identifier и порта с ожидаемым запросом. Поле Response Autenticator должно также содержать корректный отклик. Некорректные пакеты отбрасываются без уведомления.

2.5.2.3. Access-Reject

Если какой-либо из атрибутов в запросе некорректен, RADIUS-сервер должен послать пакет с Code=3 (Access Reject). В пакет может быть включен один или несколько атрибутов Reply-Message с текстовым сообщением для отображения его пользователю. Поле Autenticator должно содержать корректный отклик.

2.5.2.4. Access-Challenge

Если сервер хочет отправить пользователю запрос на ввод дополнительной информации, он передает пакет с Code=11 (Access Challenge).

Опциональное поле атрибутов такого пакета может содержать один или несколько атрибутов Reply-Message и один атрибут State. Допускается также наличие атрибутов Vendor-Specific, Idle-Timeout, Session-Timeout и Proxy-State. Больше никаких атрибутов присутствовать в этом пакете не может.

При получении пакета Access-Challenge значение поля Identifier и номера порта сравнивается с ожидаемым значением поля из запроса Access-Request. Поле Autenticator должно содержать корректный отклик. Некорректные пакеты отбрасываются без уведомления. Если NAS не поддерживает режим challenge/response, он должен трактовать такой пакет как Access-Reject.

Если режим challenge/response поддерживается, то при получении пакета этого типа следует передать новый пакет Access-Request, в этом случае NAS-сервер может передавать пользователю текстовое сообщение (если есть необходимость). После получения Access-Challenge передается исходный запрос Access-Request с новым значением идентификатора сессии, полем Response Autenticator, User-Password, введенный пользователем, и с включением атрибута State из пакета Access-Challenge (если этот атрибут присутствует). В пакете Access-Request может быть не более одного атрибута State.

2.5.2.5. Accounting-Request

Пакеты Accounting-Request передаются от NAS к RADIUS-серверу и содержат информацию, используемую для учета предоставляемых пользователю услуг. Для них используется значение Code=4. При получении такого пакета сервер должен передать отклик, если он записал информацию. Если при обработке были выявлены ошибки, то отклик не должен передаваться. Атрибуты, допустимые для Access-Request и Access-Accept, могут передаваться и в Accounting-Request, однако в них недопустимо использование атрибутов User-Password, CHAP-Password, Reply-Message, State. В каждом пакете Accounting-Request должен присутствовать один из атрибутов NAS-IP-Address или NAS-Identifier. В пакеты следует включать атрибуты NAS-Port или NAS-Port-Type, если NAS способен различать свои порты.

Если пакет Accounting-Request содержит атрибут Framed-IP-Address, то он должен содержать фактический IP-адрес пользователя. В принципе, этот атрибут должен содержаться в пакете только для поддержания функций СОРМ.

2.5.2.6. Accounting-Response

Пакеты Accounting-Response передаются сервером клиенту в качестве подтверждения успешной доставки пакета Accounting-Request. Если принятый пакет записан без ошибок, RADIUS-сервер должен передать пакет Accounting-Response с Code=5. При получении такого пакета клиент проверяет его идентификатор и удаляет из очереди ожидания пакет, которому этот ответ соответствует.

2.5.2.7. Disconnect-Request

Сообщение Disconnect-Request посылается RADIUS-сервером для завершения пользовательской сессии на NAS и закрытия всех связанных с ней, соединений. Для пакета Disconnect-Request используется Code=40.

Пакет передается поверх UDP протокола на порт 3799 [RFC 5176]. В сообщении содержатся идентификационные атрибуты, которые позволяют закрыть на NAS-сервере сеанс связи определенного пользователя.

2.5.2.8. Disconnect-ACK

Сообщение Disconnect-ACK передается NAS-сервером на RADIUS-сервер в случае, если все операции по завершению сеанса связи и закрытию соединения в ответ на сообщение Disconnect-Request прошли успешно. Сообщению Disconnect-ACK соответствует поле Code=41. В сообщении Disconnect-ACK может содержаться атрибут Acct-Terminate-Cause [68].

2.5.2.9. Disconnect-NAK

Сообщение Disconnect-NAK передается NAS-сервером в случае, если при совершении операции по завершению сеанса связи и закрытию соединения произошли сбои или ошибки. Сообщению Disconnect-NAK соответствует поле Code=42.

В сообщении Disconnect-NAK должен содержаться атрибут Service-Type со значением, не поддерживаемым на RADIUS-сервере. Кроме того, сообщение может содержать атрибут Error-Cause со значением «Unsupported Service».

2.5.2.10. Сhange-of-Authorization Messages (CoA) Request

Сообщение Change-of-Authorization Request содержит информацию, необходимую для динамического изменения авторизационных данных пользователя в рамках конкретной сессии. Обычно оно используется для изменения специализированных фильтров данных. Фильтры данных могут использоваться для входящих или исходящих потоков, и они отправляются дополнительно к атрибутам идентификации. Для этого сообщения используется тот же порт, что и для сообщения Disconnect-Request. Сообщению Change-of-Authorization Request соответствует поле Code=43.

В сообщении могут присутствовать атрибуты Filter-ID, которые содержат наименования фильтров данных, используемых в данном сеансе связи.

2.5.2.11. Change-of-Authorization Messages (CoA) ACK

Сообщение отправляется NAS на RADIUS-сервер в ответ на Change-of-Authorization Request в случае, если изменение авторизации пользовательской сессии произошло успешно. Code=44.

2.5.2.12. Change-of-Authorization Messages (CoA) NAK

Сообщение отправляется NAS на RADIUS-сервер в ответ на Change-of-Authorization Request в случае, если изменение авторизации пользовательской сессии не произошло. Code=45.

2.5.3. Формат атрибутов в RADIUS

Атрибуты в протоколе RADIUS служат для передачи сведений, используемых при идентификации, проверки полномочий, конфигурации, а также для передачи пользователю той или иной информации. Некоторые атрибуты могут включаться в пакет в нескольких экземплярах. Смысл этого зависит от типа и названия атрибута и будет описан ниже. Завершение списка атрибутов определяется в соответствии со значением поля Length в пакетах RADIUS.

При наличии в пакете нескольких однотипных атрибутов серверы прокси должны сохранять порядок их следования. Сохранение порядка следования разнотипных атрибутов не требуется. Для серверов и клиентов недопустимо принятие каких-либо решений на основе порядка расположения разнотипных атрибутов.

Атрибуты протокола RADIUS имеют нумерацию, определенную IETF в соответствующих стандартах, со следующими значениями:

значения от 0 до 191 – определены в стандартах или резервированы для дальнейших разработок;
значения от 192 до 223 – резервированы для экспериментальных целей;
значения от 224 до 240 – резервированы для специального использования;
значения от 241 до 255 – резервированы и не могут использоваться.
В этом разделе главы 2 рассматривается только базовый протокол и пакеты Access-Request, Access-Accept, Access-Reject и Access-Challenge. Дополнительные атрибуты для приложений и расширений протокола, например, для средств учета или для динамической авторизации RADIUS, будут приведены ниже в следующих разделах этой же главы. Такие атрибуты могут включаться в разные сообщения, о которых будет упомянуто отдельно в описании каждого атрибута. Формат поля атрибута показан ниже на рис. 2.9.



Рис. 2.9. Формат атрибута для протокола RADIUS



2.5.3.1. Поле Type

Однобайтное поле, определяющее тип атрибута. Тип описывается целым числом, значение которого однозначно определено в стандартах для RADIUS. Производители оборудования могут разрабатывать свои атрибуты, уникальные для своих устройств. Однако эти параметры передаются внутри специально выделенного для этого атрибута Vendor-Specific.

Если клиенту или серверу были переданы атрибуты неизвестных типов, то они могут их игнорировать для поддержания работы системы. Наименования всех атрибутов для базового протокола (без учета атрибутов, разработанных разными производителями для своего оборудования) представлены в табл. 2.2.

Табл. 2.2. Значения атрибутов RADIUS для базового протокола

Тип

Атрибут

1

User-Name

2

User-Password

3

CHAP-Password

4

NAS-IP-Address

5

NAS-Port

6

Service-Type

7

Framed-Protocol

8

Framed-IP-Address

9

Framed-IP-Netmask

10

Framed-Routing

11

Filter-Id

12

Framed-MTU

13

Framed-Compression

14

Login-IP-Host

15

Login-Service

16

Login-TCP-Port

17

(не используется)

18

Reply-Message

19

Callback-Number

20

Callback-Id

21

(не используется)

22

Framed-Route

23

Framed-IPX-Network

24

State

25

Class

26

Vendor-Specific

27

Session-Timeout

27

Idle-Timeout

29

Termination-Action

30

Called-Station-Id

31

Calling-Station-Id

32

NAS-Identifier

33

Proxy-State

34

Login-LAT-Service

35

Login-LAT-Node

36

Login-LAT-Group

37

Framed-AppleTalk-Link

38

Framed-AppleTalk-Network

39

Framed-AppleTalk-Zone

40

Acct- Status- Type

41

Acct-Delay- Time

42

Acct-Input-Octets

43

Acct-Output-Octets

44

Acct-Session-Id

45

Acct-Authentic

46

Acct-Session-Time

47

Acct-Input-Packets

48

Acct-Output-Packets

49

Acct- Terminate- Cause

50

Acct-Multi- Session-Id

51

Acct-Link-Count

52

Acct-Input-Gigawords

53

Acct-Output-Gigawords

55

Event-Timestamp

56

Egress-VLANID

57

Ingress-Filters

58

Egress-VLAN-Name

59

User-Priority-Table

60

CHAP-Challenge

61

NAS-Port-Type

62

Port-Limit

63

Login-LAT-Port

70

ARAP-Password

71

ARAP-Features

72

ARAP-Zone-Access

73

ARAP-Security

74

ARAP-Security-Data

75

Password-Retry

76

Prompt

77

Connect-Info

78

Configuration-Token

79

EAP-Message

80

Message-Authenticator

84

ARAP-Challenge-Response

85

Acct-Interim-Interval

87

NAS-Port-Id

88

Framed-Pool

92

NAS-Filter-Rule

95

NAS-IPv6-Address

96

Framed-Interface-Id

97

Framed-IPv6-Prefix

98

Login-IPv6-Host

99

Framed-IPv6-Route

100

Framed-IPv6-Pool

101

Error-Cause

103

Digest-Response

104

Digest-Realm

105

Digest-Nonce

106

Digest-Response-Auth

107

Digest-Nextnonce

108

Digest-Method

109

Digest-URI

110

Digest-Qop

111

Digest-Algorithm

112

Digest-Entity-Body-Hash

113

Digest-CNonce

114

Digest-Nonce-Count

115

Digest-Username

116

Digest-Opaque

117

Digest-Auth-Param

118

Digest-AKA-Auts

119

Digest-Domain

120

Digest-Stale

121

Digest-HA1

122

SIP-AOR

133

Framed-Management-Protocol

134

Management-Transport-Protection

135

Management-Policy-Id

136

Management-Privilege-Level

2.5.3.2. Поле Length

Поле Length, длиной один байт, указывает размер атрибута с учетом полей Type, Length и Value. При получении в пакете Access-Request атрибута с некорректно указанным размером в поле Length в ответ на него следует передать сообщение Access-Reject. При получении NAS-сервером атрибута с некорректно указанным размером в пакетах Access-Accept, Access-Reject или Access-Challenge пакет должен трактоваться как Access-Reject или отбрасываться без уведомления.

2.5.3.3. Поле Value

Опциональное поле Value содержит значение различных данных, передаваемых в атрибуте. Формат и размер значения определяются полями Type и Length.

Ни один из типов данных протокола RADIUS не использует в качестве завершения параметр NULL (hex 00). Для каждого атрибута имеется поле размера (Length), поэтому отдельные биты завершения не требуются. Значения типа text представляют собой последовательность символов в кодировке UTF-8, а значения типа string – двоичные данные. Следует отметить, что тип text является подмножеством типа string.

Типы данных, используемых при передаче атрибута:

text – размер от 1 до 253 байтов, содержит символы в кодировке UTF-8. Недопустима передача текстовых атрибутов нулевой длины. В таких случаях следует просто исключить атрибут.

string – размер от 1 до 253 байтов, содержит бинарные данные (значения от 0 до 255, включительно). Недопустима передача string-атрибутов нулевой длины. В таких случаях следует просто исключить атрибут.

address - 32-битовое значение, первый байт которого является старшим.

integer - 32-битовое беззнаковое целое, первый байт является старшим.

time - 32-битовое беззнаковое целое (первый байт является старшим), показывающее число секунд, прошедших с 1 января 1970 г. (00:00:00 по Гринвичу - UTC). Стандартные атрибуты RADIUS не используют этот тип, но он добавлен для будущих расширений.

2.5.4. Атрибуты протокола RADIUS.

2.5.4.1. User-Name

Этот атрибут показывает имя пользователя, для которого выполняется аутентификация. Атрибут является обязательным для передачи в пакетах Access-Request.

Атрибут может передаваться в пакетах Access-Accept, однако в этом случае клиенту (NAS) следует использовать идентификатор, полученный в пакете Access-Accept для всех пакетов Accounting-Request в этом сеансе. Если Access-Accept включает в себя Service-Type=Rlogin и атрибут User-Name, NAS может использовать возвращенный атрибут User-Name при выполнении функции Rlogin.

Формат полей атрибута User-Name показан ниже. Поля передаются слева направо.



String = Поле имеет длину более 1 байта. Сервер NAS может ограничивать размер поля User-Name принудительно, однако рекомендуется обрабатывать поля не длиннее 63 байтов.

Имя пользователя может указываться одним из трех типов данных:

Text - строка символов в кодировке UTF-8.
network access identifier - идентификатор NAI, описанный в [RFC 2486].
distinguished name - имя в формате ASN.1, используемое в системах аутентификации Public Key.
2.5.4.2. User-Password

Атрибут передает пароль идентифицируемого пользователя или данные, введенные пользователем в ответ на пакет Access-Challenge. Пароль может передаваться только в пакетах Access-Request.

При передаче пакетов используется технология сокрытия паролей. Сначала к паролю добавляются NUL-символы до значения, кратного 16 байтам. Далее вычисляется необратимая хэш-функция MD5 для потока октетов разделяемого ключа и значения Request Authenticator. Полученное значение объединяется (логическая операция XOR) с первыми 16 байтами пароля и помещается в первые 16 байтов поля String в атрибуте User-Password.

Если размер пароля превышает 16 байтов, вычисляется вторая необратимая хэш-последовательность MD5 для потока байтов, состоящего из разделяемого ключа и результата шифрования первых 16 байтов пароля. Полученный результат объединяется (операция XOR) со вторым 16-байтовым сегментом пароля и помещается в следующие 16 байтов поля String в атрибуте User-Password.

При необходимости эта операция повторяется для каждого 16-байтового сегмента пароля с использованием разделяемого ключа и результата предыдущей операции. Размер пароля не может превышать 128 символов.

Ниже приведем более детальное описание метода:

Вызывается функция MD5 с разделяемым ключом S 128-битовым псевдослучайным значением Request Authenticator (RA). Пароль делится на 16-байтовые сегменты p1, р2 и т.д. с дополнением последнего сегмента NUL-символами для выравнивания по 16-октетовой границе. Для выполнения операций с последовательностями используется операция XOR (исключающее или) для хэш-функции и соответствующего сегмента пароля. Для второго и последующих сегментов вместо RA используется хэш-функция, полученная на предыдущем этапе. Зашифрованный пароль сохраняется как конкатенация промежуточных результатов с(1), с(2) и т. д. в поле String атрибута User-Password.

Математическая запись приведенного алгоритма показана ниже:

b1 = MD5(S RA) c(l) = pi xor b1

b2 = MD5(S c(l)) с(2) = p2 xor b2

. .

bi = MD5(S c(i-l)) c(i) = pi xor bi

На приемной стороне процесс выполняется в обратном порядке для получения исходного пароля.

Формат полей атрибута User-Password показан ниже. Поля передаются слева направо.



String = Строка типа string размером от 16 до 128 байтов (кратные 16 значения), содержащая зашифрованный пароль.

2.5.4.3. CHAP-Password

Этот атрибут отражает значение отклика, представленное пользователем с применением протокола CHAP, в ответ на запрос (challenge). Атрибут может включаться только в пакеты Access-Request.

Вид запроса CHAP можно найти в атрибуте CHAP-Challenge (табл. 2.2), если он присутствует в пакете, или в поле Request Authenticator.

Формат атрибута CHAP-Password показан ниже. Поля передаются слева направо.



CHAP Ident = поле имеет размер 1 байт и содержит идентификатор CHAP из пользовательского отклика CHAP Response.

String = 16-байтовое поле содержит значение CHAP Response, принятое от пользователя.

2.5.4.4. NAS-IP-Address

Этот атрибут указывает IP-адрес NAS-сервера, который запрашивает у RADIUS-сервера аутентификацию пользователя. Для корректной работы системы следует иметь уникальные адреса всех NAS-серверов в пределах сферы действия RADIUS-сервера. В каждом пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier.

Отметим, что значение атрибута NAS-IP-Address недопустимо использовать для выбора разделяемого ключа, применяемого при аутентификации запроса. Такой выбор должен осуществляться на основе адреса отправителя в пакете Access-Request.

Формат атрибута NAS-IP-Address показан ниже. Поля передаются слева направо.



Address = четырехбайтовое значение IP-адреса.

2.5.4.5. NAS-Port

Атрибут указывает физический порт NAS-сервера, через который установлено соединение с идентифицируемым пользователем. Этот атрибут используется только в пакетах Access-Request. Отметим, что номер порта NAS не имеет никакого отношения к номерам используемых портов TCP или UDP. Если сервер NAS способен различать свои порты, в пакеты Access-Request следует включать атрибут NAS-Port или NAS-Port-Type (табл. 2.2), допускается одновременное включение обоих атрибутов.

Формат атрибута NAS-Port показан ниже. Поля передаются слева направо.



Value = Четырехбайтовое значение идентификатора порта NAS.

2.5.4.6. Service-Type

Атрибут отражает тип сервиса, запрошенного пользователем, или тип услуги, предоставляемой пользователю. Атрибут может использоваться в пакетах Access-Request и Access-Accept. От серверов NAS не требуется реализация всех типов услуг, указанных в атрибуте, в случае передачи неизвестного типа услуги сервер должен трактовать его, как неподдерживаемые значения Service-Type (как при получении ответа Access-Reject).

Формат атрибута Service-Type показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value содержит один из перечисленных в таблице 2.3 идентификаторов типа услуги.

Табл. 2.3. Идентификаторы типов сервисов

Тип

Сервис

1

Login

2

Framed

3

Callback Login

4

Callback Framed

5

Outbound

6

Administrative

7

NAS Prompt

8

Authenticate Only

9

Callback NAS Prompt

10

Call Check

11

Callback Administrative

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

Табл. 2.4. Описание типов сервиса в протоколе RADIUS

Тип

Описание

Login

Пользователь подключается к хосту.

Framed

Для пользователя должен быть запущен Framed-протокол (например, РРР или SLIP).

Callback Login

Пользователь должен быть отключен и соединен с хостом после вызова со стороны хоста.

Callback Framed

Пользователь должен быть отключен и соединен с хостом после вызова со стороны хоста, после чего для пользователя должен быть запущен Framed-протокол (например, РРР или SLIP).

Outbound

Пользователю следует предоставить возможность доступа к устройствам для организации исходящих соединений.

Administrative

Пользователю следует предоставить административный интерфейс с сервером NAS, на котором будут выполняться команды, требующие определенных привилегий.

NAS Prompt

Пользователю следует предоставить возможность ввода консольных команд NAS, не требующих специальных привилегий.

Authenticate Only

Запрошена только идентификация пользователя и не требуется возвращать сведений о проверке полномочий (авторизации) в отклике Access-Accept. Этот тип сервиса обычно используется серверами-посредниками.

Callback NAS Prompt

Пользователь должен быть отключен и соединен с NAS по инициативе последнего с предоставлением пользователю возможности ввода консольных команд NAS, не требующих специальных приоритетов.

Call Check

Используется NAS в пакетах Access-Request для индикации приема вызова и факта, что серверу RADIUS следует возвратить пакет Access-Accept для ответа или Access-Reject для отказа от приема вызова (обычно это решается на основе атрибутов Called-Station-Id или Calling-Station-Id). Рекомендуется в таких запросах Access-Requests использовать значение Calling-Station-Id как значение User-Name.

Callback Administrative

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

2.5.4.7. Framed-Protocol

Этот атрибут показывает тип кадров, которые будут использоваться для соединения. Атрибут может передаваться в пакетах Access-Request и Access-Accept. Формат атрибута Framed-Protocol показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value содержит идентификатор протокола (табл. 2.5).

Табл. 2.5. Идентификатор протокола

Значение

Протокол

1

PPP

2

SLIP

3

AppleTalk Remote Access Protocol (ARAP)

4

Gandalf proprietary SingleLink/MultiLink protocol

5

Xylogics proprietary IPX/SLIP

6

X.75 Synchronous

2.5.4.8. Framed-IP-Address

Этот атрибут опредлеяет предоставленный пользователю IP-адрес. Атрибут может использоваться в пакетах Access-Accept. Этот атрибут можно также включать в запросы Access-Request, как рекомендованный NAS-сервером ввиду того, что он считается предпочтительным, однако RADIUS-сервер не обязан принимать во внимание эти советы.

Формат атрибута Framed-IP-Address показан ниже. Поля передаются слева направо.



Address = Поле Address имеет размер 4 байта. Значение OxFFFFFFFF показывает, что серверу NAS следует позволить пользователю выбрать адрес самостоятельно. Значение OxFFFFFFFE показывает, что серверу NAS следует выбрать адрес для пользователя (например, из пула адресов, выделенного для NAS). Остальные корректные значения указывают серверу NAS непосредственное значение IP-адреса, предоставляемого пользователю.

2.5.4.9. Framed-IP-Netmask

Этот атрибут показывает маску IP-подсети, которая выделяется пользователю в случаях, когда его терминал является маршрутизатором сети. Этот атрибут может использоваться в пакетах Access-Accept. Атрибут можно также включать в пакеты Access-Request в качестве рекомендации со стороны NAS предпочтительной для пользователя маски. RADIUS-сервер не обязан принимать эти рекомендации во внимание.

Формат атрибута Framed-IP-Netmask приведен ниже. Поля передаются слева направо.



Address = четырехбайтовое поле Address содержит значение маски подсети, выделенное для пользователя.

2.5.4.10. Framed-Routing

Этот атрибут отражает конкретный метод маршрутизации для пользователя в случаях, когда тот является маршрутизатором для сети. Атрибут может использоваться только в пакетах Access-Accept.

Формат атрибута Framed-Routing показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value задает тип маршрутизации. Значения поля приведены в табл. 2.6.



Табл. 2.6. Значения поля Value для атрибута Framed-Routing

Значение

Тип маршрутизации

0

Нет

1

Передавать пакеты маршрутизации

2

Принимать пакеты маршрутизации

3

Передавать и принимать пакеты маршрутизации

2.5.4.11. Filter-Id

Атрибут показывает список фильтров и их идентификаторы для применения к данному пользователю. Пакеты Access-Accept могут включать в себя множество атрибутов Filter-Id.

Идентификация списков по именам позволяет использовать фильтры на различных NAS-серверах независимо от деталей реализации списков фильтрации.

Формат атрибута Filter-Id Attribute показан ниже. Поля передаются слева направо.



Text = поле Text имеет длину от 0 байтов и выше. Содержимое поля зависит от реализации фильтров. Идентификаторы фильтров должны быть понятны человеку; недопустимо влияние этих идентификаторов на работу протокола. Рекомендуется в качестве значений атрибута использовать текстовые сообщения в кодировке UTF-8.

2.5.4.12. Framed-MTU

Этот атрибут показывает устанавливаемое для пользователя значение MTU (Maximum Transmission Unit – максимальный размер передаваемого блока информации), если это значение не согласуется иным способом (например, на уровне РРР). Атрибут может использоваться в пакетах Access-Accept. Возможно включение этого атрибута в пакеты Access-Request в качестве рекомендации серверу NAS, но сервер не обязан следовать этим рекомендациям.

Формат атрибута Framed-MTU показан ниже. Поля передаются слева направо.



Value = поле Value содержит 4 байта, указывающих значение MTU, которое должно варьироваться в диапазоне от 64 до 65535 (несмотря на то, что формат поля позволяет задать большие значения).

2.5.4.13. Framed-Compression

Этот атрибут показывает протокол компрессии, который должен использоваться для передачи данных в сеансе связи. Атрибут может использоваться в пакетах Access-Accept. Можно включать этот атрибут в пакеты Access-Request в качестве рекомендации, но сервер не обязан принимать этот совет во внимание.

Пакет может содержать несколько атрибутов. Ответственность за поддержку протоколов компрессии ложится на сервер NAS.

Формат атрибута Framed-Compression показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле, указывающее протокол сжатия данных. Возможные варианты значений приведены в табл. 2.7.



Табл. 2.7. Значения поля Value для атрибута Framed Compression

Значение

Тип компрессии

0

Без компресии

1

Сжатие заголовков VJ

2

Сжатие заголовков IPX

3

Сжатие Stac-LZS

2.5.4.14. Login-IP-Host

Этот атрибут указывает узел (хост), к которому хочет подключиться пользователь при наличии в пакете атрибута Login-Service. Атрибут может включаться в пакеты Access-Accept. Можно использовать атрибут в запросах Access-Request как рекомендацию, но сервер не обязан следовать таким рекомендациям.

Формат атрибута Login-IP-Host показан ниже. Поля передаются слева направо.



Address = поле Address имеет размер 4 байта. Значение 0xFFFFFFFF показывает, что серверу NAS следует позволить пользователю указать адрес хоста. Нулевое значение адреса говорит, что NAS-серверу следует выбрать адрес самостоятельно. Все прочие значения указывают конкретный адрес, который NAS-серверу следует выбрать для подключения пользователя.

2.5.4.15. Login-Service

Этот атрибут указывает службу, которая должна быть использована для входа пользователя в систему. Атрибут включается только в пакеты Access-Accept и не может присутствовать в любом другом сообщении протокола RADIUS.

Формат атрибута Login-Service показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value указывает тип сервиса для удаленного входа в систему. Возможные значения сервиса приведены в табл. 2.8.

Табл. 2.8. Возможные значения поля Value для атрибута Login-Service.

Значение

Служба

0

Telnet

1

Rlogin

2

TCP Clear

3

PortMaster (фирменный)

4

LAT

5

X25-PAD

6

X25-T3POS

8

TCP Clear Quiet (подавляется любой строкой connect от NAS)

2.5.4.16. Login-TCP-Port

Этот атрибут определяет номер для TCP порта, к которому пользователь будет подключаться, если в пакете присутствует атрибут Login-Service. Атрибут включается только в пакеты Access-Accept.

Формат атрибута Login-TCP-Port показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value может содержать значение в диапазоне от 0 до 65535.

2.5.4.17. Reply-Message

Этот атрибут содержит текст, который может выводиться на консоль пользователя (при ее наличии). В пакетах Access-Accept этот атрибут содержит информацию об успешной аутентификации пользователя.

В пакетах Access-Reject этот атрибут служит для передачи информации об отказе в выполнении какого-либо действия. Атрибут может содержать приглашение пользователю для ввода дополнительной информации перед новой попыткой передачи пакета Access-Request.

В пакетах Access-Challenge этот атрибут может содержать приглашение пользователя к диалогу для ввода дополнительной информации (отклика).

Пакет может содержать несколько атрибутов данного типа. Если такие атрибуты отображаются пользователю, они должны выводиться в порядке их следования в пакете.

Формат атрибута Reply-Message показан ниже. Поля передаются слева направо.



Text = поле содержит, по крайней мере, один байт. Содержимое поля должно определяться реализацией. Предполагается, что значение атрибута понятно человеку. Недопустимо влияние этого атрибута на работу протокола. Рекомендуется в качестве значения атрибута использовать текст в кодировке UTF-8.

2.5.4.18. Callback-Number

Этот атрибут показывает номер, необходимый для организации обратного вызова (callback). Атрибут может использоваться в пакетах Access-Accept. Можно использовать также в пакетах Access-Request как совет серверу в выборе службы Callback, но сервер не обязан принимать во внимание такие советы.

Формат атрибута Callback-Number показан ниже. Поля передаются слева направо.



String = Поле String содержит по крайней мере один байт. Формат реального значения поля зависит от службы и приложения, в целях повышения устойчивости системы при получении этого значения следует трактовать его как неразобранные данные с их непосредственным отображением.

2.5.4.19. Callback-Id

Этот атрибут показывает участника, с кем будет организовано "обратное соединение" с точки зрения NAS-сервера. Атрибут может использоваться в пакетах Access-Accept.

Формат атрибута Callback-Id показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от приложения, в целях повышения устойчивости системы следует трактовать это поле как неразобранные данные с их непосредственным отображением.

2.5.4.20. Framed-Route

Этот атрибут содержит информацию маршрутизации для пользователя NAS. Атрибут включается в пакеты Access-Accept и может многократно передаваться в одном сообщении.

Формат атрибута Framed-Route показан ниже. Поля передаются слева направо.



Text = поле Text содержит, по крайней мере, один байт. Конкретное содержимое поля зависит от реализации этих параметров в сети. Содержащаяся в поле информация предназначена для конечного пользователя (человека), воздействие значения этого поля на работу протокола недопустимо. Рекомендуется включать в это поле текстовое сообщение в кодировке UTF-8.

Для IP маршрутизации в поле следует включать префикс адресата в десятичном формате с разделением точками и указанием размера маски после символа дробной черты (слэш). После префикса следует ставить пробел, адрес шлюза с разделением точками, пробел и одно или несколько значений метрики, разделенных пробелами. Примером может служить строка "192.168.1.0/24 192.168.1.1 12-13 400". Размер маски может быть опущен; в таких случаях предполагается принятая по умолчанию маска /8 для префиксов класса А, /16 для префиксов класса В и /24 для префиксов класса С. Например, строка может иметь вид "192.168.1.0 192.168.1.1 1".

В тех случаях, когда шлюз указан в форме "0.0.0.0" в качестве IP-адреса шлюза следует указывать адрес, выделенный пользователю.

2.5.4.21. Framed-IPX-Network

Этот атрибут показывает номер сети IPX (Internetwork Packet Exchange) для пользователя. Атрибут включается в пакеты Access-Accept.

Формат атрибута Framed-IPX-Network показан ниже. Поля передаются слева направо.



Value = поле Value содержит 4 байта. Значение 0xFFFFFFFE показывает, что серверу NAS следует выбрать для пользователя номер сети IPX (например, из пула адресов NAS). Другие значения указывают конкретный номер сети IPX для пользователя.

2.5.4.22. State

Этот атрибут доступен для передачи от RADIUS-сервера к клиентам (NAS-серверам) в пакетах Access-Challenge и должен передаваться без изменения от клиента к серверу в новом пакете Access-Request, являющемся откликом на запрос (challenge), если таковой отклик передается.

Кроме того, атрибут доступен для передачи от сервера к клиентам в пакетах Access-Accept, которые содержат также атрибут Termination-Action Attribute со значением RADIUS-Request. Если сервер NAS выполняет операцию Termination-Action путем передачи нового пакета Access-Request при разрыве текущего сеанса, он должен включить атрибут State в этот пакет Access-Request без изменения атрибута.

В любом случае для клиента (NAS) недопустима локальная интерпретация атрибута. Пакет не может включать в себя более одного атрибута State.

Формат атрибута State показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от типа услуг и приложения, в целях повышения устойчивости системы следует трактовать это поле как неразобранные данные.

2.5.4.23. Class

Этот атрибут доступен для передачи от RADIUS-сервера к клиенту (NAS) в пакетах Access-Accept. Клиентам следует пересылать этот атрибут без его изменения серверам учета (accounting) как часть пакета Accounting-Request, если в системе поддерживается учет пользовательских параметров. Для клиентов недопустима локальная интерпретация данного атрибута.

Формат атрибута Class показан ниже. Поля передаются слева направо.



String = Поле состоит, по крайней мере, из одного байта. Формат реального значения поля зависит от приложения. В целях повышения устойчивости при невозможности определения значения этого поля рекомендуется трактовать его как неразобранные данные.

2.5.4.24. Vendor-Specific

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

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

Формат атрибута Vendor-Specific показан ниже. Поля передаются слева направо.



Vendor-Id = старший байт этого поля имеет значение 0, а три младших байта содержат код SMI Network Management Private Enterprise для производителя в соответствии с "Assigned Numbers".

String = поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от приложения и трактовки специфического параметра, в целях повышения устойчивости следует трактовать это поле как неразборчивые данные при невозможности трактовки его реального значения.

Это поле следует представлять в формате vendor type / vendor length / value, как показано ниже. Поле Attribute-Specific зависит от принятого разработчиком определения для этого поля. Пример атрибута Vendor-Specific показан ниже:



В одном атрибуте Vendor-Specific может содержаться множество субатрибутов, определенных разработчиком.

2.5.4.25. Session-Timeout

Этот атрибут задает максимальную продолжительность (в секундах) пользовательского сеанса. Атрибут доступен для передачи в пакетах Access-Accept и Access-Challenge.

Формат атрибута Session-Timeout показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле, содержащее 32-битовое беззнаковое целое число, определяющее продолжительность пользовательского сеанса (соединения с NAS) в секундах.

2.5.4.26. Idle-Timeout

Этот параметр задает максимальный период непрерывного бездействия, по истечении которого пользовательский сеанс должен прерываться. Атрибут доступен для передачи от сервера к клиентам в пакетах Access-Accept и Access-Challenge.

Формат атрибута Idle-Timeout показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле, содержащее 32-битовое беззнаковое целое число, которое определяет максимальное непрерывное время бездействия в секундах, по истечении которого пользователь отключается от сервера NAS.

2.5.4.27. Termination-Action

Атрибут указывает действие, которое должен выполнять NAS-сервер по завершении сеанса, и может использоваться только в пакетах Access-Accept.

Формат атрибута Termination-Action показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value может содержать одно из двух значений:

0 - принятое по умолчанию поведение

1 - RADIUS-Request

При установке значения RADIUS-Request в случае прерывания обслуживания сервер NAS может передать серверу RADIUS новый запрос Access-Request, включив в него атрибут State при наличии такового.

2.5.4.28. Called-Station-ld

Этот атрибут позволяет серверу доступа NAS передать в пакете Access-Request номер телефона, набранный пользователем и определенный с помощью DNIS (Dialed Number Identification) или иной технологии. Важно отметить, что этот номер может отличаться от реального номера, с которым было организовано соединение. Атрибут может использоваться только в пакетах Access-Request.

Формат атрибута Called-Station-ld показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от приложения, с которым оно генерируется. Рекомендуется использовать текст в кодировке UTF-8.

2.5.4.29. Calling-Station-ld

Этот атрибут позволяет серверу NAS передать в пакете Access-Request телефонный номер вызывающего пользователя, определенный с помощью AM (Automatic Number Identification) или иной технологии. Атрибут может использоваться только в пакетах Access-Request.

Формат атрибута Calling-Station-ld показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от реализуемого приложения. Рекомендуется использовать текст в кодировке UTF-8.

2.5.4.30. NAS-ldentifier

Этот атрибут содержит идентификатор определенного сервера NAS, передавшего пакет Access-Request. Атрибут передается только в пакетах Access-Request. При этом в каждом пакете Access-Request должен присутствовать один из атрибутов NAS-IP-Address или NAS-ldentifier.

Отметим, что значение атрибута NAS-ldentifier недопустимо использовать для выбора разделяемого ключа в процессе аутентификации запроса. Для выбора такого ключа должно использоваться значение IP-адреса отправителя в пакете Access-Request.

Формат атрибута NAS-ldentifier показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт и должно быть уникальным идентификатором NAS в пределах видимости сервера RADIUS. Например, в качестве NAS-ldentifier может использоваться полное доменное имя сервера доступа.

Формат реального значения поля зависит от топологии и номенклатуры сети.

2.5.4.31. Proxy-State

Этот атрибут доступен для передачи сервером-посредником (прокси) другому серверу при пересылке пакета Access-Request и должен быть возвращен в неизменном виде в пакете Access-Accept, Access-Reject или Access-Challenge. Когда прокси-сервер получает отклик на свой запрос, он должен удалить свой атрибут Proxy-State (последний атрибут данного типа в пакете) до пересылки отклика серверу NAS.

При добавлении атрибута Proxy-State в пересылаемый пакет этот атрибут должен добавляться после всех имеющихся в пакете атрибутов Proxy-State. Содержимое любого атрибута Proxy-State, кроме добавленного данным сервером, должно трактоваться как неопределяемые данные; недопустимо влияние этих атрибутов на работу протокола.

Использование атрибутов Proxy-State зависит от реализации протокола RADIUS в оборудовании.

Формат атрибута Proxy-State показан ниже. Поля передаются слева направо.



String = Поле String содержит, по крайней мере, один байт. Формат реального значения поля зависит от приложения.

2.5.4.32. Login-LAT-Service

Этот атрибут указывает систему, к которой пользователь должен подключаться по протоколу LAT. Атрибут может использоваться в пакетах Access-Accept при условии, что протокол LAT указан в виде Login-Service. Можно включать этот атрибут в пакеты Access-Request в качестве рекомендации серверу, но сервер не обязан следовать им.

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

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

Формат атрибута Login-LAT-Service показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт, указывающий сервис LAT. Архитектура LAT позволяет включать в строку символы $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, строчные и прописные буквы, а также символы расширенного набора ISO Latin-1. При сравнении строк LAT прописные и строчные буквы не различаются.

2.5.4.33. Login-LAT-Node

Этот атрибут указывает узел, к которому пользователь будет автоматически подключен по протоколу LAT. Атрибут может использоваться в пакетах Access-Accept, но только при указании LAT в качестве Login-Service. Возможно использование атрибута в пакетах Access-Request как рекомендации серверу, но сервер не обязан следовать этим рекомендациям.

Формат атрибута Login-LAT-Node показан ниже. Поля передаются слева направо.



String = поле String содержит, по крайней мере, один байт, идентифицирующий узел LAT, к которому подключается пользователь. Архитектура LAT позволяет включать в строку символы $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, строчные и прописные буквы, а также символы расширенного набора ISO Latin-1. При сравнении строк LAT прописные и строчные буквы не различаются.

2.5.4.34. Login-LAT-Group

Этот атрибут содержит строку, идентифицирующую коды группы LAT, которую пользователю разрешено применять. Атрибут можно использовать в пакетах Access-Accept, но только при указании LAT в качестве Login-Service. Можно включать атрибут в пакеты Access-Request как рекомендацию для сервера, но сервер не обязан принимать эти рекомендации во внимание.

LAT поддерживает 256 различных групп, которые служат для управления правами доступа пользователей. Для представления кодов используются битовые маски размером 256.

Администраторы могут выбрать один или множество кодов групп доступа для сервис-провайдера LAT. Оператор связи будет принимать только такие соединения, которые имеют соответствующие биты в маске прав. Администраторы создают маску прав доступа для каждого пользователя. LAT получает биты прав от операционной системы и использует их при передаче запросов сервис-провайдерам.

Формат атрибута Login-LAT-Group показан ниже. Поля передаются слева направо.



String = поле имеет размер 32 байта.

2.5.4.35. Framed-AppleTalk-Link

Этот атрибут показывает номер сети AppleTalk для последовательного канала пользователя, который является другим маршрутизатором AppleTalk. Атрибут передается только в пакетах Access-Accept. Этот атрибут не может применяться, если пользователь не является маршрутизатором.

Формат атрибута Framed-AppleTalk-Link показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта. Диапазон допустимых значений атрибута составляет от 0 до 65535. Специальное значение 0 указывает на безадресный (unnumbered) последовательный канал. Значение от 1 до 65535 говорят о том, что последовательному каналу между NAS и пользователем следует присвоить указанное значение в качестве номера сети AppleTalk.

2.5.4.36. Framed-AppleTalk-Network

Этот атрибут показывает номер сети AppleTalk, который серверу NAS следует проверить для выделения номера узла AppleTalk пользователю. Атрибут передается только в пакетах Access-Accept. Этот атрибут никогда не применяется, если пользователь одновременно является маршрутизатором. Наличие более одного атрибута показывает, что сервер NAS может пытаться использовать любой из указанных номеров сетей.

Формат атрибута Framed-AppleTalk-Network показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта. Диапазон допустимых значений атрибута составляет от 0 до 65535. Специальное значение 0 показывает, что серверу NAS следует выбрать для пользователя номер сети из диапазона, принятого по умолчанию. Значения от 1 до 65535 (включительно) показывают номер сети AppleTalk, которую серверу NAS следует проверить для выделения адреса.

2.5.4.37. Framed-AppleTalk-Zone

Этот атрибут указывает принятую по умолчанию зону AppleTalk для данного пользователя. Атрибут передается только в пакетах Access-Accept и не допускается использование в одном пакете нескольких экземпляров атрибута.

Формат атрибута Framed-AppleTalk-Zone показан ниже. Поля передаются слева направо.



String = поле содержит имя Default AppleTalk Zone для данного пользователя.

2.5.4.38. Acct-Status-Type

Этот атрибут определяет действие, на которое указывает данный пакет Accounting-Request: начало (Start) или завершение (Stop) обслуживания пользователя.

Атрибут может использоваться для маркировки начала учета путем указания Accounting-On или для маркировки завершения учета с помощью Accounting-Off.

Формат атрибута Acct-Status-Type показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта и может принимать значения:

1. Start

2. Stop

3. Interim-Update

7. Accounting-On

8. Accounting-Off

9-14. резервированы для Tunnel Accounting

15. резервировано для отказов (Failed).

2.5.4.39. Acct-Delay-Time

Этот атрибут показывает число секунд, в течение которых клиент пытается передать определенное сообщение, и значение атрибута может вычитаться из времени доставки пакета на сервер для вычисления момента генерации пакета Accounting-Request (время передачи через сеть не принимается во внимание).

Отметим, что изменение параметра Acct-Delay-Time требует также изменять значение поля Identifier.

Формат атрибута Acct-Delay-Time показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.40. Acct-Input-Octets

Этот атрибут показывает количество байтов, полученных от порта за время, в течение которого предоставляется определенная услуга.

Атрибут может включаться только в пакеты Accounting-Request, где Acct-Status-Type = Stop.

Формат атрибута Acct-Input-Octets показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.41. Acct-Output-Octets

Этот атрибут показывает количество байтов, переданных на порт в течение всего срока предоставления определенной услуги. Атрибут может использоваться только в пакетах Accounting-Request с Acct-Status-Type = Stop.

Формат атрибута Acct-Output-Octets показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.42. Acct-Session-Id

Этот атрибут содержит уникальное значение Accounting ID, упрощающее поиск соответствия между стартовыми и конечными записями в журнальном файле. Стартовая и конечная запись для любой определенной сессии должны иметь одинаковые значения Acct-Session-Id, это позволяет однозначно сопоставить пакеты. Пакеты Accounting-Request должны содержать атрибут Acct-Session-Id. Возможно включение атрибута Acct-Session-Id в пакеты Access-Request; в таких случаях сервер доступа NAS должен использовать такое же значение параметра Acct-Session-Id в пакетах Accounting-Request для данной сессии.

Значение атрибута Acct-Session-Id необходио задавать в кодировке UTF-8. Например, можно использовать 8-значные шестнадцатеричные идентификаторы с буквами верхнего регистра и увеличивать значение двух старших цифр при каждой перезагрузке (полное использование всех значений после 256 перезагрузок). Остальные 6 цифр позволяют задать значения от 0 (для первого пользователя после перезагрузки) до 224-1 (около 16 миллионов), что позволяет организовать соответствующее число сеансов за время между перезагрузками. Возможны и другие схемы построения уникальных значений атрибута.

Формат атрибута Acct-Session-Id показан ниже. Поля передаются слева направо.



Text = Значение поля Text следует задавать в кодировке UTF-8.

2.5.4.43. Acct-Authentic

Этот атрибут может включаться в пакеты Accounting-Request для индикации того, что пользователь уже прошел аутентификацию с помощью протокола RADIUS. Если предоставление услуги пользователям обеспечивается без аутентификации, учетные записи генерировать не следует.

Формат атрибута Acct-Authentic показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта и может принимать значения :

1 - RADIUS

2 - Local (Локальная аутентификация)

3 - Remote (Удаленная аутентификация).

2.5.4.44. Acct-Session-Time

Этот атрибут показывает время обслуживания пользователя (в секундах). Атрибут может присутствовать только в пакетах Accounting-Request, где Acct-Status-Type = Stop.

Формат атрибута Acct-Session-Time показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.45. Acct-Input-Packets

Этот атрибут показывает общее число пакетов, полученных из порта за все время обслуживания пользователя Framed User, и может включаться только в пакеты Accounting-Request с Acct-Status-Type = Stop.

Формат атрибута Acct-Input-packets показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.46. Acct-Output-Packets

Этот атрибут показывает общее число пакетов, переданных в порт за все время обслуживания пользователя Framed User, и может включаться только в пакеты Accounting-Request с Acct-Status-Type = Stop.

Формат атрибута Acct-Output-Packets показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.4.47. Acct- Terminate- Cause

Этот атрибут показывает причину завершения сеанса и может включаться только в пакеты Accounting-Request, где Acct-Status-Type = Stop.

Формат атрибута Acct-Terminate-Cause показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value содержит код причины завершения сеанса (табл. 2.9):

Табл. 2.9. Код причины завершения сеанса

Значение

Тип

Описание

1

User Request

Прекращение сеанса по инициативе пользователя (с помощью LCP Terminate или выхода из сети – log out)

2

Lost Carrier

На порту был передан сигнал DCD (детектирование несущей)

3

Lost Service

Сервис больше не предоставляется (например, разорвано соединение пользователя с хостом)

4

Idle Timeout

Истекло время допустимого бездействия (Idle timer)

5

Session Timeout

Достигнута максимальная продолжительность сеанса

6

Admin Reset

Сессия или порт заданы администратором

7

Admin Reboot

Администратор прекратил обслуживание пользователей NAS

8

Port Error

Сервер NAS обнаружил для порта ошибку, потребовавшую разрыва сессии

9

NAS Error

Сервер NAS обнаружил ошибку (не связанную с портом), потребовавшую разрыва сессии

10

NAS Request

Сервер NAS завершил сессию по неизвестной причине

11

NAS Reboot

Сервер NAS завершил сессию для аварийной перезагрузки

12

Port Unneeded

Сервер NAS завершил сессию из-за слишком малого уровня использования ресурсов (в случаях выделения полосы по запросу реально достижимая скорость позволяет отключить один из портов)

13

Port Preempted

Сервер NAS завершил сеанс для предоставления порта пользователю с более высоким приоритетом

14

Port Suspended

Сервер NAS завершил сеанс для прерывания виртуальной сессии

15

Service Unavailable

Сервер NAS не может предоставить запрошенный сервис

16

Callback

Сервер NAS прерывает текущую сессию для организации обратного соединения (callback)

17

User Error

Ошибка в полученных от пользователя данных, вызвавшая прекращение сеанса

18

Host Request

Нормальное завершение сеанса хостом

2.5.4.48. Acct-Multi- Session-Id

Этот атрибут содержит уникальный идентификатор Accounting ID, позволяющий связать воедино множество сеансовых записей. Каждая сессия имеет свое значение Acct-Session-Id, а значения идентификатора “мультисессии” Acct-Multi-Session-Id будут совпадать для связанных сессий. Настоятельно рекомендуется указывать значения атрибутов Acct-Multi-Session-Id в кодировке UTF-8.

Формат атрибута Acct-Multi-Session-Id показан ниже. Поля передаются слева направо.



String = значение поля String следует задавать в кодировке UTF-8.

2.5.4.49. Acct-Link-Count

Этот атрибут указывает число соединений, относящихся к данной “мультисессии” на момент генерации записи. Сервер NAS может включать атрибут Acct-Link-Count в любые пакеты Accounting-Request, которые могут быть связаны с многоканальными соединениями.

Формат атрибута Acct-Link-Count показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле Value содержит число соединений для данной «мультисессии».

Этот атрибут упрощает серверу учета связывание воедино информации для множества сессий одной “мультисессии”. Когда число пакетов Accounting-Request, полученных с Acct-Status-Type = Stop, одинаковыми значениями Acct-Multi-Session-Id и уникальными значениями Acct-Session-Id равно наибольшему значению Acct-Link-Count, появляющемуся в таких пакетах Accounting-Requests, это говорит о получении всех финишных (Stop) запросов Accounting-Requests для данной многоканальной сессии.

2.5.4.50. CHAP-Challenge

Атрибут содержит запрос CHAP Challenge, передаваемый сервером NAS пользователю РРР CHAP, и применяется только в пакетах Access-Request.

Если значение CHAP challenge имеет размер 16 байтов, то оно может быть помещено в поле Request Authenticator вместо этого атрибута.

Формат атрибута CHAP-Challenge показан ниже. Поля передаются слева направо.



String = поле String содержит значение CHAP Challenge.

2.5.4.51. NAS-Port-Type

Этот атрибут показывает тип физического порта сервера доступа NAS, через который подключается пользователь. Атрибут может передаваться вместо атрибута NAS-Port или в дополнение к нему. Атрибут передается только в пакетах Access-Request. В каждый пакет Access-Request следует включать атрибут NAS-Port или NAS-Port-Type (или оба атрибута), если сервер NAS может различать свои порты.

Формат атрибута NAS-Port-Type показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта. Значение Virtual указывает, что соединение с NAS осуществляется через некий протокол транспортного уровня вместо физического порта. Например, если пользователь обращается к NAS из сессии telnet для идентификации себя как Outbound-User, пакет Access-Request может включать атрибут -Port-Type = Virtual в качестве указания серверу RADIUS что пользователь не связан с физическим портом. Значения параметра приведены в табл. 2.10.

Табл. 2.10. Значения параметра атрибута NAS-Port-Type

Значение

Тип порта

0

Async

1

Sync

2

ISDN Sync

3

ISDN Async V.I20

4

ISDNAsyncV.110

5

Virtual

6

PIAFS (беспроводный вариант ISDN, используемый в Японии)

7

HDLC Clear Channel

8

X.25

9

X.75

10

G.3 Fax

11

SDSL - Symmetric DSL

12

ADSL-CAP - Asymmetric DSL, модуляция CAP

13

ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone

14

IDSL - ISDN Digital Subscriber Line

15

Ethernet

16

xDSL - DSL неизвестного типа

17

Cable

18

Беспроводные каналы (не IEEE 802.11)

19

Беспроводные каналы IEEE 802.11

2.5.4.52. Port-Limit

Этот атрибут устанавливает максимальное число портов NAS-сервера, открытых для подключения пользователя. Атрибут может передаваться сервером клиенту в пакетах Access-Accept. Назначение атрибута состоит в управлении числом портов для организации "параллельных" соединений с помощью Multilink PPP или аналогичных протоколов. Атрибут может также передаваться NAS-серверу в качестве рекомендации серверу относительно желаемого числа портов, но сервер не обязан следовать таким рекомендациям.

Формат атрибута Port-Limit показан ниже. Поля передаются слева направо.



Value = четырехбайтовое поле содержит 32-битовое беззнаковое целое число, указывающее количество портов, которые сервер NAS может выделить для подключения пользователя.

2.5.4.53. Login-LAT-Port

Этот атрибут указывает порт, через который пользователь будет подключаться по протоколу LAT. Атрибут может передаваться в пакетах Access-Accept, но только при указании протокола LAT в качестве Login-Service. Можно использовать атрибут в пакетах Access-Request как рекомендацию для сервера, но сервер не обязан принимать такие рекомендации во внимание.

Формат атрибута Login-LAT-Port показан ниже. Поля передаются слева направо.



String = поле String содержит по крайней мере один байт, идентифицирующий порт LAT, который будет использоваться для подключения. Архитектура LAT позволяет включать в строку символы $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, строчные и прописные буквы, а также символы расширенного набора ISO Latin-1. При сравнении строк LAT прописные и строчные буквы не различаются.

2.5.5. Дополнительные атрибуты протокола RADIUS

Кроме базового протокола в рамках института IETF был разработан ряд документов, расширяющих возможности протокола RADIUS [RFC 2869, 2882, 3162, 4590, 4675, 4849, 5030, 5090, 5176, 5607 и другие]. В этих RFC были введены дополнительные атрибуты, которые будут приведены ниже.

2.5.5.1. Acct-Input-Gigawords [RFC 2869]

Этот атрибут указывает, какое количество блоков размером 232 было передано в атрибуте Acct-Input-Octets в процессе предоставления пользователю конкретной услуги. Атрибут может быть передан только в пакете Accounting-Request, при наличии в нем атрибута Acct-Status-Type в значении Stop или Interim-Update.

Формат атрибута Acct-Input-Gigawords показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.5.2. Acct-Output-Gigawords [RFC 2869]

Этот атрибут указывает, какое количество блоков размером 232 было передано в атрибуте Acct-Output-Octets в процессе предоставления пользователю конкретной услуги. Атрибут может быть передан только в пакете Accounting-Request, при наличии атрибута Acct-Status-Type в значении Stop или Interim-Update.

Формат атрибута Acct-Output-Gigawords показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта.

2.5.5.3. Event-Timestamp [RFC 2869]

Этот атрибут передается в сообщении Accounting-Request для отображения времени исполнения какого-либо события на NAS-сервере, время отображается в секундах, начиная с 00:00 UTC, 1 января 1970 года.

Формат атрибута Event-Timestamp показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта и содержит целое число, отображающее количество секунд, начиная с 00:00 UTC, 1 января 1970 года.

2.5.5.4. Egress-VLANID [RFC 4675]

Атрибут позволяет определять для порта его идентификатор Egress-VLANID в соответствии с рекомендациями IEEE 802.1Q. Атрибут Egress-VLANID может включаться в те же RADIUS-сообщения, что и туннельные атрибуты. Таким образом, этот атрибут не обязателен, если он используется для конфигурирования VLANID, уже включенного в другие атрибуты.

Атрибут Egress-VLANID может передаваться в сообщениях Access-Request, Access-Accept, CoA-Request или Accounting-Request.

Формат атрибута Egress-VLANID показан ниже. Поля передаются слева направо.



Value = поле состоит из 4 байтов. Его формат приведен ниже:



Поле Tag Indication занимает 1 байт и отражает, маркированы (0х31) или немаркированы (0х32) пакеты, передаваемые по этому VLAN.

Поле Pad занимает 12 битов и должно принимать значение ноль (0).

Поле VLANID занимает 12 битов и содержит значение VLAN VID [IEEE-802.1Q].

2.5.5.5. Ingress-Filters [RFC 4675]

Этот атрибут согласовывает конкретный фильтр входящего трафика для каждого порта, как это определено в документе IEEE-802.1Q. Когда атрибут принимает значение «Enabled», то настройки VLAN фильтров, которые обрабатывают входящий трафик на порт, должны быть соотнесены с настройками фильтров исходящего трафика для порта. Только один атрибут может быть передан в сообщении Access-Request.

Формат атрибута Ingress-Filters показан ниже. Поля передаются слева направо.



Value = поде состоит из 4 байтов. Поддерживаются следующие значения:

1 – Enabled.

2 – Disabled.

2.5.5.5. Egress-VLAN-Name [RFC 4675]

В стандарте IEEE-802.1Q описано соответствие параметров VLAN-ID и VLAN Name. Атрибут Egress-VLAN-Name нужен для назначения VLAN для конкретного порта. Атрибут похож на Egress-VLANID, с той разницей, что VLAN name используется для идентификации порта внутри системы.

Атрибут может передаваться в сообщениях Access-Request, Access-Accept, CoA-Request или Accounting-Request.

Формат атрибута Egress-VLAN-Name показан ниже. Поля передаются слева направо.



Tag Indication = поле занимает один байт и определяет данный VLAN. Используется (0x31, ASCII ’1’) или не используется (0x32, ASCII ’2’) для передачи информации.

String = поле занимает не менее одного байта и содержит параметр VLAN Name, определенный в IEEE-802.1Q.

2.5.5.6. User-Priority-Table [RFC 4675]

В рекомендации IEEE-802.1D обсуждается способ восстановления пользовательского приоритета для потоков, принимаемых на порт. По умолчанию восстановление пользовательского приоритета должно быть идентично пользовательским приоритетам, настроенным для входящих потоков.

Атрибут User-Priority-Table описывает приоритетную систему, которая будет применена для данного порта. Так как определено всего 8 типов приоритета для пользователя, то и атрибут принимает значения от 0 до 7. Атрибут может передаваться в сообщениях Access-Accept или CoA-Request.

Формат атрибута User-Priority-Table показан ниже. Поля передаются слева направо.



String = поле состоит из 8 байтов и содержит таблицу, которая распределяет типы приоритета входящих потоков (от 0 до 7). Типы приоритета пользователей выставляются последовательно соответственно выбранным для них потокам.

2.5.5.7. ARAP-Password [RFC 2869]

Этот атрибут представлен только в сообщении Access-Request, содержащем атрибут Framed-Protocol со значением ARAP.

Только один из атрибутов User-Password, CHAP-Password или ARAP-Password может быть вставлен в сообщение Access-Request или сообщения EAP-Messages.

Формат атрибута ARAP-Password показан ниже. Поля передаются слева направо.



Value = этот атрибут содержит 16-байтовую строку для переноса ответа пользователя на NAS-сервер по его запросу и для передачи запроса от RADIUS-клиента на NAS-сервер. Верхние байты (Value1 и Value2) содержат запрос пользователя NAS-серверу (два 32-битовых числа, 8 байтов), нижние байты (Value3 and Value4) содержат ответ на запрос NAS-сервера (два 32-битовых числа, 8 байтов).

2.5.5.8. ARAP-Features [RFC 2869]

Этот атрибут отправляется с сообщением Access-Accept при параметре Framed-Protocol в значении ARAP, и содержит пароль, который NAS-сервер должен послать пользователю в пакете "feature flags" протокола ARAP.

Формат атрибута ARAP-Features показан ниже. Поля передаются слева направо.



Value = этот атрибут содержит строку с информацией, которую NAS-сервер должен послать пользователю в пакете "feature flags" протокола ARAP.

Value 1: если равно «нулю» (0), то пользователь не может менять этот пароль. Если «не нуль» то пользователь может менять пароль.

Value 2: значение минимально допустимой длины пароля.

Value 3: дата создания пароля в формате Macintosh, определенная как 32 бита, представляющих количество секунд, начиная с 00:00 GMT, 1 января 1904 года.

Value 4: Срок действия пароля Delta (в секундах) с момента его создания.

Value 5: Текущее время на RADIUS-сервере в формате Macintosh.

2.5.5.9. ARAP-Zone-Access [RFC 2869]

Атрибут включается в сообщение Access-Accept при наличии в нем параметра Framed-Protocol со значением ARAP и служит для отображения того, в какой последовательности пользователю использовать список зон ARAP.

Формат атрибута ARAP-Zone-Access показан ниже. Поля передаются слева направо.



Value = Поле Value имеет размер 4 байта и содержит целое число, имеющее следующие значения:

1 - Разрешение доступа только в зону определенную по умолчанию.

2 - Включать использование фильтра для данной зоны.

4 - Исключить использование фильтра для зоны.

Значение 3 исключено потому, что в некоторых реализациях ARAP оно определяет переменную – «все зоны», значения которых не определены в спецификациях RADIUS. Если атрибут принимает значение 2 или 4, то в сообщении должен содержаться атрибут Filter-Id, содержащий имя фильтра списка зон для использования к ним ключа доступа.

2.5.5.10. ARAP-Security [RFC 2869]

Этот атрибут определяет Модуль безопасности ARAP, который будет использоваться в сообщении Access-Challenge.

Формат атрибута ARAP-Security показан ниже. Поля передаются слева направо.



Value = Поле Value имеет размер 4 байта, содержащих сигнатуры модуля безопасности в формате Macintosh OSType.

2.5.5.11. ARAP-Security-Data [RFC 2869]

Этот атрибут содержит запрос или ответное сообщение для действующего модуля безопасности, он может передаваться в сообщениях Access-Challenge и Access-Request.

Формат атрибута ARAP-Security-Data показан ниже. Поля передаются слева направо.



String = поле содержит запрос или ответ для действующего модуля безопасности, связанного с атрибутом ARAP-Security.

2.5.5.12. Password-Retry [RFC 2869]

Этот атрибут может включаться в сообщение Access-Reject для отображения количества попыток аутентификации, которые пользователь может произвести до разрыва соединения.

Первоначально этот механизм предполагалось использовать с ARAP-аутентификацией.

Формат атрибута Password-Retry показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта и определяет число попыток ввода пароля, доступных пользователю.

2.5.5.13. Prompt [RFC 2869]

Этот атрибут используется только с сообщениями Access-Challenge и определяет, нужно ли NAS-серверу дополнительно возвращать пользователю его отклик в том виде, в каком он был передан.

Формат атрибута Prompt показан ниже. Поля передаются слева направо.



Value = поле Value имеет размер 4 байта и может принимать значения

0 - Не передавать (No Echo)

2 - Передавать (Echo).

2.5.5.14. Connect-Info [RFC 2869]

Атрибут передается от NAS-сервера на RADIUS-сервер для определения типа пользовательского сеанса связи.

Атрибут может передаваться в сообщениях Access-Request или Accounting-Request.

Формат атрибута Connect-Info показан ниже. Поля передаются слева направо.



Text = поле содержит текст в кодировке UTF-8. Значение скорости передачи для данного соединения должно передаваться в начале первого атрибута Connect-Info в сообщении. Если скорость приема и передачи различна, то они должны разделяться знаком «/» (slash), перед знаком отражается скорость передачи, после знака «/» – скорость приема информации, затем можно отражать другую информацию.

Пример атрибута: "28800 V42BIS/LAPM" или "52000/31200 V90". В сообщениях Accounting-Request может передаваться больше одного атрибута для передачи дополнительной информации, если объем данных превышает 252 байта.

2.5.5.15. Configuration-Token [RFC 2869]

Этот атрибут используется при аутентификации в больших распределенных сетях, содержащих серверы-посредники (прокси). Он передается от RADIUS-Proxy-сервера к RADIUS-Proxy-клиенту в сообщении Access-Accept и сообщает тип используемого профиля пользователя. Этот атрибут не должен передаваться на NAS-сервер.

Формат атрибута Configuration-Token показан ниже. Поля передаются слева направо.



String = поле состоит из одного или более байтов. Реальный размер поля зависит от топологии и номенклатуры сети. В целях повышения устойчивости работы системы при невозможности определения значения данного поля рекомендуется трактовать его как неразобранные данные.

2.5.5.16. EAP-Message [RFC 2869]

Этот атрибут инкапсулирует в себя сообщения протокола EAP (Extended Access Protocol) для того, чтобы NAS-сервер мог провести процедуру аутентификации по алгоритму EAP даже в случае, если сам он не поддерживает этот механизм. NAS-сервер помещает сообщения EAP, принятые от пользователя, в атрибут и передает их на RADIUS-сервер в сообщениях Access-Request.

Если RADIUS-сервер получил сообщение EAP, которое он не может распознать, то он должен сообщить об этом в сообщении Access-Reject.

В сообщениях Access-Request или Access-Challenge может содержаться несколько атрибутов EAP-Message. Сообщения же Access-Accept и Access-Reject могут содержать только один атрибут EAP-Message, со значением EAP-Success или EAP-Failure.

Для защиты от воздействия на работу сети в сообщениях Access-Request, Access-Challenge, Access-Accept и Access-Reject, содержащих EAP-Message, должен передаваться атрибут Message-Authenticator.

RADIUS-сервер самостоятельно вычисляет значение атрибута Message-Authenticator для конкретных сообщений, и при несовпадении с ожидаемым результатом должен отбрасывать поступивший пакет и сообщать об этом пакетом Access-Reject. При отсутствии атрибута Message-Authenticator в сообщениях с EAP-Message такой пакет должен немедленно отбрасываться.

Формат атрибута EAP-Message показан ниже. Поля передаются слева направо.



String = поле содержит сообщения протокола EAP. Если сообщение разбито на несколько атрибутов, то при получении оно должно складываться, это позволяет передавать поверх протокола RADIUS сообщения EAP длиннее, чем 253 байта.

2.5.5.18. Message-Authenticator [RFC 2869]

Этот атрибут может использоваться для индикации сообщения Access-Requests при использовании дополнительных методов аутентификации, таких как CHAP-, ARAP- или EAP-аутентификации.

Этот атрибут должен присутствовать во всех сообщениях Access-Request, Access-Accept, Access-Reject или Access-Challenge, содержащих атрибут EAP-Message.

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

Ранние документы описывают этот атрибут под именем «Signature», однако последним верным названием данного атрибута является именно Message-Authenticator.

Формат атрибута Message-Authenticator показан ниже. Поля передаются слева направо.



String = когда атрибут передается в сообщении Access-Request поле имеет формат HMAC-MD5, проверочную сумму, формирование которой описано в RFC 2104. Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes). После формирования проверочной суммы она должна быть помещена в 16-байтовое поле.

Для сообщений Access-Challenge, Access-Accept и Access-Reject атрибут вычисляется по специальному алгоритму, используя атрибут Request-Authenticator из сообщения Access-Request. После формирования проверочной суммы она должна быть помещена в 16-байтовое поле. Полученное значение используется как ключ для значения HMAC-MD5. Он вычисляется и помещается в пакет до формирования Response Authenticator.

Этот атрибут не нужен, если присутствует User-Password, однако он полезен для предотвращения возможных атак и несанкционированного доступа за счет определения злонамеренного NAS-сервера, с которого поступают некорректные сообщения.

2.5.5.19. ARAP-Challenge-Response [RFC 2869]

Этот атрибут передается в сообщении Access-Accept вместе с Framed-Protocol для ARAP, и содержит отклик на соответствующий запрос пользователя.

Формат атрибута ARAP-Challenge-Response показан ниже. Поля передаются слева направо.



Value = поле состоит из 8 байтов, содержащих отклик на запрос пользователя. RADIUS-сервер формирует его из первых 8 байтов атрибута ARAP-Password в запросе пользователя. Затем выполняет DES-шифрование информации, используя пароль пользователя в качестве ключа шифрования. Если пароль пользователя меньше 8 байтов, то недостающие байты заполняются нулями.

2.5.5.20. Acct-Interim-Interval [RFC 2869]

Этот атрибут отражает количество секунд между каждым моментом модернизации (обновления) пользовательского сеанса связи. Этот атрибут может передаваться только в сообщении Access-Accept.

Формат атрибута Acct-Interim-Interval показан ниже. Поля передаются слева направо.



Value = поле содержит число секунд между обновлениями, посланными с NAS-сервера для данного сеанса связи. Значение поля не должно быть менее 600.

2.5.5.21. NAS-Port-Id [RFC 2869]

Этот атрибут содержит текстовую строку с идентификатором порта NAS-сервера, через который происходит аутентификация пользователя. Он может передаваться только в сообщениях Access-Request и Accounting-Request.

Стоит отметить, что здесь под словом «порт» понимается физическое соединение на NAS-сервере, а не номер TCP или UDP порта.

Атрибут NAS-Port-Id должен передаваться в сообщении Access-Request для использования в NAS-серверах.

Формат атрибута NAS-Port-Id показан ниже. Поля передаются слева направо.



Text = поле содержит имя порта в кодировке UTF-8.

2.5.5.22. Framed-Pool [RFC 2869]

Этот атрибут содержит наименование адресного пула, который должен раздавать адреса пользователям. Если NAS не поддерживает возможность общения с адресными пулами, то он должен игнорировать этот атрибут. Адресные пулы обычно используются для IP-адресации, но могут также использоваться и для других протоколов, если NAS-серверы эти протоколы поддерживают.

Формат атрибута Framed-Pool показан ниже. Поля передаются слева направо.



String = поле содержит наименование адресных пулов, сконфигурированных на NAS-сервере.

2.5.5.23. NAS-Filter-Rule [RFC 4849]

Этот атрибут содержит правила фильтрации, которые будут применяться для данного пользователя. Атрибут может быть передан в сообщениях Access-Accept, CoA-Request или Accounting-Request.

Атрибут не может передаваться в одном сообщении с атрибутами Filter-Id и NAS-Traffic-Rule.

Формат атрибута NAS-Filter-Rule показан ниже. Поля передаются слева направо.



String = поле содержит один или более байтов. В нем помещается список правил фильтрации, записанных в синтаксисе IPFilterRule, который определен в RFC3588. Атрибут может содержать часть правила, одно правило или более чем одно правило.

2.5.5.24. NAS-IPv6-Address [RFC 3162]

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

NAS-IPv6-Address передается только в сообщениях Access-Request.

Атрибуты NAS-IPv6-Address и/или NAS-IP-Address могут быть переданы в сообщении Access-Request, однако, если ни один из них не используется, то должен передаваться атрибут NAS-Identifier.

Формат атрибута NAS-IPv6-Address показан ниже. Поля передаются слева направо.



Address = поле состоит из 16 байтов.

2.5.5.25. Framed-Interface-Id [RFC 3162]

Атрибут определяет идентификатор IPv6 интерфейса, сформированного для пользователя. Он может передаваться в сообщении Access-Accept. Если опция Interface-Identifier IPv6CP [RFC 2472] была успешно оговорена, этот атрибут должен быть включен в сообщение Access-Request, однако RADIUS-сервер должен воспринимать его как рекомендацию использовать это значение.

Формат атрибута Framed-Interface-Id показан ниже. Поля передаются слева направо.



Interface-Id = поле состоит из 8 байтов.

2.5.5.26. Framed-IPv6-Prefix [RFC 3162]

Этот атрибут определяет IPv6 префикс (и соответствующий маршрут), сформированный для пользователя. Он может передаваться в сообщениях Access-Accept несколько раз. Он может также передаваться в пакете Access-Request, но как рекомендация NAS-серверу использовать это значение.

Как только префикс передается на NAS-сервер, тот должен установить прямой маршрут в соответствии с префиксом, в этом случае серверу нет необходимости посылать атрибут Framed-IPv6-Route.

Формат атрибута Framed-IPv6-Prefix показан ниже. Поля передаются слева направо.



Reserved = поле является резервным и всегда равно нулю (0).

Prefix-Length = длина префикса в битах. Не менее 0 и не более 128.

Prefix = поле длиной до 16 байтов. Если число битов превышает значение в поле Prefix-Length, то они заполняются нулями (0).

2.5.5.27. Login-IPv6-Host [RFC 3162]

Этот атрибут отражает систему, к которой подключается пользователь, когда присутствует атрибут Login-Service. Он может передаваться в сообщении Access-Accept. Он может также передаваться в пакете Access-Request, но как рекомендация NAS-серверу использовать это значение.

Формат атрибута Login-IPv6-Host показан ниже. Поля передаются слева направо.



Address = поле состоит из 16 байтов. Значение 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF означает, что NAS-сервер должен позволить абоненту выбрать адрес, к которому он будет подключаться. Значение 0 показывает, что NAS-сервер самостоятельно выбирает хост для подключения пользователя. Остальные значения определяют адрес, к которому необходимо подключить пользователя.

2.5.5.28. Framed-IPv6-Route [RFC 3162]

Этот атрибут доставляет информацию маршрутизации, которая была сформирована на NAS-сервере для пользователя. Он может передаваться в сообщениях Access-Accept несколько раз.

Формат атрибута Framed-IPv6-Route показан ниже. Поля передаются слева направо.



Text = поле состоит из одного или более байтов и его содержимое обусловлено реализацией протокола. Для IPv6 маршрутизации поле должно содержать префикс узла назначения, следующий за «/» (slash), и десятичное значение длины префикса. За ним следует пробел, адрес шлюза, пробел, и одна или более метрик, разделенных пробелами. К примеру, "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". Если в поле не указан адрес шлюза, то вместо него необходимо принимать адрес пользователя.

2.5.5.29. Framed-IPv6-Pool [RFC 3162]

Этот атрибут содержит наименования пулов, предназначенных для выделения IPv6 префикса пользователю.

Если NAS не поддерживает работу с несколькими пулами префиксов, то NAS-сервер должен игнорировать этот атрибут.

Формат атрибута Framed-IPv6-Pool показан ниже. Поля передаются слева направо.



String = поле содержит наименование пулов для выделения IPv6 префиксов, сформированных на NAS-сервере.

2.5.5.30. Error-Cause [RFC 3576]

На В сети возможны ситуации, при которых NAS-сервер не может принять сообщения Disconnect-Request или CoA-Request по какой-либо причине. Атрибут Error-Cause необходим для более подробного описания причины возникновения этих проблем. Этот атрибут может передаваться в сообщениях Disconnect-ACK, Disconnect-NAK и CoA-NAK.

Формат атрибута Error-Cause показан ниже. Поля передаются слева направо.



Value = поле состоит из 4 байтов, содержащих целое число, которое отображает причину ошибки. Значения от 0 до 199 и от 300 до 399 резервированы. Значения от 200 до 299 представляют успешное завершение действия, поэтому они могут передаваться только в сообщениях Disconnect-ACK или CoA-ACK и не могут передаваться в сообщениях Disconnect-NAK или CoA-NAK. Значения от 400 до 499 означают ошибку, совершенную на стороне RADIUS-сервера, поэтому они передаются внутри сообщений CoA-NAK или Disconnect-NAK, а не в CoA-ACK или Disconnect-ACK. Значения от 500 до 599 определяют ошибку, совершенную на стороне NAS-сервера или RADIUS Proxy, поэтому они передаются в пакетах CoA-NAK и Disconnect-NAK и не передаются в сообщениях CoA-ACK или Disconnect-ACK. Значения атрибута Error-Cause должны сохраняться на RADIUS-сервере. В таблице 2.11 приведены примеры значения поля Value.

Табл. 2.11. Значения поля Value

Значение

Описание

201

Residual Session Context Removed – этот параметр передается в ответном сообщении на Disconnect-Request, если пользовательская сессия больше не активна, но оставшийся контекст сеанса связи был найден и успешно удален. Параметр передается только в сообщении Disconnect-ACK

202

Invalid EAP Packet (Ignored) - это не фатальная ошибка RADIUS, передача полного описания которой не требуется

401

Unsupported Attribute – это ошибка, передаваемая в случае, если запрос содержит атрибуты (например, Vendor-Specific или EAP-Message), которые не поддерживаются системой

402

Missing Attribute – ошибка, передаваемая, если в запросе были пропущены обязательные атрибуты (например, атрибуты идентификации сессии).

403

NAS Identification Mismatch – ошибка, передаваемая, если один или несколько атрибутов идентификации NAS-сервера не совпадают с идентификаторами NAS, полученными в запросе

404

Invalid Request – ошибка, передаваемая в случае, если какие-либо параметры запроса не корректны, например, если один или несколько атрибутов имеют неверный формат

405

Unsupported Service – ошибка, передаваемая, если атрибут Service-Type в запросе содержит неверное или не поддерживаемое значение

406

Unsupported Extension – ошибка, передаваемая, если не поддерживаются сообщения из расширений протокола RADIUS (например, сообщения Disconnect или CoA). Обычно она посылается прокси сервером, при принятии на ICMP порт непонятного сообщения после попытки отправить запрос на NAS-сервер

501

Administratively Prohibited – ошибка, передаваемая, если NAS-сервер сконфигурирован так, что запрещает обработку запроса для специальных сесс
ий

502

Request Not Routable (Proxy) – ошибка, которая может быть передана RADIUS-прокси, и не может передаваться от NAS-сервера. Она определяет, что RADIUS-прокси не смог определить маршрут передачи запроса на NAS-сервер

503

Session Context Not Found – ошибка, передаваемая, если идентификатор контекста сеанса связи в Запросе не существует на NAS-сервере

504

Session Context Not Removable – ошибка, передаваемая в ответ на сообщение Disconnect-Request, если NAS-сервер определил положение контекста сессии, но не может использовать его по какой-либо причине. Он не может передаваться в сообщениях CoA-ACK, CoA-NAK или Disconnect-ACK, только в сообщении Disconnect-NAK

505

Other Proxy Processing Error – ошибка, передаваемая в ответ на Запрос, который не может быть обработан прокси-сервером, по причинам, не связанным с маршрутизацией

506

Resources Unavailable – ошибка, передаваемая, если Запрос не может быть обработан из-за нехватки ресурсов на NAS-севере

507

Request Initiated – ошибка, передаваемая в ответ на Запрос, содержащий атрибут Service-Type со значением «Authorize Only». Она означает, что сообщения Disconnect-Request или CoA-Request не могут быть обслужены, но так как Access-Request содержит Service-Type со значением «Authorize Only», то он будет отправлен на RADIUS-сервер

2.5.5.31. Digest-Response [RFC 4590]

Если этот атрибут представлен в сообщении Access-Request, то RADIUS-сервер должен обрабатывать это сообщение в соответствии с механизмом Цифровой Аутентификации (HTTP Digest Authentication). Когда RADIUS-клиент получает заголовок (Proxy-)Authorization, он должен вложить значение из него в атрибут Digest-Response.

Формат атрибута Digest-Response показан ниже. Поля передаются слева направо.



Text = когда используется HTTP кодировка, поле состоит из 32 байтов, и содержит десятичное представление 16-байтовых числовых значений, как они были вычислены клиентом (NAS). При использовании других алгоритмов (отличных от HTTP) длина поля может изменяться.

2.5.5.32. Digest-Realm [RFC 4590]

Этот атрибут описывает компоненты безопасности RADIUS-сервера при использовании HTTP Цифровой Аутентификации. Атрибут может передаваться только в сообщениях Access-Request и Access-Challenge.

Формат атрибута Digest-Realm показан ниже. Поля передаются слева направо.



Text = в сообщении Access-Requests клиент вставляет значение основных директив (основные директивы, описанные в [RFC2617]) без дополнительных HTTP-ссылок, необходимых для аутентификации. В сообщение Access-Challenge RADIUS-сервер вставляет ожидаемые основные директивы.

2.5.5.33. Digest-Nonce [RFC 4590]

Этот атрибут содержит специальное случайное число (nonce) из тех, что используются в вычислениях метода HTTP Digest аутентификации. Если Access-Request содержит атрибуты Digest-Method и Digest-URI, но не содержит Digest-Nonce, то RADIUS-сервер обязан вставить этот атрибут в сообщение Access-Challenge.

Формат атрибута Digest-Nonce показан ниже. Поля передаются слева направо.



Text = в сообщении Access-Requests RADIUS-клиент (NAS) вставляет значение специального случайного числа (nonce), параметр nonce-value из HTTP заголовков [RFC2617] без дополнительных параметров, используемых при HTTP аутентификации. В сообщении Access-Challenge атрибут содержит специальное случайное число (nonce), полученное RADIUS-сервером.

2.5.5.34. Digest-Response-Auth [RFC 4590]

Этот атрибут дает возможность RADIUS-серверу проверить правильность пароля. Если ранее принятый атрибут Digest-Qop имел значение «auth-int», то RADIUS-сервер должен послать атрибут Digest-HA1, вместо Digest-Response-Auth.

Формат атрибута Digest-Response-Auth показан ниже. Поля передаются слева направо.



Text = RADIUS-сервер вычисляет цифровое соответствие (RFC 2617, Section 3.2.3) и копирует результат в этот атрибут. Если алгоритм аутентификации отличен от описанного в RFC 2617, то длина поля может быть отличной от 32 байтов.

2.5.5.35. Digest-Nextnonce [RFC 4590]

Этот атрибут содержит специальное число (nonce) из тех, что используются в вычислениях метода HTTP Digest аутентификации. RADIUS-сервер может вставлять атрибут Digest-Nextnonce в сообщение Access-Accept. Если этот атрибут представлен, то RADIUS-клиент (NAS) должен вставить его содержимое в nextnonce директиву заголовка Authentication-Info в его HTTP-ответе.

Формат атрибута Digest-Nextnonce показан ниже. Поля передаются слева направо.



2.5.5.36. Digest-Method [RFC 4590]

Этот атрибут содержит значения методов, которые используются в вычислениях механизма HTTP Digest аутентификации. Этот атрибут может использоваться только в пакетах Access-Request.

Формат атрибута Digest-Method показан ниже. Поля передаются слева направо.



Text = в сообщении Access-Requests RADIUS-клиент берет значения необходимых методов из HTTP запросов, применяемых для аутентификации.

2.5.5.37. Digest-URI [RFC 4590]

Этот атрибут используется для передачи содержимого директив digest-uri или URI из HTTP запроса. Этот атрибут может использоваться только в пакетах Access-Request

Формат атрибута Digest-URI показан ниже. Поля передаются слева направо.



Text = если HTTP запрос имеет заголовок Authorization, то RADIUS-клиент помещает его значение «uri» в это поле без дополнительных ссылок. Если в запросе нет заголовка Authorization, то RADIUS-клиент берет значение запрашиваемой URI из HTTP запроса аутентификации.

2.5.5.38. Digest-Qop [RFC 4590]

Этот атрибут содержит параметры качества защиты, которые связаны с вычислением метода HTTP Digest аутентификации. RADIUS-клиент должен вставить один из атрибутов Digest-Qop, если в сообщении Access-Challenge он получил этот атрибут. RADIUS-сервер должен вставить хотя бы один атрибут Digest-Qop в сообщение Access-Challenge.

Формат атрибута Digest-Qop показан ниже. Поля передаются слева направо.



Text = для сообщения Access-Requests RADIUS клиент берет значение директивы qop из HTTP запроса аутентификации. В сообщении Access-Challenge RADIUS-сервер вставляет qop-value в атрибут. Если RADIUS-сервер поддерживает более одного значения «качества защиты», то он вставляет каждое значение в отдельный атрибут.

2.5.5.39. Digest-Algorithm [RFC 4590]

Этот атрибут содержит алгоритмы, которые связаны с вычислением метода HTTP Digest аутентификации. Этот атрибут может использоваться только в пакетах Access-Request и Access-Challenge. Если этот атрибут отсутствует, то его роль выполняет контрольная сумма MD5.

Формат атрибута Digest-Algorithm показан ниже. Поля передаются слева направо.



Text = для сообщения Access-Requests RADIUS-клиент берет значение директивы алгоритмов из HTTP запроса аутентификации. В сообщении Access-Challenge, в атрибут RADIUS-сервер вставляет нужный алгоритм работы из HTTP сообщения.

2.5.5.40. Digest-Entity-Body-Hash [RFC 4590]

При использовании уровня защиты (qop) «auth-int» для реализации механизма HTTP цифровой аутентификации необходимо использовать дополнительные параметры, содержащиеся в HTTP сообщениях. Поэтому вместо посылки всего сообщения достаточно передать только эти дополнительные параметры. Эти параметры используются для запуска процесса цифровой HTTP аутентификации.

Более подробно эти процедуры описаны в RFC 3261, для передачи дополнительных параметров в протоколе RADIUS используется атрибут Digest-Entity-Body-Hash. Этот атрибут передается только в сообщении Access-Request.

Формат атрибута Digest-Entity-Body-Hash показан ниже. Поля передаются слева направо.



Text = атрибут содержит десятичное представление дополнительных параметров (hash). Эти параметры нужны для организации процесса при качестве защиты, установленном в значении «auth-int». RADIUS-клиенты должны использовать эти атрибуты для передачи дополнительных параметров (hash) при цифровой HTTP аутентификации. При этом RADIUS-сервер должен проверять правильность этих значений. Возможно применение этого атрибута и для других способов аутентификации, не только цифровой HTTP аутентификации.

2.5.5.41. Digest-CNonce [RFC 4590]

Этот атрибут содержит набор специальных чисел (nonce), которые используются при цифровой HTTP аутентификации. Этот атрибут передается только в сообщении Access-Request.

Формат атрибута Digest-CNonce показан ниже. Поля передаются слева направо.



Text = этот атрибут содержит значения «cnonce-value» [RFC2617], без дополнительных ссылок из HTTP запроса.

2.5.5.42. Digest-Nonce-Count [RFC 4590]

Атрибут содержит вычисленные значения специальных чисел (nonce), которые используются для определения попыток атак или взлома сервера. Этот атрибут передается только в сообщении Access-Request.

Формат атрибута Digest-Nonce-Count показан ниже. Поля передаются слева направо.



Text = для этого поля в сообщении Access-Requests RADIUS-клиент (NAS) берет значение из nc директивы (nc-value по RFC2617) без дополнительных значений и ссылок из HTTP-запроса аутентификации.

2.5.5.43. Digest-Username [RFC 4590]

Этот атрибут содержит имя пользователя, используемое при цифровой HTTP-аутентификации. RADIUS-сервер должен использовать этот атрибут только при выполнения процедуры цифровой аутентификации (HTTP Digest Authentication). Обычно для определения прав доступа пользователя и его кредитоспособности RADIUS-сервер использует атрибут User-Name, а не Digest-Username. Этот атрибут передается только в сообщении Access-Request.

Формат атрибута Digest-Username показан ниже. Поля передаются слева направо.



Text = для сообщения Access-Request RADIUS клиент (NAS) берет значение из директивы username (username-value по RFC2617) без дополнительных ссылок из HTTP запроса аутентификации.

2.5.5.44. Digest-Opaque [RFC 4590]

Атрибут содержит защищенный (закрытый) параметр и передается к HTTP-клиенту. HTTP-клиент, в свою очередь, передает этот атрибут обратно на сервер (т.е. RADIUS-клиенту) без изменений. Передается атрибут только в сообщении Access-Request и Access-Challenge.

Формат атрибута Digest-Opaque показан ниже. Поля передаются слева направо.



Text = для сообщения Access-Requests RADIUS-клиент берет значение из защищенной директивы (opaque-value в соответствии с RFC2617) без дополнительных ссылок из HTTP-запроса аутентификации, и помещает его в этот атрибут. Для сообщений Access-Challenge, RADIUS-сервер вставляет ранее принятый аналогичный атрибут.

2.5.5.46. Digest-Auth-Param [RFC 4590]

Этот атрибут являет контейнером заполнения для будущих расширений и соотношений для параметра «auth-param», описанного в RFC2617. Digest-Auth-Param – это механизм, при помощи которого RADIUS-клиент и RADIUS-сервер могут обмениваться расширениями параметра «auth-param», содержащимися в HTTP-заголовке Digest, которые могут быть непонятны RADIUS-клиенту и для которых не предусмотрено отдельных атрибутов. В отличие от других Digest-атрибутов Digest-Auth-Param содержит не только значение, но и имя параметра, если это имя неизвестно RADIUS-клиенту. Если HTTP-заголовок Digest содержит несколько неизвестных параметров, то в RADIUS-сообщениях необходимо передать все эти параметры в повторяющихся атрибутах, но в них должна содержаться уникальная комбинация параметр/значение (Digest parameter/value).

Этот атрибут передается только в сообщениях Access-Request, Access-Challenge и Access-Accept.

Формат атрибута Digest-Auth-Param показан ниже. Поля передаются слева направо.



Text = текст содержит весь параметр целиком, включая его имя, знак равенства и значение (ссылку).

2.5.5.47. Digest-AKA-Auts [RFC 4590]

Этот атрибут содержит параметры «auts», которые используются в HTTP-процедуре Digest AKA согласно RFC3310. Он используется только в случае, если алгоритм распознавания процедуры цифровой аутентификации (Digest) указал на версию AKA Digest. Атрибут передается только в сообщении Access-Request.

Формат атрибута Digest-AKA-Auts показан ниже. Поля передаются слева направо.



Text = для сообщения Access-Requests RADIUS-клиент берет значение из директивы auts (auts-param [RFC3310]) без дополнительных значений из HTTP-запроса аутентификации.

2.5.5.48. Digest-Domain [RFC 4590]

Когда у RADIUS-клиента запрашивают специальные числа (nonce), то RADIUS-сервер может послать один или несколько атрибутов Digest-Domain в сообщении Access-Challenge. RADIUS-клиент помещает их внутрь ссылок, отдельной таблицы адресов (URI) директивы «domain» заголовка WWW-Authenticate.

Вместе с атрибутом Digest-Realm, таблица значений URI создает пространство доверительных сетей по RFC2617 для безопасной работы протоколов, производных от HTTP.

Этот атрибут передается только в сообщении Access-Challenge.

Формат атрибута Digest-Domain показан ниже. Поля передаются слева направо.



Text = этот атрибут содержит один URI, который определяет элемент доверительной безопасной сети.

2.5.5.49. Digest-Stale [RFC 4590]

Этот атрибут передается RADIUS-серверу для его извещения, принял ли RADIUS-клиент (NAS) специальное число (nonce) к работе. Если специальное число (nonce), с которым работает RADIUS-клиент (NAS) уже устарело, то выставляется значение «true», в противном случае «false». RADIUS-клиент помещает содержимое этого атрибута в директиву «stale» заголовка WWW-Authenticate, HTTP-запроса аутентификации.

Этот атрибут передается только в сообщении Access-Challenge.

Формат атрибута Digest-Stale показан ниже. Поля передаются слева направо.



Text = поле принимает значение ’true’ или ’false’.

2.5.5.50. Digest-HA1 [RFC 4590]

Этот атрибут используется для запуска генерации заголовка Authentication-Info. Атрибут должен передаваться в сообщении Access-Accept требуемое качество безопасности («qop») при этом должно иметь значение «auth-int».

Этот атрибут не передается, если параметр качества безопасности (qop) не определен или имеет значение «auth» (в этом случае используется атрибут Digest-Response-Auth).

Атрибут Digest-HA1 может быть послан к RADIUS-серверу или использован RADIUS-клиентом, если выполняется одно из следующих условий:

- значением атрибута Digest-Algorithm является ’MD5-sess’ или ’AKAv1-MD5-sess’;

- трафик между RADIUS-клиентом и RADIUS-сервером шифруется при помощи IPSec.

Этот атрибут передается только в сообщении Access-Accept.

Формат атрибута Digest-HA1 показан ниже. Поля передаются слева направо.



Text = это поле содержит десятеричное представление заголовка H(A1), описанного в RFC2617.

2.5.5.51. SIP-AOR [RFC 4590]

Этот атрибут используется для проведения авторизации по SIP сообщениям. Атрибут определяет URI, работа которого должна быть авторизована и аутентифицирована. RADIUS-сервер использует этот атрибут для авторизации в процессе обработки SIP-запросов. Атрибут SIP-AOR может быть получен, например, из заголовка «To» сообщения SIP REGISTER, или из заголовка «From» других запросов протокола SIP. Тем не менее, точное описание этого атрибута для SIP может изменяться в зависимости от новых разработок в протоколе. Атрибут может использоваться только в случае, когда RADIUS-клиент хочет авторизовать SIP-пользователей.

Этот атрибут передается только в сообщении Access-Request

Формат атрибута SIP-AOR показан ниже. Поля передаются слева направо.



Text = синтаксис этого поля соответствует или формату SIP URI по RFC 3261 или tel URI по RFC 3966.

Атрибут содержит полный адрес (URI), включая различные параметры. Он передается на RADIUS-сервер, который сам решает, какие из компонентов необходимы для проведения авторизации.

2.5.5.52. Framed-Management-Protocol [RFC 5607]

Атрибут необходим для индикации управляющего протокола прикладного уровня, используемого для доступа Framed Management. Атрибут может передаваться в сообщениях Access-Request и Access-Accept.

При получении NAS-сервером атрибута Framed-Management-Protocol в сообщении Access-Accept он должен установить этот механизм управления доступом или разорвать соединение. При невозможности распознавания или выполнения атрибута NAS-сервер должен считать, что получил сообщение Access-Reject.

Формат атрибута Framed-Management-Protocol показан ниже. Поля передаются слева направо.



Value = поле состоит из 4 байтов и может принимать значения:

1 SNMP (Simple Network Management Protocol)

2 Web-based (например, HTML поверх HTTP)

3 NETCONF (управление через NETCONF протокол)

4 FTP (File Transfer Protocol)

5 TFTP (Trivial File Transfer Protocol)

6 SFTP (SSH File Transfer Protocol)

7 RCP (программа удаленного копирования файлов на базе UNIX)

8 SCP (защищенная программа удаленного копирования файлов на базе UNIX)

2.5.5.53. Management-Transport-Protection [RFC 5607]

Этот атрибут показывает самый нижний уровень, на котором задействована система защиты или шифрования при передаче информации.

Когда защитный механизм для неразделенного потока запущен, это значит, что данная сессия инкапсулирована в защитные заголовки на транспортном уровне или туннелирована.

Когда NAS-сервер принимает этот атрибут, он должен обеспечить поддержку защиты на том же или лучшем уровне, чем это описано в атрибуте, или разорвать соединение.

Формат атрибута Management-Transport-Protection показан ниже. Поля передаются слева направо.



Value = поле имеет длину 4 байта и принимает значения:

1 - No-Protection – не требуется защита транспортного уровня.

2 - Integrity-Protection – на транспортном уровне должен использоваться защитный механизм, использующий шифрование с проверочными суммами.

3 - Integrity-Confidentiality-Protection – должна поддерживаться возможность различных механизмов защиты для входящего и исходящего трафика пользователя.

2.5.5.54. Management-Policy-Id [RFC 5607]

Атрибут указывает правила управления доступом для определенного пользователя. Разные правила управления доступом могут быть сформированы в единую систему, под индивидуальным названием.

Содержимое атрибута содержит наименования системы управления доступом в значениях, локальных для этого NAS.

Наименования, используемые в атрибуте, должны носить простой и монолитный характер, без вложенных структур и иерархий.

Формат атрибута Management-Policy-Id показан ниже. Поля передаются слева направо.



Text = поле состоит из одного или более байтов, и его содержимое зависит от настройки системы. Рекомендуется использовать кодировку UTF-8.

2.5.5.55. Management-Privilege-Level [RFC 5607]

Этот атрибут содержит номер уровня, наиболее подходящего для управления доступом при аутентификации пользователя. Атрибут может передаваться в сообщениях Access-Request и Access-Accept.

Формат атрибута Management-Privilege-Level показан ниже. Поля передаются слева направо.



Value = поле имеет длину 4 байта, и определяет подходящий уровень управления. Обычно принимается, что при использовании CLI минимальную привилегию имеет обращение через атрибут NAS-Prompt, а полную привилегию имеет Администратор.
2.6. Практические аспекты работы протокола RADIUS
Большое разнообразие атрибутов в RADIUS связано, в первую очередь, с разнообразием ситуаций, в которых используется протокол. Для примера можно рассмотреть несколько основных сценариев работы протокола RADIUS в сетях связи.

На рис. 2.10 приведен пример использования протокола RADIUS при предоставлении пользователям услуг доступа Dial-Up и учета абонента, подключенного к АТС телефонной сети общего пользования (ТфОП).



Рис. 2.10. Сценарий протокола RADIUS при предоставлении доступа Dial-Up

Следует обратить внимание на то, что содержание сообщений, приведенных ниже, может варьироваться в зависимости от задач ААА (например: учет по времени или объему переданной/принятой информации, протокол аутентификации PAP или CHAP и т.д.).

Если рассмотреть применение протокола в сетях следующего поколения NGN/IMS, то львиную долю сигнального трафика в них занимает SIP. Поэтому наиболее актуальным будет являться пример взаимодействия оборудования SIP-сети с RADIUS-сервером (рис. 2.11).



Рис. 2.11. Сценарий работы протокола RADIUS в системах SIP-телефонии

Далее приведен фрагмент текста описания сессии на языке SIP с указанием ссылок в квадратных скобках на документы, указанные в списке литературы в работе [1] :



INVITE

sip:97226491335@example.com SIP/2.0

From:

To:



SIP/2.0 100 Trying



Access-Request

Length = 97

Authenticator = F5E55840E324AA49D216D9DBD069807C

NAS-IP-Address = 192.0.2.38 [4]

NAS-Port = 5 [5]

User-Name = 12345678 [1]

Digest-Method = INVITE [108]

Digest-URI = sip:97226491335@example.com [109]

Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B [80]



Access-challenge

Length = 72

Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D

Digest-Nonce = 3bada1a0 [105]

Digest-Realm = example.com [104]

Digest-Qop = auth [110]

Digest-Algorithm = MD5 [111]

Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3 [80]



SIP/2.0 407 Proxy Authentication Required

Proxy-Authenticate: Digest realm="example.com"

,nonce="3bada1a0",qop=auth,algorithm=MD5

Content-Length: 0



ACK

sip:97226491335@example.com SIP/2.0



INVITE

sip:97226491335@example.com SIP/2.0

Proxy-Authorization: Digest nonce="3bada1a0"

,realm="example.com"

,response="756933f735fcd93f90a4bbdd5467f263"

,uri="sip:97226491335@example.com",username="12345678"

,qop=auth,algorithm=MD5

,cnonce="56593a80,nc="00000001"

From:

To:



Access-Request

Length = 221

Authenticator = F5E55840E324AA49D216D9DBD069807D

NAS-IP-Address = 192.0.2.38 [4]

NAS-Port = 5 [5]

User-Name = 12345678 [1]

Digest-Method = INVITE [108]

Digest-URI = sip:97226491335@example.com [109]

Digest-Realm = example.com [104]

Digest-Qop = auth [110]

Digest-Algorithm = MD5 [111]

Digest-CNonce = 56593a80 [113]

Digest-Nonce = 3bada1a0 [105]

Digest-Nonce-Count = 00000001 [114]

Digest-Response = 756933f735fcd93f90a4bbdd5467f263 [103]

Digest-Username = 12345678 [115]

SIP-AOR = sip:12345678@example.com [122]

Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60 [80]



Access-Accept

Length = 72

Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2

Digest-Response-Auth = f847de948d12285f8f4199e366f1af21 [106]

Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E [80]



SIP/2.0 180 Ringing



SIP/2.0 200 OK



ACK sip:97226491335@example.com SIP/2.0



Можно увидеть Authenticator в нескольких операциях SIP сессии.



Зарегистрируйтесь на ontext.info для получения дополнительных возможностей по работе с сервисом.