RFC: 2865
Оригинал: Remote Authentication Dial In User Service (RADIUS)
Предыдущие версии: RFC 2058, RFC 2138
Категория: Проект стандарта
Дата публикации:
Авторы: , , ,
Перевод: Николай Малых

2. Работа протокола

Когда клиент настроен на использование RADIUS, каждый пользователь должен предоставить клиенту свою идентификационную информацию. Это может выполняться в форме приглашения на вход в систему (login prompt), где пользователь должен ввести свое регистрационное имя и пароль. Другим вариантом может быть использование канальных протоколов типа PPP (Point-to-Point Protocol), в которых поддерживаются специальные пакеты идентификации для передачи сведений о пользователе.

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

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

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

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

Если в запросе Access-Request присутствует хотя бы один атрибут Proxy-State, такой атрибут должен без каких-либо изменений копироваться в пакет отклика. Другие атрибуты могут до атрибутов Proxy-State, после них и даже между такими атрибутами.

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

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

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

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

2007 - 2018 © Русские переводы RFC, IETF, ISOC.