Аутентификация и хранение учетных записей
Атрибуты для поддержки MS-CHAP V2
Рассмотрим RADIUS-атрибуты, необходимые для поддержки второй версии протокола MS-CHAP. Протокол MS-CHAP-V2 аналогичен, но не совместим с протоколом MS-CHAP-V1. Некоторые поля удалены или используются по-другому. Протокол MS-CHAP-V2 максимально согласован как с протоколом MS-CHAP-V1, так и со стандартным протоколом СНАР.
Кратко различия между протоколами MS-CHAP-V2 и MS-CHAP-V1 следующие:
- Протокол MS-CHAP-V2 дает возможность вести переговоры об алгоритме.
- Протокол MS-CHAP-V2 предоставляет возможность взаимной аутентификации участников, посылая вызов противоположной стороне в пакете Response и аутентифицируя ответ в пакете Success.
- Вычисление поля "Windows NT compatible challenge response" в пакете Response изменено на вызов и имя пользователя противоположной стороны.
- В протоколе MS-CHAP-V1 поле "LAN Manager compatible challenge response" всегда посылается в пакете Response. В протоколе MS-CHAP-V2 данное поле заменено на поле Peer-Challenge.
- Формат поля Message в пакете Failure изменен.
- Пакеты Change Password (версии 1) и Change Password (версии 2) больше не поддерживаются. Они заменены на единственный пакет Change-Password.
Соответствующие атрибуты отражают эти различия.
Атрибут MS-CHAP2-Response
Данный атрибут содержит ответ, предоставленный противоположной стороной. Атрибут используется только в пакетах Access-Accept.
Атрибут MS-CHAP2-Success
Данный атрибут содержит ответ длиной 42 октета. Данная строка содержит поле Message из пакета Success, который посылался от NAS к противоположной стороне. Данный атрибут используется только в пакетах Access-Accept.
Атрибут MS-CHAP2-CPW
Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут используется только совместно с атрибутом MS-CHAP-NT-Enc-PW2в пакетах Access-Request и включен только если в непосредственно предшествующий пакет Access-Reject был включен атрибут MS-CHAP-Error, указывающий, что пароль пользователя истек, и версия MS-CHAP равна 3.
Атрибуты для поддержки МРРЕ
Рассмотрим атрибуты, разработанные для поддержки протокола Microsoft Point-to-Point Encryption (MPPE). Протокол МРРЕ обеспечивает способ передачи РРР-пакетов в зашифрованном виде. В протоколе МРРЕ для шифрования используется алгоритм RC4. Могут вестись переговоры о длине ключа сессии для инициализации таблиц шифрования.
Атрибут MS-CHAP-MPPE-Keys
Атрибут MS-CHAP-MPPE-Keys содержит два ключа сессии, которые будут использоваться в протоколе МРРЕ. Данный атрибут включается только в пакеты Access-Accept.
Атрибут MS-MPPE-Send-Key
Атрибут MS-MPPE-Send-Key содержит ключ сессии, который будет использоваться в протоколе МРРЕ. Считается, что этот ключ используется для шифрования пакетов, посылаемых от NAS к удаленному хосту. Данный атрибут включается только в пакеты Access-Accept.
Атрибут MS-MPPE-Recv-Key
Атрибут MS-MPPE-Recv-Key содержит ключ сессии, который будет использоваться в протоколе МРРЕ. Считается, что данный ключ используется для шифрования пакетов, получаемых NAS от противоположной стороны. Данный атрибут включается только в пакеты Access-Accept.
Атрибут MS-MPPE-Encryption-Policy
Атрибут MS-MPPE-Encryption-Policy используется для указания того, что шифрование требуется или нет. Если поле Policy равно 1 (Encryption-Allowed), то может использоваться любой из типов шифрования, указанный в атрибуте MS-MPPE-Encryption-Types, или не использоваться ни один. Если поле Policy равно 2 (Encrypted-Required), то любой из типов шифрования, указанный в атрибуте MS-MPPE-Encrypted-Types, может использоваться, но по крайней мере один должен использоваться.
Атрибут MS-MPPE-Encryption-Types
Атрибут MS-MPPE-Encryption-Types используется для указания типов шифрования, которые могут использоваться в протоколе МРРЕ. Атрибут является 4-х октетным целым, которое интерпретируется как строка битов.
В приведенной ниже таблице описано, какие атрибуты и в каком количестве могут содержаться в пакетах.
| Request | Accept | Reject | Challenge | Атрибут |
|---|---|---|---|---|
| 0-1 | 0-1 | 0 | 0 | User-Name |
| 0-1 | 0 | 0 | 0 | User-Password |
| 0-1 | 0 | 0 | 0 | CHAP-Password |
| 0-1 | 0 | 0 | 0 | NAS-IP-Address |
| 0-1 | 0 | 0 | 0 | NAS-Port |
| 0-1 | 0-1 | 0 | 0 | Service-Type |
| 0-1 | 0-1 | 0 | 0 | Framed-Protocol |
| 0-1 | 0-1 | 0 | 0 | Framed-IP-Address |
| 0-1 | 0-1 | 0 | 0 | Framed-IP-Netmask |
| 0 | 0-1 | 0 | 0 | Framed-Routing |
| 0 | 0+ | 0 | 0 | Filter-Id |
| 0-1 | 0-1 | 0 | 0 | Framed-MTU |
| 0+ | 0+ | 0 | 0 | Framed-Compression |
| 0+ | 0+ | 0 | 0 | Login-IP-Host |
| 0 | 0-1 | 0 | 0 | Login-Service |
| 0 | 0-1 | 0 | 0 | Login-TCP-Port |
| 0 | 0+ | 0+ | 0+ | Reply-Message |
| 0-1 | 0-1 | 0 | 0 | Callback-Number |
| 0 | 0-1 | 0 | 0 | Callback-Id |
| 0 | 0+ | 0 | 0 | Framed-Route |
| 0-1 | 0-1 | 0 | 0-1 | State |
| 0 | 0+ | 0 | 0 | Class |
| 0+ | 0+ | 0 | 0+ | Vendor-Specific |
| 0 | 0-1 | 0 | 0-1 | Session-Timeout |
| 0 | 0-1 | 0 | 0-1 | Idle-Timeout |
| 0 | 0-1 | 0 | 0 | Termination-Action |
| 0-1 | 0 | 0 | 0 | Called-Station-Id |
| 0-1 | 0 | 0 | 0 | Calling-Station-Id |
| 0-1 | 0 | 0 | 0 | NAS-Identifier |
| 0+ | 0+ | 0+ | 0+ | Proxy-State |
| 0-1 | 0 | 0 | 0 | CHAP-Challenge |
| 0-1 | 0 | 0 | 0 | NAS-Port-Type |
| 0-1 | 0-1 | 0 | 0 | Port-Limit |
Access-Request должен содержать либо User-Password, либо CHAP-Password, либо State. Access-Request не может одновременно содержать как User-Password, так и CHAP-Password.
Access-Request должен содержать либо NAS-IP-Address, либо NAS-Identifier, либо и то, и другое.
Обсуждение безопасности
Каждый RADIUS-сервер имеет базу данных, в которой хранятся имена пользователей и аутентификационная информация ("секреты"). Не предпо-лагается, что отдельный пользователь может быть аутентифицирован не-сколькими способами. Аутентификация несколькими способами может быть уязвима, если атакующий попытается заставить использовать наиболее слабый метод.
К паролям и другим секретам доступ должен быть максимально ограничен.
Аккаунтинг RADIUS
Рассмотрим использование протокола RADIUS для доставки информации об учетных записях от NAS к серверу учетных записей RADIUS.
Последовательность пакетов
Если клиент сконфигурирован для использования RADIUS-аккаунтинга, то перед началом получения сервиса создается пакет Accounting Start, описывающий тип сервиса и пользователя, которому необходим этот сервис. Эта информация посылается к серверу аккаунтинга RADIUS.
Затем этот сервер присылает подтверждение, что пакет был получен.
После завершения получения сервиса NAS создает пакет Accounting Stop, в котором описан тип полученного сервиса и возможно различная статистическая информация, такая как затраченное время, количество входящего и исходящего трафика. Этот пакет посылается к серверу аккаунтинга RADIUS, который присылает подтверждение, что пакет был получен.
Клиент посылает пакеты Accounting-Request до тех пор, пока не получит тем или иным способом подтверждения. После того, как клиент не получил подтверждения в течение определенного времени, он может перенаправить запрос альтернативному серверу.
Сервер аккаунтинга RADIUS может делать запросы другим серверам, в этом случае он действует как клиент.
Использование прокси-сервера
Аккаунтинг прокси функционирует аналогично аутентификационному прокси.
- NAS посылает запрос на аккаунтинг к перенаправляющему серверу.
- Перенаправляющий сервер записывает в лог запрос на аккаунтинг (если требуется), добавляет свой атрибут Proxy-State (если требуется) после всех остальных атрибутов Proxy-State, изменяет Аутентификатор запроса и перенаправляет запрос удаленному серверу.
- Удаленный сервер записывает в лог (если требуется) все атрибуты Proxy-State, а также помещает их в пакет ответа и посылает перенаправляющему серверу.
- Перенаправляющий сервер вырезает последний атрибут (если он был добавлен на шаге 2), изменяет аутентификатор запроса и посылает ответ аккаунтинга к NAS.
Перенаправляющий сервер не должен модифицировать существующие в пакете атрибуты Proxy-State и Class.
Формат пакета аккаунтинга
Формат пакета аккаунтинга аналогичен формату пакета аутентификации, значения полей другие. В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1813.
При создании ответа порты отправителя и получателя меняются местами.
Поле Code
Поле Code состоит из одного октета и определяет тип RADIUS-пакета. Если получен пакет с недействительным значением поля Code, то пакет молча (без отправления ответа) отбрасывается. В поле Code могут быть указаны следующие значения:
4 Accounting-Request 5 Accounting-Response
Поле Identifier
Поле Identifier состоит из одного октета и предназначено для того, чтобы можно было сопоставить пары запросов и ответов. RADIUS-сервер может определить дубликат запроса, если запрос имеет IP-адрес источника, UDP-порт источника и Identifier, что и у уже полученного запроса.
Поле Length
Поле Length состоит из двух октетов. Оно содержит длину пакета, включая поля Code, Identifier, Length, Authenticator и Attribute.
Поле Authenticator
Поле Authenticator состоит из 16 октетов. Это значение используется для определения повторов ответов от RADIUS-сервера и используется в алгоритме скрытия пароля.
Аутентификатор запроса
В пакетах Accounting-Request значение Authenticator является 16-октетным значением MD5, называемым аутентификатором запроса.
NAS и аккаунтинг сервер RADIUS разделяют секрет. Поле аутентификатора запроса содержит результат вычисления MD5 над следующими значениями: Code + Identifier + Length + 16 октетов нулей + атрибуты запроса + разделяемый секрет.
Заметим, что аутентификатор запроса в Accounting-Request может вычисляться другим способом, чем аутентификатор запроса в Access-Request, потому что в Accounting-Request нет атрибута User-Password.
Аутентификатор ответа
Поле Authenticator в пакете Accounting-Response называется аутентификатором ответа и содержит результат вычисления MD5 над следующими значениями:
Code + Identifier + Length + аутентификатор запроса из пакета Accounting-Request + атрибуты ответа, если есть, + разделяемый секрет. Полученные 16 октетов записываются в поле Authenticator пакета Accounting-Response.
Поле Attributes
В поле Attributes могут быть включена атрибуты разных типов. Атрибуты некоторых типов могут быть включены несколько раз. В этом случае порядок атрибутов одного и того же типа фиксирован.