Статус документа
Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2000). Все права защищены.
Примечание IESG
Этот протокол имеет множество реализаций и используется достаточно широко. Опыт показывает возможность снижения производительности и потери данных при использовании протокола в больших масштабируемых системах. Это обусловлено отчасти тем, что протокол не включает средств контроля насыщения. Интересующиеся читатели могут обратиться к документам рабочей группы AAA в составе IETF, результатом деятельности которой может стать следующий вариант протокола лучше приспособленный для больших систем и обеспечивающий контроль насыщения.
Тезисы
В этом документе описан протокол, используемый для идентификации (authentication), проверки полномочий (authorization) и установки конфигурационных параметров в серверах доступа, которые хотят работать с идентифицированными пользователями, информация о которых содержится на разделяемом сервере идентификации (Authentication Server).
Замечания для разработчиков
В этом документе содержится спецификация протокола RADIUS. Первые версии протокола RADIUS использовали протокол UDP через порт 1645, что приводило к возникновению конфликтов со службами datametrics. Официально для протокола RADIUS выделен порт 1812.
Оглавление
- 1. Введение
- 1.1. Спецификация уровня требований
- 1.2. Терминология
- 2. Работа протокола
- 2.1. Режим Challenge/Response
- 2.2. Взаимодействие с PAP и CHAP
- 2.3. Сервер-посредник (Proxy)
- 2.4. Почему UDP?
- 2.5. Рекомендации по передаче повторов
- 2.6. Пагубность запросов Keep-Alive
- 3. Формат пакетов
- 4. Типы пакетов
- 4.1. Пакет Access-Request
- 4.2. Пакет Access-Accept
- 4.3. Пакет Access-Reject
- 4.4. Пакет Access-Challenge
- 5. Атрибуты
- 5.1. User-Name
- 5.2. User-Password
- 5.3. CHAP-Password
- 5.4. NAS-IP-Address
- 5.5. NAS-Port
- 5.6. Service-Type
- 5.7. Framed-Protocol
- 5.8. Framed-IP-Address
- 5.9. Framed-IP-Netmask
- 5.10. Framed-Routing
- 5.11. Filter-Id
- 5.12. Framed-MTU
- 5.13. Framed-Compression
- 5.14. Login-IP-Host
- 5.15. Login-Service
- 5.16. Login-TCP-Port
- 5.17. (не используется)
- 5.18. Reply-Message
- 5.19. Callback-Number
- 5.20. Callback-Id
- 5.21. (не используется)
- 5.22. Framed-Route
- 5.23. Framed-IPX-Network
- 5.24. State
- 5.25. Class
- 5.26. Vendor-Specific
- 5.27. Session-Timeout
- 5.28. Idle-Timeout
- 5.29. Termination-Action
- 5.30. Called-Station-Id
- 5.31. Calling-Station-Id
- 5.32. NAS-Identifier
- 5.33. Proxy-State
- 5.34. Login-LAT-Service
- 5.35. Login-LAT-Node
- 5.36. Login-LAT-Group
- 5.37. Framed-AppleTalk-Link
- 5.38. Framed-AppleTalk-Network
- 5.39. Framed-AppleTalk-Zone
- 5.40. CHAP-Challenge
- 5.41. NAS-Port-Type
- 5.42. Port-Limit
- 5.43. Login-LAT-Port
- 5.44. Таблица атрибутов
- 6. Согласование с IANA
- 6.1. Определения терминов
- 6.2. Рекомендуемая политика регистрации
- 7. Примеры
- 7.1. Telnet-доступ к заданному хосту
- 7.2. Framed-сервис с использованием аутентификации CHAP
- 7.3. Пользователь подключается с помощью карты Challenge-Response
- 8. Вопросы безопасности
- 9. Журнал изменений
- 10. Литература
- 11. Подтверждение
1. Введение
Данный документ заменяет RFC 2138 [1]. Сводка изменений по сравнению с RFC 2138 приведена в приложении "Журнал изменений".
Управление распределенной системой доступа по телефонным линиям и модемными пулами в сетях с большим числом пользователей может потребовать от администраторов значительных усилий. Поскольку модемный пул по определению является открытой дверью, требуется повышенное внимание к идентификации пользователей, проверке их полномочий и учету работы (accounting). Наиболее эффективное решение может быть обеспечено путем создания единой "базы данных" о пользователях, которая применяется при идентификации (проверка имени пользователя и пароля), установке конфигурационных параметров и выборе типа сервиса, предоставляемого пользователю (например, SLIP, PPP, telnet, rlogin).
Основными преимуществами протокола RADIUS являются:
Архитектура "Клиент-Сервер"
Сервер доступа (NAS, Network Access Server — сервер доступа в сеть) выступает в качестве клиента RADIUS. Клиент отвечает за передачу сведений о пользователе заданным серверам RADIUS и дальнейшие действия в зависимости от возвращенной сервером информации.
Серверы RADIUS отвечают за прием клиентских запросов, идентификацию пользователей и возврат клиенту всех конфигурационных параметров, требуемых для предоставления пользователю соответствующих услуг.
Сервер RADIUS может выступать в качестве клиента-посредника (proxy client) других серверов RADIUS или серверов идентификации иного типа.
Безопасность
Аутентификация транзакций между клиентом и сервером RADIUS осуществляется с использованием разделяемого ключа (shared secret), который никогда не передается через сеть. В дополнение к этому пользовательские пароли между клиентами и серверами RADIUS передаются в зашифрованном виде во избежание перехвата паролей при их передаче через незащищенные сети.
Гибкость механизмов идентификации
Сервер RADIUS может поддерживать широкий спектр методов идентификации пользователей. При получении регистрационного имени и пароля, указанных пользователем, сервер может может поддерживать дополнительные механизмы, включая PPP PAP или CHAP, UNIX login и т.п.
Возможность расширения
Все протокольные транзакции представляются в форме триплетов "атрибут-размер-значение". Новые атрибуты могут добавляться без нарушения работы существующих реализаций протокола.
Атрибут-размер-значение — Attribute-Length-Value. В последнее время для таких триплетов чаще используют обозначение TLV (Type-Length-Value — тип-размер-значение). Прим. перев.