Московский государственный университет имени М.В.Ломоносова
Опубликован: 28.11.2014 | Доступ: свободный | Студентов: 1154 / 83 | Длительность: 23:26:00
ISBN: 978-5-9556-0163-2
Лекция 12:

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

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

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

Таблица 12.1.
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.

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

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

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

Пример первого пакета Accounting Start RADIUS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роман Храменков
Роман Храменков
Россия, г. Барнаул