Previous: 4.5.3 Удаленный доступ (Telnet)    UP: 4.5 Процедуры Интернет
Down: 4.5.8 Поиск узлов и людей
    Next: 4.5.4 Протокол пересылки файлов FTP

Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin).

Модель клиент/сервер

Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные.

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

Сервер RADIUS может выполнять функцию прокси-клиента по отношению к другим серверам RADIUS или прочим аутентификационным серверам.

Сетевая безопасность

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

Гибкие аутентификационные механизмы

Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами.

Масштабируемый протокол

Все операции подразумевают использование ансамблей атрибут-длина-значение. Новое значение атрибута может быть добавлено без редактирования существующей версии реализации протокола.

В этом документе используются следующие термины:

Когда клиент сконфигурирован для использования RADIUS, любой пользователь предоставляет аутентификационные данные клиенту. Это может быть сделано с помощью традиционной процедуры login, когда пользователь вводит свое имя и пароль. В качестве альтернативы может использоваться протокол типаPPP, который имеет специальные пакеты, несущие аутентификационную информацию.

Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]).

Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен.

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

Если хотя бы какое-то условие не выполнено, сервер посылает отклик "Access-Reject" (отклонение Access-Reject текст комментария.

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

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

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

Пакет Access-Challenge обычно содержит сообщение-ответ, включая приглашение (challenge), которое должно быть отображено для пользователя. Обычно оно имеет форму числа и получается от внешнего сервера, который знает, какого типа аутентификатор должен быть применен для данного авторизованного пользователя и, следовательно, может выбрать псевдослучайное число заданной длины.

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

Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение "challenge", но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой "Challenge 12345678, enter your response at the prompt", которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge.

Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя.. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP.

Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP.

Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае - Access-Reject.

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

Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:

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

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

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

Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на рис. .1. Разряды пронумерованы в порядке их передачи.

Рис. .1. Формат пакета RADIUS

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

Стандартизованы следующие значения поля код:

Коды 4 и 5 будут описаны в документе [RFC-2139]. Коды 12 и 13 зарезервированы для возможного использования.

Поле идентификатор имеет один октет, и служит для установления соответствия между запросом и откликом.

Поле длина имеет два октета. Оно определяет длину пакета, включая поля код, идентификатор, длина, аутентификатор и атрибуты. Октеты за пределом, указанным полем длина, рассматриваются как заполнитель и игнорируются получателем. Если пакет короче, чем указано в поле длина, он должен быть молча выкинут. Минимальная длина равна 20, а максимальная - 4096.

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

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

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

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

NAS и сервер RADIUS используют секретный пароль совместно. Этот секретный пароль и аутентификатор запроса пропускаются через хэширование MD5, чтобы получить 16-октетный дайджест, который объединяется посредством операции XOR с паролем, введенным пользователем, результат помещается в атрибут пароля пользователя пакета Access-Request.

Значение поля аутентификатор в пакетах Access-Accept, Access-Reject, и Access-Challenge называется аутентификатором отклика (Response Authenticator). Оно представляет собой однопроходную хэш-функцию MD5, вычисленную для потока октетов, включающих в себя: пакет RADIUS, начинающийся с поля код, и включающий поля идентификатор, длина, аутентификатор запроса из пакета Access-Request, и атрибуты отклика, за которыми следует общий секретный пароль. То есть ResponseAuth = MD5(Код+ID+длина+RequestAuth+атрибуты+секретный_пароль) где знак + означает присоединение.

Секретный пароль, совместно используемый клиентом и сервером RADIUS, должен быть достаточно большим и непредсказуемым, как хороший пароль. Желательно, чтобы секретный пароль имел, по крайней мере, 16 октетов. Сервер RADIUS должен использовать IP-адрес отправителя UDP-пакета, чтобы решить, какой секретный пароль использовать.

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

Атрибуты

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

В данном документе регламентированы атрибуты для пакетов с полем код, равным 1, 2, 3 и 11. Чтобы определить, какие атрибуты допускаются для пакетов с полем код=4 и 5, смотри [9].

Тип пакета RADIUS определяется полем тип, размещенным в первом октете.

Пакеты Access-Request посылаются серверу RADIUS, и передают информацию, которая используется для определения того, позволен ли данному пользователю доступ к специфицированному NAS, и допустимы ли запрошенные услуги. Программная реализация, желающая аутентифицировать пользователя, должна послать пакет RADIUS с кодом поля тип=1 (Access-Request).

При получении запроса (Access-Request) доступа от корректного клиента, должен быть передан соответствующий ответ. Запрос доступа (Access-Request) должен содержать атрибут имени пользователя. Он должен включать в себя атрибут NAS-IP-адреса или атрибут NAS-идентификатора (или оба эти атрибута, хотя это и не рекомендуется). Он должен содержать атрибут пароля пользователя (User-Password) или атрибут CHAP-пароля. Желательно, чтобы он содержал атрибут NAS-порта или NAS-Port-Type или оба эти атрибута, если только тип запрошенного доступа не содержал номер порта.

Запрос доступа (Access-Request) может содержать дополнительные атрибуты - подсказки серверу, но последний не обязан следовать этим подсказкам. Когда присутствует пароль пользователя (User-Password), он защищается с использованием метода, базирующегося на RSA алгоритме MD5 [1]. Формат пакета Access-Request аналогичен показанному на рис. .1. Только на месте поля аутентификатор размещается поле аутентификатор запроса (Request Authenticator), а в поле код записывается 1.

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

Значение поля аутентификатор запроса (Request Authenticator) должно изменяться, когда используется новый идентификатор.

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

Пакеты Access-Accept посылаются сервером RADIUS, и предоставляют специфическую конфигурационную информацию, необходимую для предоставления пользователю соответствующего сервиса. Если все значения атрибутов, полученных с запросом Access-Request, приемлемы, тогда реализация RADIUS должна послать пакет с полем код=2 (Access-Accept). При получении сообщения Access-Accept, поле идентификатор соответствует обрабатываему запросу (Access-Request). Кроме того, поле аутентификатор отклика должно содержать корректный отклик на полученный запрос Access-Request. Пакеты неверного формата молча отбрасываются. Формат пакета Access-Accept идентичен показанному на рис. .1. Но здесь вместо поля аутентификатор используется поле аутентификатор отклика, имеющее тот же размер. В поле код при этом записывается число 2.

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

Значение поля аутентификатор отклика (Response Authenticator) вычисляется на основе значения Access-Request, как это описано выше. Поле атрибуты имеет переменную длину и содержит список из нуля или более атрибутов.

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

Значение поля аутентификатор отклика вычисляется на основе содержимого сообщения Access-Request, как это описано выше.

Если сервер RADIUS хочет послать пользователю вызов, требующий отклика, то сервер должен реагировать на запрос Access-Request посылкой пакета с полем код=11 (Access-Challenge). Поле атрибуты может содержать один или более атрибутов Reply-Message, и может опционно включать атрибут состояния. Никакие другие атрибуты здесь не применимы.

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

Если сервер NAS поддерживает обмен вызов/отклик, получение корректного сообщения Access-Challenge указывает, что следует послать новый запрос Access-Request. Сервер NAS может отобразить текстовое сообщение для пользователя, если таковое имеется, а затем предложить ему ввести отклик. Затем сервер посылает исходное сообщение Access-Request с новым идентификатором запроса и аутентификатором отклика, с атрибутом пароля пользователя, содержащим зашифрованный отклик пользователя. Кроме того, это сообщение содержит атрибут состояния (State) сообщения Access-Challenge, если таковой имелся.

NAS, который поддерживает PAP может переадресовать сообщение Reply-Message клиенту, подключенному по модемному каналу, и принять PAP-отклик, который он может использовать как отклик, введенный пользователем. Если NAS этого сделать не может, он должен воспринимать Access-Challenge, как если бы он получил сообщение Access-Reject. Формат пакета Access-Challenge совпадает с форматом Access-Accept и Access-Request.

Поле идентификатор является копией одноименного поля пакета Access-Request, который вызвал посылку Access-Challenge.

Значение аутентификатора отклика вычисляется так, как это было описано выше. Поле атрибуты имеет переменную длину, и содержит список из нуля или более атрибутов.

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

Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина. Формат записи атрибута показан на рис. .2.

Рис. .2. Формат записи атрибута

Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 "Assigned Numbers" [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа.

Таблица .1. Cпецификация стандартизованных значений атрибутов

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

Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина. Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.

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

Рис. .3. Формат атрибута

Поле тип=1, длина ³ 3. Поле строка имеет один или более октетов. NAS может ограничить максимальную длину имени пользователя, но рекомендуется, чтобы программа была способна обрабатывать как минимум 63 октета. Применяется несколько форматов имени пользователя:

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

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

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

Данный метод заимствован из книги "Network Security" Кауфмана, Пелмана и Спесинера [4; стр. 109-110]. Более формализовано алгоритм можно описать следующим образом:

Берется общий секретный ключ S и псевдослучайный 128-битный аутентификатор запроса RA. Пароль разбивается на 16-октетные блоки p1, p2, ., pi. последний из них дополняется нулями до размера кратного 16 октетам. Далее реализуется алгоритм MD5. Берутся блоки шифрованного текста c(1), c(2), ., c(i), получаются промежуточные значения b1, b2, . bi:

Поле строка будет содержать c(1)+c(2)+...+c(i), где знак + означает присоединение.

При получении осуществляется обратный процесс и получается исходная форма пароля. В результате формируется атрибут, где в поле тип записан код 2, в поле длина число в интервале 18-130, а в поле строка - 16-128 октетов зашифрованного пароля.

Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае - в поле аутентификатор запроса. Формат атрибута CHAP-Password показан на рис. .4.

Рис. .4. Формат атрибута CHAP-Password

Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя.

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

Рис. .5 Формат атрибута NAS-IP-Address

Поле адрес имеет протяженность 4 октета (IPv4).

Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на рис. .6.

Рис. .6. Формат атрибута NAS-порт

Диапазон кодов в поле значение составляет 0 - 65535.

Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт. Только поле тип=6. Коды поля значение перечислены в таблице .2..

Таблица .2. Коды поля значение

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

Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (рис. .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3.

Таблица .3. Коды поля значение

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

Поле тип = 8, поле длина = 6.

Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя.

Этот атрибут указывает на сетевую IP-маску, которая должна быть сконфигурирована для пользователя, когда он является маршрутизатором сети. Атрибут может использоваться в пакетах Access-Accept. Он может использоваться в пакете Access-Request в качестве подсказки NAS серверу относительно того, какую сетевую маску он предпочитает. Но сервер не обязан следовать этой подсказке. Формат записи атрибута аналогичен формату атрибута NAS-IP-адрес. Поле тип = 9, поле длина = 6. Поле адрес имеет 4 октета и определяет сетевую IP-маску.

5.10. Атрибут Framed-Routing

Этот атрибут указывает метод маршрутизация для пользователя, когда пользователем является маршрутизатор сети. Атрибут может использоваться в пакетах Access-Accept. Формат записи атрибута аналогичен показанному на рис. .6 (NAS-порт). Поле тип = 10, поле длина = 10. Допустимые коды и их назначения собраны в таблице .4

Таблица .4. Допустимые коды поля значение и их назначения

Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует рис. .3. поле тип = 11, поле длина ³ 3.

Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов.

Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535.

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

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

Формат атрибута аналогичен показанному на рис. 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5.

Таблица .5. Возможные коды поля значение

Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на рис. .5. Поле тип = 14, а поле длина = 6.

Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя.

Этот атрибут указывает на услугу, которая будет использоваться для соединения пользователя с ЭВМ. Атрибут применяются только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 15, а поле длина = 6. Возможные коды поля значение собраны в таблице .6.

Таблица .6. Возможные коды поля значение

Этот атрибут указывает порт TCP, с которым следует соединить пользователя при наличии атрибута Login-Service. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 16, а поле длина = 6. Поле значение имеет четыре октета и может содержать величины в диапазоне 0 - 65535.

Этот атрибут содержит текст, который может быть отображен для пользователя. Если используется в пакете Access-Accept, это сообщение об успешном выполнении. При использовании с Access-Reject, это уведомление о неудаче. Это может быть элемент диалога с пользователем перед очередной попыткой послать запрос доступа (Access-Request).

Когда атрибут используется в Access-Challenge, он может содержать приглашение пользователю ввести отклик. Допускается применение нескольких атрибутов Reply-Message, в этом случае они должны отображаться в порядке из записи в пакете. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 18, а поле длина ³ 3.

Поле строка содержит один или более октетов. Его содержимое может зависеть от конкретной программной реализации. Содержимое должно быть читабельным и не должно влиять на работу протокола. Рекомендуется, чтобы текст состоял из печатных ASCII символов с кодами 10, 13 и 32 - 126.

Этот атрибут представляет собой телефонный номер, используемый для обратного дозвона. Атрибут может использоваться в пакетах Access-Accept, а также в Access-Request в качестве подсказки серверу о том, что желателен обратный дозвон, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 19, а поле длина ³ 3.

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

Этот атрибут содержит имя места вызова, которое должно быть интерпретировано сервером NAS. Атрибут может использоваться пакетами Access-Accept. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 20, а поле длина ³ 3.

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

Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 22, а поле длина ³ 3.

Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 - 126.

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

Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя. Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 23, а поле длина = 6.

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

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

Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 24, а поле длина ³ 3.

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

Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 25, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

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

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

Рис. .7. Формат записи атрибута Vendor-Specific

Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой.

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

Рис. .8. Пример формата строки

Поле строка предназначено для записи параметров, специфических для данного производителя.

Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 27, а поле длина = 6.

Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS).

Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 28, а поле длина = 6.

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

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

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

Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь. При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 30, поле длина ³ 3.

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

Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI - Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 31, поле длина ³ 3.

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

Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 32, а поле длина ³ 3.

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

Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge. Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 33, а поле длина ³ 3.

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

Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации.

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

Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 34, а поле длина ³ 3.

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

Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 35, а поле длина ³ 3.

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

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

Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту. Старший октет передается первым.

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

Поле значение имеет 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk.

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

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

Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на рис. .3. Поле тип = 39, а поле длина ³ 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя.

Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на рис. .3. Поле тип = 60, а поле длина ³ 7. Поле строка содержит сообщение CHAP Challenge.

Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на рис. .6. Поле тип = 61, а поле длина =6.

Поле значение имеет 4 октета. "Виртуальный" (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом.

Таблица .7. Код поля значение атрибута NAS-Port-Type

Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на рис. .6. Поле тип = 62, а поле длина = 6.

Поле значение имеет 4 октета и содержит 32-битовое целое число без знака, которое определяет максимальное число портов, к которым пользователь может быть подключен сервером NAS.

Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на рис. .3. Поле тип = 63, а поле длина ³ 3.

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

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

Таблица .8. Основные характеристики атрибутов

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

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3.

Code = 1 (Access-Request)
ID = 0
Request Authenticator = {16-октетное случайное число}
Атрибуты:
User-Name = "NEMO"

User-Password = {16-октетный пароль, дополненный в конце нулями и объединенный операцией XOR с MD5(общий секретный пароль|Request Authenticator)}

NAS-IP-Address = 192.168.1.16
NAS-Port = 3

Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом.

Code = 2 (Access-Accept)
ID = 0 (то же самое, что и в Access-Request)
Response Authenticator = {16-октетная контрольная сумма MD-5 кода (2),

id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля }

Атрибуты:
Service-Type = Login-User
Login-Service = Telnet
Login-Host = 192.168.1.3

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP-пакете серверу RADIUS для пользователя с именем VANYA для подключения к порту 20 в рамках протокола PPP. Аутентификация осуществляется посредством CHAP. NAS посылает атрибуты Service-Type и Framed-Protocol в качестве рекомендаций серверу RADIUS воспользоваться PPP, хотя NAS необязательно этому последует.

Code = 1 (Access-Request)
ID = 1

Request Authenticator = {16-октетное случайное число, используется также в вызове CHAP (CHAP challenge)}

Атрибуты:
User-Name = " VANYA"

CHAP-Password = {1 октет идентификатора CHAP, за которым следует 16 октетов CHAP-отклика}

NAS-IP-Address = 192.168.1.16
NAS-Port = 20
Service-Type = Framed-User
Framed-Protocol = PPP

Сервер RADIUS аутентифицирует VANYA и посылает запрос Access-Accept в UDP-пакете серверу NAS, сообщая, что он отрывает PPP-сессию и приписывает адрес пользователю из имеющегося у него списка.

Code = 2 (Access-Accept)
ID = 1 (тот же, что и в Access-Request)
Response Authenticator = {16-октетов контрольной суммы MD-5 кода (2), ID (1), Request Authenticator, приведенного выше, атрибутов этого отклика и общего секретного пароля}

Атрибуты:
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = 255.255.255.254
Framed-Routing = None
Framed-Compression = 1 (Компрессия заголовка VJ TCP/IP)
Framed-MTU = 1500

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request серверу RADIUS для пользователя с именем MANYA, подключаемого к порту 7.

ID = 2
Request Authenticator = {16 октетов случайного числа }

Атрибуты:
>User-Name = " MANYA"
User-Password = {16 октетов пароля дополненные в конце нулями,
объединенный функцией XOR с MD5 (общий секретный ключ |Request Authenticator)}
NAS-IP-Address = 192.168.1.16
NAS-Port = 7

Сервер RADIUS решает вызвать MANYA, отсылая назад строку вызова и ожидая отклика. Сервер RADIUS посылает запрос Access-Challenge серверу NAS.

Response Authenticator = {16-октетов контрольной суммы MD-5 кода (11), ID (2), Request Authenticator, представленный выше, атрибуты данного отклика и общий секретный пароль}

Атрибуты:
Reply-Message = "Challenge 32769430. Enter response at prompt."
State = {Код, который должен быть прислан вместе с откликом пользователя }

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

Request Authenticator = {Новое 16-октетное число}

Атрибуты:

User-Name = " MANYA"

User-Password = {16 октетов отклика дополненного в конце нулями и объединенного функцией XOR с контрольной суммой MD5 общего секретного пароля и представленного выше аутентификатора запроса (Request Authenticator)}

NAS-IP-Address = 192.168.1.16

NAS-Port = 7

Отклик был некорректен, поэтому сервер RADIUS предлагает NAS отклонить попытку входа в систему.

Response Authenticator = {16-октетов контрольной суммы MD-5 кода (3), ID (3), описанного выше Request Authenticator, атрибутов этого отклика (если таковые имеются) и общего секретного пароля}

Атрибуты:

(отсутствуют, хотя сообщение Reply-Message может быть послано)

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

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

Previous: 4.5.3 Удаленный доступ (Telnet)    UP: 4.5 Процедуры Интернет
Down: 4.5.8 Поиск узлов и людей    Next: 4.5.4 Протокол пересылки файлов FTP