Аутентификация и хранение учетных записей

Атрибуты для поддержки 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-х октетным целым, которое интерпретируется как строка битов.

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

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.

Последовательность пакетов

Рис. 12.19. Последовательность пакетов при выполнении аккаунтинга

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

Рис. 12.20. Пример первого пакета Accounting Start RADIUS

Затем этот сервер присылает подтверждение, что пакет был получен.

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

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

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

Использование прокси-сервера

Аккаунтинг прокси функционирует аналогично аутентификационному прокси.

Рис. 12.21. Топология сети при использовании прокси-сервера RADIUS

• NAS посылает запрос на аккаунтинг к перенаправляющему серверу.
• Перенаправляющий сервер записывает в лог запрос на аккаунтинг (если требуется), добавляет свой атрибут Proxy-State (если требуется) после всех остальных атрибутов Proxy-State, изменяет Аутентификатор запроса и перенаправляет запрос удаленному серверу.
• Удаленный сервер записывает в лог (если требуется) все атрибуты Proxy-State, а также помещает их в пакет ответа и посылает перенаправляющему серверу.
• Перенаправляющий сервер вырезает последний атрибут (если он был добавлен на шаге 2), изменяет аутентификатор запроса и посылает ответ аккаунтинга к NAS.

Перенаправляющий сервер не должен модифицировать существующие в пакете атрибуты Proxy-State и Class.

Формат пакета аккаунтинга

Формат пакета аккаунтинга аналогичен формату пакета аутентификации, значения полей другие. В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1813.

При создании ответа порты отправителя и получателя меняются местами.

Рис. 12.22. Формат RADIUS-пакета аккаунтинга

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