Идентификация – сервис, с помощью которого определяются уникальные свойства пользователей, с помощью которых можно отличать их друг от друга, и способы, с помощью которых, пользователи указывают свои идентификации информационной системе. Идентификация тесно связана с аутентификацией.
Аутентификация – сервис, с помощью которого доказывается, что участники являются требуемыми, т.е. обеспечивается доказательство идентификации. Это может достигаться с помощью паролей, смарт-карт, биометрических токенов и т.п. В случае передачи единственного сообщения аутентификация должна гарантировать, что получателем сообщения является тот, кто нужно, и сообщение получено из заявленного источника. В случае установления соединения имеют место два аспекта. Во-первых, при инициализации соединения сервис должен гарантировать, что оба участника являются требуемыми. Во-вторых, сервис должен гарантировать, что на соединение не воздействуют таким образом, что третья сторона сможет маскироваться под одну из легальных сторон уже после установления соединения.
Как правило, при большом числе пользователей идентификационные и аутентификационные данные хранятся на отдельном сервере. Это позволяет освободить межсетевой экран от необходимости хранить большие объемы идентификационных и аутентификационных данных. Доступ к серверу, на котором хранятся идентификационные и аутентификационные данные, как правило, осуществляется либо по протоколу RADIUS, либо по прото-колу LDAP (рис. 12.1).
Будем предполагать, что сеть имеет следующую топологию.
(рис 12.1) Топология сети при использовании сервера идентификации
Конечная цель – предоставить аутентифицированный и авторизованный доступ пользователю с удаленного хоста к серверу, расположенному в LAN или DMZ. Между МЭ1 и МЭ2 выполняется один из протоколов VPN. Учетные записи пользователей хранятся на сервере RADIUS. Идентифика-ционная и аутентификационная информация указывается на удаленной точке туннеля. Запрос аутентификации и используемый сервер, на котором хранятся идентификационные и аутентификационные данные, указываются на локальной стороне туннеля. При успешной аутентификации пользователю с удаленного хоста предоставляется доступ к серверу, расположенному в LAN или DMZ.
Взаимодействующими сторонами в протоколе RADIUS (Remote Au-thentication Dial In User Service) являются:
Сервер RADIUS– сервер, выполняющий аутентификацию, авторизацию и хранение учетных записей (аккаунтинг). В английском варианте Authentication, Authorization и Accounting – ААА. RADIUS предоставляет сервисы ААА для NAS.
Сервер Сетевого Доступа (Network Access Server – NAS)– устройство, которое предоставляет удаленным пользователям доступ в сеть и является клиентом для сервера RADIUS.
Аутентификация, авторизация и аккаунтинг выполняются для удаленной стороны туннеля, в нашем случае для учетной записи, указанной в конфигурации МЭ1.
Основные принципы функционирования RADIUS:
Сервер RADIUS получает запрос от NAS, аутентифицирует пользователя и затем возвращает NAS всю необходимую для предоставления сервиса информацию.
Сервер RADIUS может функционировать как прокси-клиент для других серверов RADIUS или аутентификационных серверов других типов.
(рис 12.2) Задание секрета между NAS и сервером RADIUS на стороне NAS
(рис 12.3) Задание секрета между NAS и сервером RADIUS на стороне сервера RADIUS
(рис 12.4) Защищенность пользовательского пароля при пересылке между NAS и сервером RADIUS
(рис 12.5) Параметры РРР-аутентификации на стороне NAS
(рис 12.6) Параметры РРР-аутентификации на стороне сервера RADIUS
В протоколе RADIUS все данные передаются в элементах, которые называются атрибутами.
Атрибуты RADIUS используются для передачи:
Атрибут может быть определен в спецификации протокола RADIUS, и в этом случае говорят, что он является стандартным и принадлежит стандартному пространству имен, либо может быть определен производителем, в этом случае говорят, что он принадлежит пространству имен производи-теля и являются Vendor-Specific Attributes (VSA).
Такие атрибуты определяются производителем и указываются в поле String.
Значение каждого атрибута принадлежит определенному типу данных. В отличие от протокола SNMP в RADIUS нет формального языка определения данных.
Типы данных могут быть "базовые" и "комплексные". Базовые типы данных используют один из существующих типов данных RADIUS, которые могут содержаться в стандартном атрибуте или VSA-атрибуте.
(рис 12.7) Пример атрибутов RADIUS
В RADIUS определены следующие базовые типы данных:
Следующие типы данных определены как "комплексные":
Пространство имен производителя обозначается как VSA. При этом Vendor-Id определяет конкретного производителя, а поле String определяет уникальный тип атрибута для данного производителя.
Функционирование RADIUS основано на следующих принципах:
Access-Reject и Disconnect-Request.Хотя производители серверов RADIUS и могут поддерживать состояние, в самом протоколе RADIUS понятие состояния не определено. Однако определенная информация может передаваться от одной транзакции к другой с помощью атрибута State.
В спецификации RADIUS определены атрибуты, содержащие конфиденциальную информацию (например, пароли). Такие атрибуты не пересылаются в запросе и не возвращаются в ответе в открытом виде. Кроме того, аутентификационный механизм связывает вместе последовательность пакетов Access-Request / Access-Challenge в одной аутентификационной сессии с помощью атрибута State.
Протокол RADIUS является протоколом типа запрос-ответ, выполняющимся между клиентом и сервером RADIUS. Один пакет запроса требует в ответ по крайней мере один пакет, который посылается на IP-адрес и порт клиента.
Длина пакета RADIUS не может быть больше 4096 байтов (октетов).
Даже если длина пакета меньше, чем 4096 байтов, она может быть больше, чем Path MTU (PMTU). Любой пакет, длина которого больше, чем PMTU, будет фрагментирован, что может привести к сложности прохожде-ния межсетевых экранов, которые отбрасывают фрагментированные пакеты. Если приходится использовать фрагментированные пакеты, то необхо-димо тщательное тестирование корректного прохождения всех межсетевых экранов и устройств, которые могут отбрасывать фрагментированные пакеты. Некоторые устройства не могут передавать фрагментированные UDP-пакеты, затрудняя развертывание RADIUS в сети с такими устройствами. Рекомендуется следить за тем, чтобы сообщения RADIUS были как можно более маленькими.
Если необходимо передавать пакеты большей длины, чем 4096 байтов, то используется один из следующих подходов:
Access-Request / Access-Response пакетов. 
(рис 12.8) Последовательность пакетов при выполнении аутентификации
Пользователь предоставляет NAS аутентификационную информацию, после этого NAS использует протокол RADIUS для аутентификации данного пользователя. Эта аутентификационная информация может предоставляться в виде настраиваемого приглашения для входа, когда от пользователя требуется ввести имя и пароль. Либо может использовать такой протокол, как РРР, в котором существуют аутентификационные пакеты для пересылки данной информации.
(рис 12.9) Задание аутентификационных данных пользователя на противоположной NAS стороне туннеля
После того, как NAS получил эту информацию, он может выполнить аутентификацию пользователя на сервере RADIUS. Для того чтобы сделать это, NAS создает запрос Access-Request, содержащий в качестве атрибутов имя пользователя, пароль, идентификатор и тип порта NAS, к которому пользователь хочет получить доступ. Если присутствует пароль, то используется метод его скрытия, основанный на алгоритме хэширования MD5.
(рис 12.10) Пересылка аутентификационных данных пользователя по туннелю между NAS и противоположной стороной туннеля
Атрибуты RADIUS используются для передачи аутентификационной и авторизационной информации и деталей конфигурирования.
Некоторые атрибуты могут быть включены в сообщение несколько раз. Результат такого включения зависит от атрибута.
Если есть несколько атрибутов одного и того же типа, то прокси-серверы не должны изменять их упорядоченность. Порядок атрибутов разных типов прокси-серверами может быть изменен. Поведение RADIUS-сервера и клиента никак не зависит от упорядоченности атрибутов разных типов. Не требуется, чтобы атрибуты одного и того же типа были расположены рядом друг с другом.
(рис 12.11) Пересылка аутентификационных данных между NAS и сервером RADIUS
Access-Request передается по сети серверу RADIUS. Если в течение определенного времени ответ не получен, то запрос повторяется. Клиент может также направить запросы к альтернативному серверу или нескольким серверам в случае, если первичный сервер выключен или не доступен. Альтернативный сервер может использоваться либо после определенного числа неудачных попыток обращения к первичному серверу, либо по круговому алгоритму.
После получения запроса сервер RADIUS выполняет аутентификацию NAS. Запрос от NAS, с которым сервер RADIUS не имеет разделяемого секрета, молча, т.е. без уведомления противоположной стороны, отбрасывается.
Если NAS аутентифицирован, RADIUS-сервер ищет в базе данных пользователей имя, указанное в запросе. Запись пользователя в базе данных содержит список требований, которые должны быть выполнены, чтобы пользователю можно было разрешить доступ. Это всегда включает проверку пароля, но можно также определить дополнительные параметры, которые проверяются перед тем, как пользователю будет разрешен доступ.
(рис 12.12) Указание параметров аутентификации на стороне сервера RADIUS
Сервер RADIUS может сделать запросы к другим серверам, чтобы обработать данный запрос. В этом случае он является прокси и действует как клиент по отношению к другому серверу RADIUS.
Если в запросе Access-Request есть какие-либо атрибуты Proxy-State, они должны быть скопированы без каких-либо изменений и в том же порядке в пакет ответа. Остальные атрибуты могут быть расположены до, после и даже между Proxy-State атрибутами.
Если какое-либо из условий не выполнено, сервер RADIUS посылает Access-Reject ответ, который говорит о том, что аутентификация не выполнена и запрос пользователя на вход отвергается. Сервер может также включить в Access-Reject текстовое сообщение, которое будет показано пользователю. Никаких других атрибутов, за исключением Proxy-State, в Access-Reject не передается.
(рис 12.13) Пример сообщения Access-Reject при отсутствии у пользователя или NAS требуемых аутентификационных данных
Если все условия выполнены, и RADIUS-серверу требуется получить дополнительные ответы от пользователя, RADIUS-сервер посылает Access-Challenge ответ. Он может включить текстовое сообщение, которое будет показано пользователю, и может включать атрибут State.
Если NAS получил Access-Challenge и поддерживает Запрос / Ответ, он может показать текстовое сообщение, если оно есть, и затем выдать приглашение пользователю для ввода ответа. Затем клиент передает свой исходный Access-Request с новым ID запроса и с атрибутом User-Password и атрибутом State из Access-Challenge, если они были там указаны.
В ответе не может быть больше одного экземпляра атрибута State. На это сообщение сервер может ответить новым Access-Request, указав в нем либо Access-Request, либо Access-Reject, либо другой Access-Challenge.
Если все условия выполнены, в ответ Access-Request помещается список конфигурационных значений. Эти значения включают тип сервиса (например, SLIP, PPP, Login User) и все необходимые значения для получения требуемого сервиса. Для SLIP и РРР это может включать такие значения, как IP-адрес, маска подсети, MTU, алгоритм сжатия и идентификаторы требуемых фильтров пакетов. Могут быть также указаны требуемый протокол и хост.
(рис 12.14) Пример сообщения Access-Request при выполнении аутентификации
При аутентификации Вызов/Ответ (Challenge/Response) пользователь получает заранее неизвестное число запросов, на которые он должен дать ответ. Для создания корректного ответа пользователь должен иметь либо специальные устройства, такие как смарт-карты, либо ПО, которое создает ответ. Если у пользователя нет соответствующего устройства или в ПО не установлено корректное значение секрета, пользователь считается неавторизованным.
Пакет Access-Challenge обычно содержит Reply-Message, которое показывается пользователю, например, числовое значение, которое никогда не повторяется.
Затем пользователь вводит это случайное число в смарт-карту или программу, которая вычисляет ответ. Пользователь вводит этот ответ, и NAS пересылает его на сервер RADIUS во втором Access-Request. Если ответ правильный, сервер RADIUS возвращает Access-Request, в противном случае возвращает Access-Reject.
Пример:
(рис 12.15) Пример последовательности пакетов при Challenge/Response
NAS посылает пакет Access-Request к серверу RADIUS с атрибутами NAS-Identifier, NAS-Port, User-Name, User-Password (который может быть фиксированной строкой типа "challenge" и игнорироваться). Сервер посылает обратно пакет Access-Challenge с атрибутами State, Reply-Message и строкой "Challenge 12345678, введите ваш ответ", которую NAS показывает пользователю. NAS выдает приглашение пользователю для ответа и посылает полученный ответ в новом пакете Access-Request к серверу (с новым ID), содержащий атрибуты NAS-Identifier, NAS-Port, User-Name, User-Password. В этом случае ответ, который только что ввел пользователь, защищен. Этот ответ содержит тот же самый атрибут State, который был указан в Access-Challenge. После этого сервер присылает обратно либо пакет Access-Request, либо пакет Access-Reject.
При использовании РАР NAS получает РАР ID и пароль и посылает их в пакете Access-Request в качестве атрибутов User-Name и User-Password. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol=PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
При использовании СНАР NAS создает случайный вызов (желательно 16 октетов) и посылает его пользователю, который возвращает СНАР-ответ вместе с атрибутами CHAP ID и СНАР Username. Затем NAS посылает пакет Access-Request к серверу RADIUS со значением СНАР Username в атрибуте User-Name и со значением СНАР ID и СНАР-ответом в атрибуте CHAP-Password. Случайный вызов либо может быть включен в атрибут CHAP-Challenge, либо, если его длина больше 16 октетов, он может быть помещен в поле Request Authenticator в пакете Access-Request. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
Если сервер RADIUS не может выполнить необходимую проверку, он возвращает Access-Reject. Например, при использовании СНАР требуется, чтобы пароль пользователя был доступен серверу в незашифрованном виде для того, чтобы он мог хэшировать его вместе с вызовом и сравнить с тем, что получил в качестве СНАР-ответа. Если пароль не доступен серверу RADIUS в незашифрованном виде, то он посылает клиенту Access-Reject.
(рис 12.16) Топология сети при использовании прокси-сервера RADIUS
При использовании RADIUS-прокси один RADIUS-сервер получает запрос на аутентификацию (или аккаунтинг) от RADIUS-клиента (такого как NAS), перенаправляет запрос к удаленному RADIUS-серверу, получает ответ от него и посылает этот ответ клиенту, возможно с изменениями, от-ражающими локальную административную политику. RADIUS-прокси чаще всего используется при роуминге. В этом случае для предоставления доступа несколько административных единиц должны аутентифицировать пользователей друг друга.
NAS посылает свой запрос на доступ к перенаправляющему серверу, который перенаправляет этот запрос на удаленный сервер. Удаленный сервер присылает ответ (Access-Request, Access-Reject или Access-Challenge) обратно перенаправляющему серверу, который посылает его к NAS. Атрибут User-Name может содержать идентификатор сетевого доступа (например, userID, переданный клиентом при РРР-аутентификации). Выбор сервера, которому следует перенаправить запрос, основывается на аутентификационной области (realm). Аутентификационная область может быть частью области идентификатора сетевого доступа ("области имени"). Выбор сервера, которому пересылается запрос, может быть основан и на каком-то другом критерии.
RADIUS-сервер может функционировать и как перенаправляющий сервер для одних областей, и как удаленный сервер для других областей. Один перенаправляющий сервер может перенаправлять запросы любому числу удаленных серверов. Один удаленный сервер может получать пере-направления от любого числа серверов и может выполнять аутентифика-цию для любого числа областей. Один перенаправляющий сервер может выполнять перенаправление другому перенаправляющему серверу, создавая тем самым цепочку прокси. При этом следует стараться избегать создания циклов.
Следующий сценарий иллюстрирует взаимодействие между RADIUS-прокси, NAS и удаленным RADIUS-сервером:
Access-Request, Access-Reject или Access-Challenge обратно перенаправляющему серверу. В нашем случае предположим, что посылается Access-Request.Access-Request к NAS.Перенаправляющий сервер должен рассматривать все атрибуты Proxy-State в пакете как неструктурированные данные. Его действия не должны зависеть от содержимого Proxy-State атрибутов, которые были добавлены предыдущими серверами.
Если в запросе, полученном от клиента, существуют какие-либо атрибуты Proxy-State , перенаправляющий сервер должен включить эти атрибуты Proxy-State в ответ клиенту. Перенаправляющий сервер может как включать, так и не включать Proxy-State атрибуты в запрос доступа при перенаправлении запроса. Если перенаправляющий сервер не включил Proxy-State атрибуты в перенаправленный запрос доступа, он должен присоединить их к ответу перед тем, как посылать ответ обратно клиенту.
Рассмотрим каждый шаг более детально.
User-Password, если он есть, используя общий секрет с NAS. Если в пакете присутствует атрибут CHAP-Password и нет атрибута CHAP-Challenge, перенаправляющий сервер не должен изменять атрибут Request-Authenticator или должен копировать его в атрибут CHAP-Challenge. Перенаправляющий сервер может добавить в пакет не более одного атрибута Proxy-State. Если он добавляет атрибут Proxy-State, то он должен быть добавлен после всех остальных атрибутов Proxy-State, которые уже есть в пакете. Перенаправляющий сервер не изменяет последовательность атрибутов одного и того же типа, включая атрибуты Proxy-State.User-Password, если он присутствует. Для защиты от replay-атак используется секрет, который он разделяет с удаленным сервером. Перенаправляющий сервер может добавить значение Identifier, после чего перенаправляет запрос на доступ к удаленному серверу.User-Password, CHAP-Password или какой-либо другой метод, и возвращает обрат-но перенаправляющему серверу ответ Access-Request, Access-Reject или Access-Challenge. Предположим, что посылается Access-Request. Удаленный сервер должен копировать, не модифицируя, все атрибуты Proxy-State (и только их) из запроса на доступ в пакет ответа.Proxy-State (если он был присоединен), обеспечивает целостность аутентификатора ответа, используя секрет, который он разделяет с NAS, и посылает Access-Request к NAS.Перенаправляющему серверу может понадобиться изменить атрибуты для реализации локальной политики. Но при этом перенаправляющий сервер не должен изменять имеющиеся в пакете атрибуты Proxy-State, State или Class.
Производители перенаправляющих серверов определяют значения, которые они готовы принимать в качестве значения атрибута Service-Type. Это может повлиять на передачу значения Service-Type от NAS в проксируемом пакете Access-Request. Могут также существовать механизмы, которые блокируют определенные типы сервисов.
Часто возникает вопрос, почему в качестве транспорта сообщений RADIUS используется UDP, а не ТСР. UDP был выбран исключительно по техническим причинам.
Существуют определенные проблемы, в результате которых UDP становится более предпочтительным транспортным протоколом. RADIUS является протоколом, основанным на транзакциях, который обладает следующими характеристиками:
С одной стороны RADIUS не требует сверх точного определения потерянных данных. Пользователь может подождать несколько секунд для завершения аутентификации, поэтому по-стоянные повторные передачи, которые имеют место в ТСР, не требуются.
С другой стороны пользователя нельзя заставлять ждать завершения аутентификации несколько минут. Следовательно, надежная доставка ТСР-данных в течение двух минут не нужна. Быстрее использовать альтернативный сервер, который может предоставить доступ.
И клиент, и сервер могут завершить соединение, любая из сторон может выполнить перезапуск всей системы. При этом обычно не возникает проблем, связанных с необходимостью определения потерянного соединения, которые имеют место в протоколе ТСР. Код может быть просто написан с учетом обработки аномальных событий. В самом протоколе UDP полностью отсутствует какая-либо специальная обработка при потере соединения. И клиент, и сервер могут использовать данное UDP-соединение только один раз.
В ранних реализациях RADIUS сервер состоял из единственной нити. Это означало, что одновременно мог получаться, обрабатываться и возвращаться единственный запрос. Это за-медляло обработку в тех случаях, когда используемым механизмам безопасности требовалось много времени. Также могла переполниться очередь запросов на сервер, если сотням людей ежеминутно требовалась аутентификация. Очевидным решением этой проблемы является реализация сервера с использованием нескольких нитей. Сделать это значительно проще, используя UDP. Каждый процесс обрабатывал отдельный запрос и отвечал клиенту NAS простым UDP-пакетом.
Это не является панацеей от всех бед. При использовании UDP на прикладном уровне требуется помнить о проблемах, которые автоматически решаются в ТСР, например управлением таймерами повторных передач.
Если RADIUS-сервер и альтернативный RADIUS-сервер разделяют общий секрет, то можно переслать пакет альтернативному RADIUS-серверу с тем же самым ID и аутентификатором запроса, так как содержимое атрибутов не изменилось. Если необходимо использовать новый аутентификатор запроса при отправке запроса альтернативному серверу, это можно сделать.
Если сервер изменил содержимое атрибута User-Password (или любого другого атрибута), то он должен создать новый аутентификатор запроса и, следовательно, новый ID.
Если NAS повторяет запрос к тому же самому серверу, и атрибуты не изменились, следует использовать тот же самый аутентификатор запроса, ID и порт источника. Если какой-либо атрибут изменился, необходимо использовать новые аутентификатор запроса и ID.
NAS может использовать один и тот же ID для всех серверов или может для каждого сервера использовать отдельный ID.
Некоторые производителя посылают тестовые запросы для проверки жизнеспособности сервера. Это не самая лучшая практика, так как увели-чивается трафик и уменьшается масштабируемость, без предоставления при этом никакой дополнительной информации. Так как запрос RADIUS содержится в единственной дейтаграмме, можно вместо этого просто выполнить команду ping.
Для мониторинга RADIUS-сервера следует использовать протокол SNMP.
В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1812.
При создании ответа порты отправителя и получателя меняются местами.
(рис 12.17) Формат RADIUS-пакета аутентификации
Поле Code
Поле Code состоит из одного октета и определяет тип RADIUS-пакета. Если получен пакет с недействительным значением поля Code, то пакет молча (без ответа) отбрасывается. В поле Code могут быть указаны следующие значения:
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server 13 Status-Client
Поле Identifier
Поле Identifier состоит из одного октета и предназначено для сопоставления пар запросов и ответов. RADIUS-сервер может определить дубликат запроса, если запрос имеет IP-адрес источника, UDP-порт источника и значения поля Identifier, что и у уже полученного запроса.
Поле Length
Поле Length состоит из двух октетов. Оно содержит длину пакета, состоящего из полей Code, Identifier, Length, Authenticator и Attribute.
Поле Authenticator
Поле Authenticator состоит из 16 октетов. Это значение используется для определения повторных ответов от RADIUS-сервера и используется в алгоритме скрытия пароля.
Аутентификатор запроса
В пакете Access-Request значение Authenticator состоит из 16-октетного случайного числа, называемого аутентификатор запроса. Значение должно быть случайным. Хотя протокол RADIUS и не может защитить от встраивания поддельной информации в аутентифицированную сессию с помощью активной атаки man-in-the-middle, создание случайного значения в качестве аутентификатора защищает от большого числа активных атак, связанных с аутентификацией.
NAS и RADIUS-сервер разделяют общий секрет. Выполняется конкатенация этого секрета и аутентификатора запроса, результат подается на вход хэш-функции MD5, которая создает 16-октетное значение дайджеста. Затем выполняется операция XOR полученного значения и пароля, введен-ного пользователем, и результат помещается в атрибут User-Password в пакете Access-Request.
Аутентификатор ответа
Значение поля Authenticator в пакетах Access-Request, Access-Reject и Access-Challenge называется аутентификатором ответа и содержит хэш-значение MD5, вычисленное для RADIUS-пакета, начиная с поля Code и включая поля Identifier, Length, Request Authenticator из пакета Access-Request, Attributes из ответа, за которыми следует разделяемый секрет.
MD5 (Code+ID+Length+RequestAuth+Attributes+Secret)
где "+" означает конкатенацию.
Вопросы администрирования
Секрет (пароль, разделяемый клиентом и RADIUS-сервером) должен быть такой длины, чтобы его трудно было перебрать. Считается, что его длина должна быть по крайней мере 16 октетов.
Перенаправляющий прокси может изменить содержимое пакета, а именно он может добавить атрибут Proxy-State. Когда прокси возвращает ответ, он должен удалить свой атрибут Proxy-State, если тот был добавлен. Proxy-State всегда добавляется после других атрибутов Proxy-State, но никаких других предположений относительно его расположения в списке атрибутов не делается. Так как ответы Access-Request и Access-Reject аутентифицированы как часть содержимого всего пакета, удаление атрибута Proxy-State делает недействительным аутентификатор пакета, поэтому прокси заново вычисляет аутентификатор.
Сообщение Access-Request
Пакеты Access-Request посылаются RADIUS-серверу и содержат информацию, используемую для определения разрешен ли пользователю доступ к данному NAS и какие сервисы доступны для данного пользователя.
Пакет Access-Request должен содержать атрибут User-Name. Он также должен содержать атрибуты NAS-IP-Address или NAS-Identifier.
Пакет Access-Request должен содержать либо атрибут User-Password, либо атрибут CHAP-Password, либо атрибут State. Пакет Access-Request не должен содержать одновременно и User-Password, и CHAP-Password. Возможно также добавление других типов аутентификационной информации и атрибутов, которые будут использоваться в пакете Access-Request вместо атрибутов User-Password или CHAP-Password.
Пакет Access-Request может содержать атрибут NAS-Port или NAS-Port-Type, а также дополнительные атрибуты, но при этом не требуется, чтобы сервер их как-то учитывал при создании ответа.
Если присутствует атрибут User-Password, он должен быть скрыт с использованием хэш-функции MD5.
Сообщение Access-Request
Пакеты Access-Request посылаются RADIUS-сервером и содержат информацию, необходимую для предоставления сервиса пользователю. Если все значения атрибута Attribute в Access-Request корректные, то RADIUS-сервер должен передать пакет с полем Code, установленным в 2 (Access-Request).
В пакете Access-Request поле Identifier должно соответствовать отправленному в Access-Request.
Сообщение Access-Reject
Если какое-либо значение Attributes не является допустимым, то RADIUS-сервер передает ответ с полем Code, установленным в 3 (Access-Reject). Он может включить один или несколько атрибутов Reply-Massage с текстовым сообщением, которое NAS может показать пользователю.
Сообщение Access-Challenge
Если RADIUS-сервер считает, что пользователю необходимо послать вызов, требующий ответа, то он отвечает пакетом с полем Code, установленным в 11 (Access-Challenge).
Поле Attribute может содержать один или несколько атрибутов Reply-Message или единственный атрибут State, либо не содержать ничего из перечисленного. Могут также быть включены следующие атрибуты: Vendor-Specific, Idle-Timeout, Session-Timeout и Proxy-State. Никакие другие атрибуты не должны включаться в Access-Challenge.
В полученном пакете Access-Challenge поле Identifier должно соответствовать тому, которое было указано в отправленном NAS Access-Request.
Если NAS не поддерживает обмен сообщениями Вызов/Ответ, он должен считать, что Access-Challenge соответствует Access-Reject.
Если NAS поддерживает обмен сообщениями Вызов/Ответ, то получение корректного ответа Access-Challenge означает, что должен быть послан новый запрос Access-Request. NAS может показать пользователю текстовое сообщение и выдать приглашение для ввода ответа. Затем он посылает исходный Access-Request с новым ID запроса и аутентификатором запроса, с атрибутом User-Password, в котором содержится ответ пользователя (в скрытом виде), а также в него добавляется атрибут State из Access-Challenge, если он там был. В Access-Request может присутствовать не более одного атрибута State.
NAS, поддерживающий РАР, может перенаправить Reply-Message клиенту и получить РАР-ответ, который затем он может использовать в качестве ответа пользователя. Если NAS это не поддерживает, он должен трактовать Access-Challenge как Access-Reject.
Атрибуты имеют следующий формат:
(рис 12.18) Формат атрибутов RADIUS
Поле Type
Поле Type имеет длину один октет. Возможные типы стандартизованы и перечислены в соответствующих RFC. Как RADIUS-сервер, так и клиент могут игнорировать атрибуты, тип которых они не знают.
Основные типы атрибутов следующие:
1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 11 12 Framed-MTU 13 Framed-Compression 14 Logon-IP-Host 15 Login-Service 16 Login-TCP-Port 17 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 -59 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port
Атрибут User-Name
Атрибут содержит имя аутентифицируемого пользователя. Он обязательно указывается в пакетах Access-Request.
Он может быть послан в пакете Access-Request, в этом случае клиент должен использовать это имя во всех пакетах Accounting-Request данной сессии. Если в Access-Request включен ServiceType=Rlogin и атрибут User-Name, NAS может использовать возвращаемое значение User-Name при выполнении сервиса Rlogin в UNIX-системах. Значением атрибута может быть текст, идентификатор сетевого доступа или DN прото-кола LDAP.
Атрибут User-Password
В данном атрибуте указывается пароль аутентифицируемого пользователя или введенная пользователем информация при получении пакета Access-Challenge. Атрибут используется только в пакетах Access-Request.
Пароль передается в скрытом виде. Первым делом к паролю добавляются символы заполнения, чтобы длина пароля стала кратной 16 октетам. Затем используется хэш-функция MD5, на вход которой подаются разделяемый секрет и аутентификатор запроса. Затем выполняется операция XOR этого значения с первыми 16 октетами пароля, полученное значение помещается в первые 16 октет поля String атрибута User-Password.
Если пароль длиннее 16 символов, второй раз используется хэш-функция MD5, на вход которой подается разделяемый секрет, за которым следует результат первого XOR. После этого выполняется XOR результата второго использования MD5 и вторых 16 октетов пароля. При необходимости данная операция повторяется нужное число раз.
Обозначим разделяемый секрет – S, псевдослучайный 128-битный аутентификатор запроса – RA. 16-октетные части пароля – р1, р2 и т.д.
b1 = MD5 (S + RA) c(1) = p1 xor b1 b2 = MD5 (S + c(1)) c(2) = p2 xor b2 String содержит с(1) + с(2) + ….., где + обозначает конкатенацию.
Атрибут СНАР-Password
В данном атрибуте указывается ответ на запрос, предоставленный протоколом СНАР, в ответ на Вызов (Challenge). Атрибут используется только в пакетах Access-Request.
Значение Вызова СНАР берется из атрибута CHAP-Challenge, если он присутствует в пакете, в противном случае используется поле Аутентификатора запроса.
Атрибут NAS-IP-Address
Данный атрибут определяет IP-адрес NAS, который запросил аутентификацию пользователя. Этот IP-адрес должен быть уникальным у данного RADIUS-сервера. NAS-IP-Address используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать либо NAS-IP-Address, либо NAS-Identifier.
Заметим, что NAS-IP-Address не должен использоваться для выбора разделяемого секрета, который используется для аутентификации запроса. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.
Атрибут NAS-Port
Атрибут определяет номер физического порта NAS, который аутентифицирует пользователя. Атрибут используется только в пакетах Access-Request. Заметим, что это порт физического соединения NAS, а не ТСР или UDP номер порта. В пакете Access-Request должен присутствовать либо NAS-Port, либо NAS-Port-Type.
Атрибут Service-Type
Данный атрибут определяет тип сервиса, который запросил пользователь, или тип сервиса, который будет предоставлен. Он может использоваться в пакетах Access-Request и Access-Accept. Не требуется, чтобы NAS мог реализовывать все типы сервисов, неизвестные или не поддерживаемые сервисы игнорируются и должны рассматриваться как Access-Reject.
Следующие типы сервисов могут использоваться в Access-Request. При использовании в Access-Request они могут рассматриваться как подсказка RADIUS-серверу какой тип сервиса требуется пользователю. Но при этом не требуется, чтобы сервер следовал этой подсказке.
| Login | Пользователь должен войти на хост. |
|---|---|
Framed | Для соединения с пользователем должен использоваться такой протокол, как РРР или SLIP. |
Callback Login | Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего пользователь должен быть снова подсоединен к хосту. |
Callback Framed | Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего должен начать выполняться такой протокол, как РРР или SLIP. |
Outbound | Пользователю должен быть предоставлен доступ к внешним устройствам. |
Administrative | Пользователю должен быть предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды. |
NAS prompt | Пользователю должно быть выдано приглашение для ввода непривилегированных команд NAS. |
Authenticate Only | Требуется только аутентификация, в Access-Request не должно возвращаться никакой авторизационной информации (обычно используется прокси-серверами, а не самим NAS). |
Callback NAS Prompt | Пользователь отсоединяется, осуществляется обратный вызов и пользователю выдается приглашение для выполнения непривилегированных команд NAS. |
Call Check | Используется NAS в пакете Access-Request для указания того, что вызов был получен, и что в ответ на вызов RADIUS-сервер должен послать сообщение Access-Accept или Access-Reject, обычно основываясь на атрибутах Called-Station-Id или Calling-Station-Id. Рекомендуется, чтобы Access-Request использовал Calling-Station-Id в качестве значения User-Name. |
Callback Administrative | Пользователь должен быть отсоединен, выполнен обратный вызов, затем предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды. |
Атрибут Framed-Protocol
Атрибут указывает внешний протокол, который используется для получения доступа. Может использоваться в пакетах Access-Request и Access-Accept.
Атрибут Framed-IP-Address
Данный атрибут определяет IP-адрес, который должен быть выдан пользователю. Атрибут может быть указан в пакетах Access-Accept. Он также может быть указан в пакете Access-Request в качестве предпочтительного IP-адреса, но сервер не обязан следовать этому указанию.
Атрибут Framed-IP-Netmask
Данный атрибут определяет IP-маску, которая будет сконфигурирована для пользователя при доступе в сеть. Атрибут может использоваться в пакетах Access-Accept. Он может также использоваться в пакете Access-Request для указания предпочтений NAS серверу, но сервер не обязан следовать этому.
Атрибут Framed-MTU
Данный атрибут определяет MTU, который будет сконфигурирован для пользователя, если об этом значении не ведутся переговоры каким-либо другим способом, например в РРР. Атрибут может использоваться в Access-Accept пакетах. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Framed-Compression
Данный атрибут определяет протокол сжатия. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Может быть послано несколько атрибутов, определяющих протокол сжатия. За использование корректного протокола сжатия отвечает NAS.
Атрибут Login-IP-Host
Данный атрибут определяет систему, к которой должен подсоединиться пользователь, если используется атрибут Login-Service. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Login-Service
Данный атрибут указывает сервис, который будет использоваться при соединении пользователя с хостом. Он может использоваться только в пакетах Acces-Accept.
Атрибут Login-TCP-Port
Данный атрибут определяет ТСР-порт, с которым будет устанавливать соединение пользователь, если присутствует атрибут Login-Service. Используется только в пакетах Access-Request.
Атрибут Reply-Message
Данный атрибут содержит текст, который будет показан пользователю. Может означать необходимость создания диалогового окна и определять приглашение пользователю перед следующей попыткой выполнения запроса на доступ Access-Request.
Если используется в пакете Access-Challenge, может содержать диалоговое сообщение, которое выдается пользователю для ввода ответа.
Если в сообщении содержится несколько Reply-Message, то они показываются в том же порядке, в каком расположены в пакете.
Атрибут Callback-Number
Атрибут определяет строку, которая будет использоваться при обратном вызове. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Callback-Id
Данный атрибут определяет имя, которое будет использовано при обратном вызове и которое должно будет интерпретироваться NAS. Атрибут может использоваться в Access-Accept пакетах.
Атрибут Framed-Route
Данный атрибут предоставляет информацию маршрутизации, которая будет сконфигурирована для пользователя NAS. Атрибут используется в пакете Access-Accept, и может появиться там несколько раз.
Атрибут State
Атрибут посылается сервером клиенту в сообщении Access-Challenge и должен быть отправлен без изменения обратно клиентом серверу в новом Access-Request, который является ответом на запрос.
Данный атрибут может быть послан сервером клиенту в сообщении Access-Accept, в котором должен быть также атрибут Termination-Action со значением RADIUS-Request. Если NAS выполняет Termination-Action, посылая новый Access-Request при завершении текущей сессии, он должен включить без изменения атрибут State в этот Access-Request.
В любом случае клиент не должен интерпретировать данный атрибут локально. В пакете не может быть больше одного атрибута State. Использование данного атрибута во многом зависит от реализации.
Атрибут Class
Данный атрибут посылается сервером клиенту в Access-Accept, и должен отправляется без изменения клиентом серверу, хранящему учетные записи (аккаунтинг) как часть Accounting-Request пакета, если используется аккаунтинг. Клиент не должен интерпретировать данный атрибут локально.
Атрибут Vendor-Specific
Данный атрибут позволяет производителям поддерживать свои собственные атрибуты. Данный атрибут не должен влиять на операции протокола RADIUS.
Сервер, который не знает, как интерпретировать относящуюся к производителю информацию, должен игнорировать данный атрибут.
Атрибут Session-Timeout
Данный атрибут устанавливает максимальное время (в секундах) перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.
Атрибут Idle-Timeout
Данный атрибут устанавливает максимально допустимое число секунд простоя соединения перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.
Атрибут Termination-Action
Данный атрибут определяет действие, которое должен выполнить NAS при завершении определенного сервиса. Используется только в пакетах Access-Accept.
Атрибут Called-Station-Id
Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, который использовал пользователь. Заметим, что это может отличаться от номера телефона, с которого пришел вызов. Данный атрибут используется только в пакетах Access-Request.
Атрибут Calling-Station-Id
Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, с которого пришел вызов. Атрибут используется только в пакетах Access-Request.
Атрибут NAS-Identifier
Данный атрибут содержит строку, идентифицирующую NAS, который создал исходный Access-Request. Атрибут используется только в пакетах Access-Request. Либо NAS-IP-Address, либо NAS-Identifier должен присутствовать в пакете Access-Request.
Заметим, что NAS-Identifier не должен использоваться для выбора разделяемого секрета, аутентифицирующего запрос. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.
Атрибут Proxy-State
Данный атрибут может быть послан прокси-сервером другому серверу при перенаправлении Access-Request. Атрибут должен быть возвращен без изменения в Access-Accept, Access-Reject или Access-Challenge. Когда прокси-сервер получает ответ на свой запрос, он должен удалить свой собственный Proxy-State (последний Proxy-State в пакете) перед тем, как перенаправить ответ к NAS.
Если атрибут Proxy-State добавляется в пакет, то он должен быть добавлен после всех имеющихся атрибутов Proxy-State.
Содержимое всех других атрибутов Proxy-State, отличных от добавляемого, должно рассматриваться как неформатированные данные и не должно влиять на операции протокола.
Использование атрибута Proxy-State зависит от протокола.
Атрибут CHAP-Challenge
Данный атрибут содержит CHAP Challenge, посылаемый NAS. Он используется только в Access-Request пакетах.
Если значение вызова СНАР имеет длину в 16 октетов, то оно может быть размещено в поле аутентификатора запроса, а не в данном атрибуте.
Атрибут NAS-Port-Type
Данный атрибут определяет тип физического порта NAS, с которого выполняется аутентификация пользователя. Атрибут может использоваться вместо или в дополнение к атрибуту NAS-Port. Данный атрибут используется только в Access-Request пакетах. Если NAS различает свои порты, то в пакете Access-Request должен присутствовать либо атрибут NAS-Port, либо атрибут NAS-Port-Type, либо оба эти атрибута.
Атрибут Port-Limit
Данный атрибут устанавливает максимальное количество портов, которое может предоставить NAS своим пользователям. Атрибут может быть послан сервером клиенту в пакете Access-Accept. Предполагается, что он будет использоваться вместе с многоканальным РРР или в аналогичной технологии. Он также может быть послан NAS к серверу в качестве предпочтения, какое количество портов может использоваться, но сервер может игнорировать это.
Атрибуты RADIUS, специфичные для ПО Microsoft
Рассмотрим атрибуты, которые могут быть переданы в одном или более атрибутах RADIUS, тип которых есть Vendor-Specific. В одном Vendor-Specific атрибуте могут быть переданы несколько атрибутов; в этом случае эти атрибуты пакетируются в виде последовательности троек Vendor-Type/Vendor-Length/Value, которые следуют за начальными полями Type, Length и Vendor-Id. Поле Vendor-ID должно быть установлено в десятичное значение 311 (Microsoft).
Атрибуты для поддержки MS-CHAP V1
Microsoft разработала протокол MS-CHAP для аутентификации удаленных рабочих станций Windows, обеспечивая функциональность, аналогичную той, к которой привыкли пользователи сети. Где это возможно, MS-CHAP аналогичен стандартному СНАР. Основная разница в следующем:
Algorithm) в аутентификационном протоколе.Response протокола MS-CHAP имеет формат, совместимый с Microsoft Windows и сетевым ПО Microsoft. Формат MS-CHAP не требует, чтобы аутентифицирующая сторона хранила пароли в явном виде или в обратимом зашифрованном виде. Message пакета Failure.Атрибуты RADIUS отражают эти отличия.
Атрибут MS-CHAP-Challenge
Данный атрибут содержит вызов, посылаемый NAS к пользователю MS-CHAP. Он может использоваться в пакетах Access-Request и Access-Challenge.
Атрибут MS-CHAP-Response
Данный атрибут содержит ответ, передаваемый пользователем в ответ на вызов. Атрибут используется только в пакетах Access-Request.
Атрибут MS-CHAP-Domain
Атрибут MS-CHAP-Domain определяет Window-домен, в котором пользователь был аутентифицирован. Данный атрибут может быть включен в пакеты Access-Accept и Accounting-Request.
Атрибут MS-CHAP-Error
Атрибут MS-CHAP-Error содержит информацию об ошибке, относящуюся к предыдущему MS-CHAP-обмену. Данный атрибут может использоваться в обменах как MS-CHAP-V1, так и MS-CHAP-V2. Данный атрибут используется только в пакетах Access-Reject.
Атрибут MS-CHAP-CPW-1
Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут может использоваться только в пакетах Access-Request и должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP не меньше 2.
Атрибут MS-CHAP-CPW-2
Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут используется только в пакетах Access-Request, и включается только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль истек, и версия MS-CHAP равна 2.
Атрибут MS-CHAP-LM-Enc-PW
Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, пароль разделяется на несколько частей и передается в нескольких атрибутах. В атрибут включается последовательный номер (2 октета), чтобы обеспечить возможность правильной сборки фрагментов пароля.
Атрибут используется только в пакетах Access-Request совместно с атрибутом MS-CHAP-CPW-2. Атрибут должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP равна 2 или более.
Атрибут MS-CHAP-NT-Enc-PW
Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля Windows. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, то пароль разделяется на несколько частей и передается в нескольких атрибутах. Последовательный номер включается в атрибут, чтобы обеспечить сборку фрагментов пароля.
Данный атрибут используется только в пакете Access-Request совместно с атрибутами MS-CHAP-CPW-2 и MS-CHAP-CPW. Он включает только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия протокола MS-СНАР равна 2 или более.
Атрибуты для поддержки MS-CHAP V2
Рассмотрим RADIUS-атрибуты, необходимые для поддержки второй версии протокола MS-CHAP. Протокол MS-CHAP-V2 аналогичен, но не совместим с протоколом MS-CHAP-V1. Некоторые поля удалены или используются по-другому. Протокол MS-CHAP-V2 максимально согласован как с протоколом MS-CHAP-V1, так и со стандартным протоколом СНАР.
Кратко различия между протоколами MS-CHAP-V2 и MS-CHAP-V1 следующие:
Response и аутентифицируя ответ в пакете Success.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 для доставки информации об учетных записях от NAS к серверу учетных записей RADIUS.
(рис 12.19) Последовательность пакетов при выполнении аккаунтинга
Если клиент сконфигурирован для использования RADIUS-аккаунтинга, то перед началом получения сервиса создается пакет Accounting Start, описывающий тип сервиса и пользователя, которому необходим этот сервис. Эта информация посылается к серверу аккаунтинга RADIUS.
(рис 12.20) Пример первого пакета Accounting Start RADIUS
Затем этот сервер присылает подтверждение, что пакет был получен.
После завершения получения сервиса NAS создает пакет Accounting Stop, в котором описан тип полученного сервиса и возможно различная статистическая информация, такая как затраченное время, количество входящего и исходящего трафика. Этот пакет посылается к серверу аккаунтинга RADIUS, который присылает подтверждение, что пакет был получен.
Клиент посылает пакеты Accounting-Request до тех пор, пока не получит тем или иным способом подтверждения. После того, как клиент не получил подтверждения в течение определенного времени, он может перенаправить запрос альтернативному серверу.
Сервер аккаунтинга RADIUS может делать запросы другим серверам, в этом случае он действует как клиент.
Аккаунтинг прокси функционирует аналогично аутентификационному прокси.
(рис 12.21) Топология сети при использовании прокси-сервера RADIUS
Proxy-State (если требуется) после всех остальных атрибутов Proxy-State, изменяет Аутентификатор запроса и перенаправляет запрос удаленному серверу.Proxy-State, а также помещает их в пакет ответа и посылает перенаправляющему серверу.Перенаправляющий сервер не должен модифицировать существующие в пакете атрибуты 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 могут быть включена атрибуты разных типов. Атрибуты некоторых типов могут быть включены несколько раз. В этом случае порядок атрибутов одного и того же типа фиксирован.
Тип пакета RADIUS определяется полем Code.
Пакет Accounting-Request
Пакеты Accounting-Request посылаются от клиента (обычно NAS или прокси) к аккаунтинг-серверу RADIUS и содержат информацию, используемую для авторизации доступа к сервису, предоставляемого пользователю. Клиент передает RADIUS-пакет с полем Code, установленным в 4 (Accounting-Request).
При получении Accounting-Request сервер должен передать ответ Accounting-Response, если он успешно записал пакет аккаунтинга, и не должен передавать никакого ответа, если произошел сбой при записи пакета аккаунтинга.
Любой атрибут, который используется в пакетах Access-Request и Access-Accept, может использоваться и в пакете Accounting-Request, за исключением следующих атрибутов, которые не должны присутствовать в пакетах Accounting-Request: User-Password, CHAP-Password, Reply-Message, State. В пакете Accounting-Request должен присутствовать атрибуты либо NAS-IP-Address, либо NAS-Identifier. Пакет должен содержать NAS-Port, или NAS-Port-Type, или оба атрибута, если только в сервисе не определен порт, или NAS не различает свои порты.
Если пакет Accounting-Request содержит Framed-IP-Address, то атрибут должен содержать IP-адрес пользователя. Если Access-Request использует специальные значения для Framed-IP-Address, которые означают, что NAS должен назначить IP-адрес пользователю или вести о нем переговоры, то Framed-IP-Address (если есть) в Accounting-Request должен содержать реальный IP-адрес, который назначен или о котором договорились.
Пакет Accounting-Response
Пакеты Accounting-Response посылаются сервером RADIUS клиенту как подтверждение того, что Accounting-Request был получен и успешно записан. Если Accounting-Request был успешно записан, то аккаунинг сервер должен передать пакет с полем Code, установленным в 5 (Accounting-Response). При получении Accounting-Response клиент проверяет, что поле Identifier соответствует отправленному в запросе. Аутентификатор ответа должен содержать корректное значение. Недействительный пакет молча отбрасывается.
Атрибуты отражают детали аутентификации, авторизации и аккаунтинга в запросе и ответе.
Некоторые атрибуты могут быть включены несколько раз. Результат такого включения зависит от атрибута.
Атрибуты имеют следующий формат.
(рис 12.23) Формат RADIUS-атрибутов
Поле Type
Поле Type имеет длину один октет. Основные типы атрибутов следующие:
40 Acct-Status-Type 41 Acct-Delay-Time 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause 50 Acct-Multi-Session-Id 51 Acct-Link-Count
Поле Length
Поле Length имеет длину один октет и определяет длину данного атрибута, включая поля Type, Length и Value. Если в Accounting-Request получен атрибут с неправильным значением поля Length, то весь пакет отбрасывается.
Поле Value
Поле Value состоит из нуля или более октетов и содержит информацию, зависящую от атрибута. Формат и длина поля Value зависят от типа и длины данного атрибута.
Атрибут Acct-Status-Type
Атрибут указывает, маркирует ли данный пакет Accounting-Request начало пользовательского сервиса (Start) или конец (Stop).
Он может использоваться клиентом для маркировки начала аккаунтинга (например, после перезагрузки), указав специальное значение атрибута Accounting-On и пометив конец аккаунтинга (например, перед плановым перезапуском) специальным значением атрибута Accounting-Off.
Атрибут Acct-Delay-Time
Атрибут указывает сколько секунд клиент пытается послать данную запись, и может вычитаться из времени получения сервером пакета Accounting-Request, т.е. время передачи по сети будет игнорироваться.
Атрибут Acct-Input-Octets
Атрибут определяет, сколько октетов было получено с порта, на котором был предоставлен сервис, и может присутствовать только в пакетах Accounting-Request, в которых Acct-Status-Type установлен в Stop.
Атрибут Acct-Output-Octets
Атрибут определяет, сколько октетов было послано на порт, на котором выполняется данный сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Session-Id
Атрибут содержит уникальный идентификатор, который используется для нахождения соответствующих пар старт- и стоп-записей в лог-файле. Старт- и стоп-записи для данной сессии должны иметь один и тот же Acct-Session-Id. Пакет Access-Request может содержать атрибут Acct-Session-Id. Если он содержит этот атрибут, то NAS должен использовать тот же самый Acct-Session-Id во всех пакетах Accounting-Request, относящихся к данной сессии.
Атрибут Acct-Authentic
Атрибут может быть включен в пакет Accounting-Request для указания того, был ли пользователь аутентифицирован самим NAS или использовался протокол RADIUS или другой протокол удаленной аутентификации. Для пользователей, которые получили сервис без выполнения аутентификации, не должны создаваться записи аккаунтинга.
Атрибут Acct-Session-Time
Атрибут указывает, сколько секунд пользователь получал сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Input-Packets
Атрибут указывает, сколько пакетов было получено с порта в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Output-Packets
Атрибут указывает, сколько пакетов было послано на порт в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Terminate-Cause
Атрибут указывает, как сессия была завершена, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Multi-Session-Id
Данный атрибут является уникальным Accounting ID, что позволяет легко объединить в лог-файле несколько взаимосвязанных сессий. Каждая сессия имеет уникальный атрибут Acct-Session-Id, но взаимосвязанные сессии имеют один и тот же атрибут Acct-Link-Count.
Атрибут Acct-Link-Count
Атрибут содержит количество взаимосвязанных (с помощью атрибута Acct-Link-Count) сессий. NAS может включить атрибут Acct-Link-Count в любой пакет Accounting-Request, который связан с несколькими сессиями.
Это дает возможность аккаунтинг-серверу объединить все записи в логах, относящиеся к взаимосвязанным сессиям.
Идентификация – сервис, с помощью которого определяются уникальные свойства пользователей, с помощью которых можно отличать их друг от друга, и способы, с помощью которых, пользователи указывают свои идентификации информационной системе. Идентификация тесно связана с аутентификацией.
Аутентификация – сервис, с помощью которого доказывается, что участники являются требуемыми, т.е. обеспечивается доказательство идентификации. Это может достигаться с помощью паролей, смарт-карт, биометрических токенов и т.п. В случае передачи единственного сообщения аутентификация должна гарантировать, что получателем сообщения является тот, кто нужно, и сообщение получено из заявленного источника. В случае установления соединения имеют место два аспекта. Во-первых, при инициализации соединения сервис должен гарантировать, что оба участника являются требуемыми. Во-вторых, сервис должен гарантировать, что на соединение не воздействуют таким образом, что третья сторона сможет маскироваться под одну из легальных сторон уже после установления соединения.
Как правило, при большом числе пользователей идентификационные и аутентификационные данные хранятся на отдельном сервере. Это позволяет освободить межсетевой экран от необходимости хранить большие объемы идентификационных и аутентификационных данных. Доступ к серверу, на котором хранятся идентификационные и аутентификационные данные, как правило, осуществляется либо по протоколу RADIUS, либо по прото-колу LDAP (рис. 12.1).
Будем предполагать, что сеть имеет следующую топологию.
(рис 12.1) Топология сети при использовании сервера идентификации
Конечная цель – предоставить аутентифицированный и авторизованный доступ пользователю с удаленного хоста к серверу, расположенному в LAN или DMZ. Между МЭ1 и МЭ2 выполняется один из протоколов VPN. Учетные записи пользователей хранятся на сервере RADIUS. Идентифика-ционная и аутентификационная информация указывается на удаленной точке туннеля. Запрос аутентификации и используемый сервер, на котором хранятся идентификационные и аутентификационные данные, указываются на локальной стороне туннеля. При успешной аутентификации пользователю с удаленного хоста предоставляется доступ к серверу, расположенному в LAN или DMZ.
Взаимодействующими сторонами в протоколе RADIUS (Remote Au-thentication Dial In User Service) являются:
Сервер RADIUS– сервер, выполняющий аутентификацию, авторизацию и хранение учетных записей (аккаунтинг). В английском варианте Authentication, Authorization и Accounting – ААА. RADIUS предоставляет сервисы ААА для NAS.
Сервер Сетевого Доступа (Network Access Server – NAS)– устройство, которое предоставляет удаленным пользователям доступ в сеть и является клиентом для сервера RADIUS.
Аутентификация, авторизация и аккаунтинг выполняются для удаленной стороны туннеля, в нашем случае для учетной записи, указанной в конфигурации МЭ1.
Основные принципы функционирования RADIUS:
Сервер RADIUS получает запрос от NAS, аутентифицирует пользователя и затем возвращает NAS всю необходимую для предоставления сервиса информацию.
Сервер RADIUS может функционировать как прокси-клиент для других серверов RADIUS или аутентификационных серверов других типов.
(рис 12.2) Задание секрета между NAS и сервером RADIUS на стороне NAS
(рис 12.3) Задание секрета между NAS и сервером RADIUS на стороне сервера RADIUS
(рис 12.4) Защищенность пользовательского пароля при пересылке между NAS и сервером RADIUS(рис 12.5) Параметры РРР-аутентификации на стороне NAS
(рис 12.6) Параметры РРР-аутентификации на стороне сервера RADIUS
В протоколе RADIUS все данные передаются в элементах, которые называются атрибутами.
Атрибуты RADIUS используются для передачи:
Атрибут может быть определен в спецификации протокола RADIUS, и в этом случае говорят, что он является стандартным и принадлежит стандартному пространству имен, либо может быть определен производителем, в этом случае говорят, что он принадлежит пространству имен производи-теля и являются Vendor-Specific Attributes (VSA).
Такие атрибуты определяются производителем и указываются в поле String.
Значение каждого атрибута принадлежит определенному типу данных. В отличие от протокола SNMP в RADIUS нет формального языка определения данных.
Типы данных могут быть "базовые" и "комплексные". Базовые типы данных используют один из существующих типов данных RADIUS, которые могут содержаться в стандартном атрибуте или VSA-атрибуте.
(рис 12.7) Пример атрибутов RADIUS
В RADIUS определены следующие базовые типы данных:
Следующие типы данных определены как "комплексные":
Пространство имен производителя обозначается как VSA. При этом Vendor-Id определяет конкретного производителя, а поле String определяет уникальный тип атрибута для данного производителя.
Функционирование RADIUS основано на следующих принципах:
Access-Reject и Disconnect-Request.Хотя производители серверов RADIUS и могут поддерживать состояние, в самом протоколе RADIUS понятие состояния не определено. Однако определенная информация может передаваться от одной транзакции к другой с помощью атрибута State.
В спецификации RADIUS определены атрибуты, содержащие конфиденциальную информацию (например, пароли). Такие атрибуты не пересылаются в запросе и не возвращаются в ответе в открытом виде. Кроме того, аутентификационный механизм связывает вместе последовательность пакетов Access-Request / Access-Challenge в одной аутентификационной сессии с помощью атрибута State.
Протокол RADIUS является протоколом типа запрос-ответ, выполняющимся между клиентом и сервером RADIUS. Один пакет запроса требует в ответ по крайней мере один пакет, который посылается на IP-адрес и порт клиента.
Длина пакета RADIUS не может быть больше 4096 байтов (октетов).
Даже если длина пакета меньше, чем 4096 байтов, она может быть больше, чем Path MTU (PMTU). Любой пакет, длина которого больше, чем PMTU, будет фрагментирован, что может привести к сложности прохожде-ния межсетевых экранов, которые отбрасывают фрагментированные пакеты. Если приходится использовать фрагментированные пакеты, то необхо-димо тщательное тестирование корректного прохождения всех межсетевых экранов и устройств, которые могут отбрасывать фрагментированные пакеты. Некоторые устройства не могут передавать фрагментированные UDP-пакеты, затрудняя развертывание RADIUS в сети с такими устройствами. Рекомендуется следить за тем, чтобы сообщения RADIUS были как можно более маленькими.
Если необходимо передавать пакеты большей длины, чем 4096 байтов, то используется один из следующих подходов:
Access-Request / Access-Response пакетов. (рис 12.8) Последовательность пакетов при выполнении аутентификации
Пользователь предоставляет NAS аутентификационную информацию, после этого NAS использует протокол RADIUS для аутентификации данного пользователя. Эта аутентификационная информация может предоставляться в виде настраиваемого приглашения для входа, когда от пользователя требуется ввести имя и пароль. Либо может использовать такой протокол, как РРР, в котором существуют аутентификационные пакеты для пересылки данной информации.
(рис 12.9) Задание аутентификационных данных пользователя на противоположной NAS стороне туннеля
После того, как NAS получил эту информацию, он может выполнить аутентификацию пользователя на сервере RADIUS. Для того чтобы сделать это, NAS создает запрос Access-Request, содержащий в качестве атрибутов имя пользователя, пароль, идентификатор и тип порта NAS, к которому пользователь хочет получить доступ. Если присутствует пароль, то используется метод его скрытия, основанный на алгоритме хэширования MD5.
(рис 12.10) Пересылка аутентификационных данных пользователя по туннелю между NAS и противоположной стороной туннеля
Атрибуты RADIUS используются для передачи аутентификационной и авторизационной информации и деталей конфигурирования.
Некоторые атрибуты могут быть включены в сообщение несколько раз. Результат такого включения зависит от атрибута.
Если есть несколько атрибутов одного и того же типа, то прокси-серверы не должны изменять их упорядоченность. Порядок атрибутов разных типов прокси-серверами может быть изменен. Поведение RADIUS-сервера и клиента никак не зависит от упорядоченности атрибутов разных типов. Не требуется, чтобы атрибуты одного и того же типа были расположены рядом друг с другом.
(рис 12.11) Пересылка аутентификационных данных между NAS и сервером RADIUS
Access-Request передается по сети серверу RADIUS. Если в течение определенного времени ответ не получен, то запрос повторяется. Клиент может также направить запросы к альтернативному серверу или нескольким серверам в случае, если первичный сервер выключен или не доступен. Альтернативный сервер может использоваться либо после определенного числа неудачных попыток обращения к первичному серверу, либо по круговому алгоритму.
После получения запроса сервер RADIUS выполняет аутентификацию NAS. Запрос от NAS, с которым сервер RADIUS не имеет разделяемого секрета, молча, т.е. без уведомления противоположной стороны, отбрасывается.
Если NAS аутентифицирован, RADIUS-сервер ищет в базе данных пользователей имя, указанное в запросе. Запись пользователя в базе данных содержит список требований, которые должны быть выполнены, чтобы пользователю можно было разрешить доступ. Это всегда включает проверку пароля, но можно также определить дополнительные параметры, которые проверяются перед тем, как пользователю будет разрешен доступ.
(рис 12.12) Указание параметров аутентификации на стороне сервера RADIUS
Сервер RADIUS может сделать запросы к другим серверам, чтобы обработать данный запрос. В этом случае он является прокси и действует как клиент по отношению к другому серверу RADIUS.
Если в запросе Access-Request есть какие-либо атрибуты Proxy-State, они должны быть скопированы без каких-либо изменений и в том же порядке в пакет ответа. Остальные атрибуты могут быть расположены до, после и даже между Proxy-State атрибутами.
Если какое-либо из условий не выполнено, сервер RADIUS посылает Access-Reject ответ, который говорит о том, что аутентификация не выполнена и запрос пользователя на вход отвергается. Сервер может также включить в Access-Reject текстовое сообщение, которое будет показано пользователю. Никаких других атрибутов, за исключением Proxy-State, в Access-Reject не передается.
(рис 12.13) Пример сообщения Access-Reject при отсутствии у пользователя или NAS требуемых аутентификационных данных
Если все условия выполнены, и RADIUS-серверу требуется получить дополнительные ответы от пользователя, RADIUS-сервер посылает Access-Challenge ответ. Он может включить текстовое сообщение, которое будет показано пользователю, и может включать атрибут State.
Если NAS получил Access-Challenge и поддерживает Запрос / Ответ, он может показать текстовое сообщение, если оно есть, и затем выдать приглашение пользователю для ввода ответа. Затем клиент передает свой исходный Access-Request с новым ID запроса и с атрибутом User-Password и атрибутом State из Access-Challenge, если они были там указаны.
В ответе не может быть больше одного экземпляра атрибута State. На это сообщение сервер может ответить новым Access-Request, указав в нем либо Access-Request, либо Access-Reject, либо другой Access-Challenge.
Если все условия выполнены, в ответ Access-Request помещается список конфигурационных значений. Эти значения включают тип сервиса (например, SLIP, PPP, Login User) и все необходимые значения для получения требуемого сервиса. Для SLIP и РРР это может включать такие значения, как IP-адрес, маска подсети, MTU, алгоритм сжатия и идентификаторы требуемых фильтров пакетов. Могут быть также указаны требуемый протокол и хост.
(рис 12.14) Пример сообщения Access-Request при выполнении аутентификации
При аутентификации Вызов/Ответ (Challenge/Response) пользователь получает заранее неизвестное число запросов, на которые он должен дать ответ. Для создания корректного ответа пользователь должен иметь либо специальные устройства, такие как смарт-карты, либо ПО, которое создает ответ. Если у пользователя нет соответствующего устройства или в ПО не установлено корректное значение секрета, пользователь считается неавторизованным.
Пакет Access-Challenge обычно содержит Reply-Message, которое показывается пользователю, например, числовое значение, которое никогда не повторяется.
Затем пользователь вводит это случайное число в смарт-карту или программу, которая вычисляет ответ. Пользователь вводит этот ответ, и NAS пересылает его на сервер RADIUS во втором Access-Request. Если ответ правильный, сервер RADIUS возвращает Access-Request, в противном случае возвращает Access-Reject.
Пример:
(рис 12.15) Пример последовательности пакетов при Challenge/Response
NAS посылает пакет Access-Request к серверу RADIUS с атрибутами NAS-Identifier, NAS-Port, User-Name, User-Password (который может быть фиксированной строкой типа "challenge" и игнорироваться). Сервер посылает обратно пакет Access-Challenge с атрибутами State, Reply-Message и строкой "Challenge 12345678, введите ваш ответ", которую NAS показывает пользователю. NAS выдает приглашение пользователю для ответа и посылает полученный ответ в новом пакете Access-Request к серверу (с новым ID), содержащий атрибуты NAS-Identifier, NAS-Port, User-Name, User-Password. В этом случае ответ, который только что ввел пользователь, защищен. Этот ответ содержит тот же самый атрибут State, который был указан в Access-Challenge. После этого сервер присылает обратно либо пакет Access-Request, либо пакет Access-Reject.
При использовании РАР NAS получает РАР ID и пароль и посылает их в пакете Access-Request в качестве атрибутов User-Name и User-Password. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol=PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
При использовании СНАР NAS создает случайный вызов (желательно 16 октетов) и посылает его пользователю, который возвращает СНАР-ответ вместе с атрибутами CHAP ID и СНАР Username. Затем NAS посылает пакет Access-Request к серверу RADIUS со значением СНАР Username в атрибуте User-Name и со значением СНАР ID и СНАР-ответом в атрибуте CHAP-Password. Случайный вызов либо может быть включен в атрибут CHAP-Challenge, либо, если его длина больше 16 октетов, он может быть помещен в поле Request Authenticator в пакете Access-Request. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
Если сервер RADIUS не может выполнить необходимую проверку, он возвращает Access-Reject. Например, при использовании СНАР требуется, чтобы пароль пользователя был доступен серверу в незашифрованном виде для того, чтобы он мог хэшировать его вместе с вызовом и сравнить с тем, что получил в качестве СНАР-ответа. Если пароль не доступен серверу RADIUS в незашифрованном виде, то он посылает клиенту Access-Reject.
(рис 12.16) Топология сети при использовании прокси-сервера RADIUS
При использовании RADIUS-прокси один RADIUS-сервер получает запрос на аутентификацию (или аккаунтинг) от RADIUS-клиента (такого как NAS), перенаправляет запрос к удаленному RADIUS-серверу, получает ответ от него и посылает этот ответ клиенту, возможно с изменениями, от-ражающими локальную административную политику. RADIUS-прокси чаще всего используется при роуминге. В этом случае для предоставления доступа несколько административных единиц должны аутентифицировать пользователей друг друга.
NAS посылает свой запрос на доступ к перенаправляющему серверу, который перенаправляет этот запрос на удаленный сервер. Удаленный сервер присылает ответ (Access-Request, Access-Reject или Access-Challenge) обратно перенаправляющему серверу, который посылает его к NAS. Атрибут User-Name может содержать идентификатор сетевого доступа (например, userID, переданный клиентом при РРР-аутентификации). Выбор сервера, которому следует перенаправить запрос, основывается на аутентификационной области (realm). Аутентификационная область может быть частью области идентификатора сетевого доступа ("области имени"). Выбор сервера, которому пересылается запрос, может быть основан и на каком-то другом критерии.
RADIUS-сервер может функционировать и как перенаправляющий сервер для одних областей, и как удаленный сервер для других областей. Один перенаправляющий сервер может перенаправлять запросы любому числу удаленных серверов. Один удаленный сервер может получать пере-направления от любого числа серверов и может выполнять аутентифика-цию для любого числа областей. Один перенаправляющий сервер может выполнять перенаправление другому перенаправляющему серверу, создавая тем самым цепочку прокси. При этом следует стараться избегать создания циклов.
Следующий сценарий иллюстрирует взаимодействие между RADIUS-прокси, NAS и удаленным RADIUS-сервером:
Access-Request, Access-Reject или Access-Challenge обратно перенаправляющему серверу. В нашем случае предположим, что посылается Access-Request.Access-Request к NAS.Перенаправляющий сервер должен рассматривать все атрибуты Proxy-State в пакете как неструктурированные данные. Его действия не должны зависеть от содержимого Proxy-State атрибутов, которые были добавлены предыдущими серверами.
Если в запросе, полученном от клиента, существуют какие-либо атрибуты Proxy-State , перенаправляющий сервер должен включить эти атрибуты Proxy-State в ответ клиенту. Перенаправляющий сервер может как включать, так и не включать Proxy-State атрибуты в запрос доступа при перенаправлении запроса. Если перенаправляющий сервер не включил Proxy-State атрибуты в перенаправленный запрос доступа, он должен присоединить их к ответу перед тем, как посылать ответ обратно клиенту.
Рассмотрим каждый шаг более детально.
User-Password, если он есть, используя общий секрет с NAS. Если в пакете присутствует атрибут CHAP-Password и нет атрибута CHAP-Challenge, перенаправляющий сервер не должен изменять атрибут Request-Authenticator или должен копировать его в атрибут CHAP-Challenge. Перенаправляющий сервер может добавить в пакет не более одного атрибута Proxy-State. Если он добавляет атрибут Proxy-State, то он должен быть добавлен после всех остальных атрибутов Proxy-State, которые уже есть в пакете. Перенаправляющий сервер не изменяет последовательность атрибутов одного и того же типа, включая атрибуты Proxy-State.User-Password, если он присутствует. Для защиты от replay-атак используется секрет, который он разделяет с удаленным сервером. Перенаправляющий сервер может добавить значение Identifier, после чего перенаправляет запрос на доступ к удаленному серверу.User-Password, CHAP-Password или какой-либо другой метод, и возвращает обрат-но перенаправляющему серверу ответ Access-Request, Access-Reject или Access-Challenge. Предположим, что посылается Access-Request. Удаленный сервер должен копировать, не модифицируя, все атрибуты Proxy-State (и только их) из запроса на доступ в пакет ответа.Proxy-State (если он был присоединен), обеспечивает целостность аутентификатора ответа, используя секрет, который он разделяет с NAS, и посылает Access-Request к NAS.Перенаправляющему серверу может понадобиться изменить атрибуты для реализации локальной политики. Но при этом перенаправляющий сервер не должен изменять имеющиеся в пакете атрибуты Proxy-State, State или Class.
Производители перенаправляющих серверов определяют значения, которые они готовы принимать в качестве значения атрибута Service-Type. Это может повлиять на передачу значения Service-Type от NAS в проксируемом пакете Access-Request. Могут также существовать механизмы, которые блокируют определенные типы сервисов.
Часто возникает вопрос, почему в качестве транспорта сообщений RADIUS используется UDP, а не ТСР. UDP был выбран исключительно по техническим причинам.
Существуют определенные проблемы, в результате которых UDP становится более предпочтительным транспортным протоколом. RADIUS является протоколом, основанным на транзакциях, который обладает следующими характеристиками:
С одной стороны RADIUS не требует сверх точного определения потерянных данных. Пользователь может подождать несколько секунд для завершения аутентификации, поэтому по-стоянные повторные передачи, которые имеют место в ТСР, не требуются.
С другой стороны пользователя нельзя заставлять ждать завершения аутентификации несколько минут. Следовательно, надежная доставка ТСР-данных в течение двух минут не нужна. Быстрее использовать альтернативный сервер, который может предоставить доступ.
И клиент, и сервер могут завершить соединение, любая из сторон может выполнить перезапуск всей системы. При этом обычно не возникает проблем, связанных с необходимостью определения потерянного соединения, которые имеют место в протоколе ТСР. Код может быть просто написан с учетом обработки аномальных событий. В самом протоколе UDP полностью отсутствует какая-либо специальная обработка при потере соединения. И клиент, и сервер могут использовать данное UDP-соединение только один раз.
В ранних реализациях RADIUS сервер состоял из единственной нити. Это означало, что одновременно мог получаться, обрабатываться и возвращаться единственный запрос. Это за-медляло обработку в тех случаях, когда используемым механизмам безопасности требовалось много времени. Также могла переполниться очередь запросов на сервер, если сотням людей ежеминутно требовалась аутентификация. Очевидным решением этой проблемы является реализация сервера с использованием нескольких нитей. Сделать это значительно проще, используя UDP. Каждый процесс обрабатывал отдельный запрос и отвечал клиенту NAS простым UDP-пакетом.
Это не является панацеей от всех бед. При использовании UDP на прикладном уровне требуется помнить о проблемах, которые автоматически решаются в ТСР, например управлением таймерами повторных передач.
Если RADIUS-сервер и альтернативный RADIUS-сервер разделяют общий секрет, то можно переслать пакет альтернативному RADIUS-серверу с тем же самым ID и аутентификатором запроса, так как содержимое атрибутов не изменилось. Если необходимо использовать новый аутентификатор запроса при отправке запроса альтернативному серверу, это можно сделать.
Если сервер изменил содержимое атрибута User-Password (или любого другого атрибута), то он должен создать новый аутентификатор запроса и, следовательно, новый ID.
Если NAS повторяет запрос к тому же самому серверу, и атрибуты не изменились, следует использовать тот же самый аутентификатор запроса, ID и порт источника. Если какой-либо атрибут изменился, необходимо использовать новые аутентификатор запроса и ID.
NAS может использовать один и тот же ID для всех серверов или может для каждого сервера использовать отдельный ID.
Некоторые производителя посылают тестовые запросы для проверки жизнеспособности сервера. Это не самая лучшая практика, так как увели-чивается трафик и уменьшается масштабируемость, без предоставления при этом никакой дополнительной информации. Так как запрос RADIUS содержится в единственной дейтаграмме, можно вместо этого просто выполнить команду ping.
Для мониторинга RADIUS-сервера следует использовать протокол SNMP.
В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1812.
При создании ответа порты отправителя и получателя меняются местами.
(рис 12.17) Формат RADIUS-пакета аутентификации
Поле Code
Поле Code состоит из одного октета и определяет тип RADIUS-пакета. Если получен пакет с недействительным значением поля Code, то пакет молча (без ответа) отбрасывается. В поле Code могут быть указаны следующие значения:
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server 13 Status-Client
Поле Identifier
Поле Identifier состоит из одного октета и предназначено для сопоставления пар запросов и ответов. RADIUS-сервер может определить дубликат запроса, если запрос имеет IP-адрес источника, UDP-порт источника и значения поля Identifier, что и у уже полученного запроса.
Поле Length
Поле Length состоит из двух октетов. Оно содержит длину пакета, состоящего из полей Code, Identifier, Length, Authenticator и Attribute.
Поле Authenticator
Поле Authenticator состоит из 16 октетов. Это значение используется для определения повторных ответов от RADIUS-сервера и используется в алгоритме скрытия пароля.
Аутентификатор запроса
В пакете Access-Request значение Authenticator состоит из 16-октетного случайного числа, называемого аутентификатор запроса. Значение должно быть случайным. Хотя протокол RADIUS и не может защитить от встраивания поддельной информации в аутентифицированную сессию с помощью активной атаки man-in-the-middle, создание случайного значения в качестве аутентификатора защищает от большого числа активных атак, связанных с аутентификацией.
NAS и RADIUS-сервер разделяют общий секрет. Выполняется конкатенация этого секрета и аутентификатора запроса, результат подается на вход хэш-функции MD5, которая создает 16-октетное значение дайджеста. Затем выполняется операция XOR полученного значения и пароля, введен-ного пользователем, и результат помещается в атрибут User-Password в пакете Access-Request.
Аутентификатор ответа
Значение поля Authenticator в пакетах Access-Request, Access-Reject и Access-Challenge называется аутентификатором ответа и содержит хэш-значение MD5, вычисленное для RADIUS-пакета, начиная с поля Code и включая поля Identifier, Length, Request Authenticator из пакета Access-Request, Attributes из ответа, за которыми следует разделяемый секрет.
MD5 (Code+ID+Length+RequestAuth+Attributes+Secret)
где "+" означает конкатенацию.
Вопросы администрирования
Секрет (пароль, разделяемый клиентом и RADIUS-сервером) должен быть такой длины, чтобы его трудно было перебрать. Считается, что его длина должна быть по крайней мере 16 октетов.
Перенаправляющий прокси может изменить содержимое пакета, а именно он может добавить атрибут Proxy-State. Когда прокси возвращает ответ, он должен удалить свой атрибут Proxy-State, если тот был добавлен. Proxy-State всегда добавляется после других атрибутов Proxy-State, но никаких других предположений относительно его расположения в списке атрибутов не делается. Так как ответы Access-Request и Access-Reject аутентифицированы как часть содержимого всего пакета, удаление атрибута Proxy-State делает недействительным аутентификатор пакета, поэтому прокси заново вычисляет аутентификатор.
Сообщение Access-Request
Пакеты Access-Request посылаются RADIUS-серверу и содержат информацию, используемую для определения разрешен ли пользователю доступ к данному NAS и какие сервисы доступны для данного пользователя.
Пакет Access-Request должен содержать атрибут User-Name. Он также должен содержать атрибуты NAS-IP-Address или NAS-Identifier.
Пакет Access-Request должен содержать либо атрибут User-Password, либо атрибут CHAP-Password, либо атрибут State. Пакет Access-Request не должен содержать одновременно и User-Password, и CHAP-Password. Возможно также добавление других типов аутентификационной информации и атрибутов, которые будут использоваться в пакете Access-Request вместо атрибутов User-Password или CHAP-Password.
Пакет Access-Request может содержать атрибут NAS-Port или NAS-Port-Type, а также дополнительные атрибуты, но при этом не требуется, чтобы сервер их как-то учитывал при создании ответа.
Если присутствует атрибут User-Password, он должен быть скрыт с использованием хэш-функции MD5.
Сообщение Access-Request
Пакеты Access-Request посылаются RADIUS-сервером и содержат информацию, необходимую для предоставления сервиса пользователю. Если все значения атрибута Attribute в Access-Request корректные, то RADIUS-сервер должен передать пакет с полем Code, установленным в 2 (Access-Request).
В пакете Access-Request поле Identifier должно соответствовать отправленному в Access-Request.
Сообщение Access-Reject
Если какое-либо значение Attributes не является допустимым, то RADIUS-сервер передает ответ с полем Code, установленным в 3 (Access-Reject). Он может включить один или несколько атрибутов Reply-Massage с текстовым сообщением, которое NAS может показать пользователю.
Сообщение Access-Challenge
Если RADIUS-сервер считает, что пользователю необходимо послать вызов, требующий ответа, то он отвечает пакетом с полем Code, установленным в 11 (Access-Challenge).
Поле Attribute может содержать один или несколько атрибутов Reply-Message или единственный атрибут State, либо не содержать ничего из перечисленного. Могут также быть включены следующие атрибуты: Vendor-Specific, Idle-Timeout, Session-Timeout и Proxy-State. Никакие другие атрибуты не должны включаться в Access-Challenge.
В полученном пакете Access-Challenge поле Identifier должно соответствовать тому, которое было указано в отправленном NAS Access-Request.
Если NAS не поддерживает обмен сообщениями Вызов/Ответ, он должен считать, что Access-Challenge соответствует Access-Reject.
Если NAS поддерживает обмен сообщениями Вызов/Ответ, то получение корректного ответа Access-Challenge означает, что должен быть послан новый запрос Access-Request. NAS может показать пользователю текстовое сообщение и выдать приглашение для ввода ответа. Затем он посылает исходный Access-Request с новым ID запроса и аутентификатором запроса, с атрибутом User-Password, в котором содержится ответ пользователя (в скрытом виде), а также в него добавляется атрибут State из Access-Challenge, если он там был. В Access-Request может присутствовать не более одного атрибута State.
NAS, поддерживающий РАР, может перенаправить Reply-Message клиенту и получить РАР-ответ, который затем он может использовать в качестве ответа пользователя. Если NAS это не поддерживает, он должен трактовать Access-Challenge как Access-Reject.
Атрибуты имеют следующий формат:
(рис 12.18) Формат атрибутов RADIUS
Поле Type
Поле Type имеет длину один октет. Возможные типы стандартизованы и перечислены в соответствующих RFC. Как RADIUS-сервер, так и клиент могут игнорировать атрибуты, тип которых они не знают.
Основные типы атрибутов следующие:
1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 11 12 Framed-MTU 13 Framed-Compression 14 Logon-IP-Host 15 Login-Service 16 Login-TCP-Port 17 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 -59 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port
Атрибут User-Name
Атрибут содержит имя аутентифицируемого пользователя. Он обязательно указывается в пакетах Access-Request.
Он может быть послан в пакете Access-Request, в этом случае клиент должен использовать это имя во всех пакетах Accounting-Request данной сессии. Если в Access-Request включен ServiceType=Rlogin и атрибут User-Name, NAS может использовать возвращаемое значение User-Name при выполнении сервиса Rlogin в UNIX-системах. Значением атрибута может быть текст, идентификатор сетевого доступа или DN прото-кола LDAP.
Атрибут User-Password
В данном атрибуте указывается пароль аутентифицируемого пользователя или введенная пользователем информация при получении пакета Access-Challenge. Атрибут используется только в пакетах Access-Request.
Пароль передается в скрытом виде. Первым делом к паролю добавляются символы заполнения, чтобы длина пароля стала кратной 16 октетам. Затем используется хэш-функция MD5, на вход которой подаются разделяемый секрет и аутентификатор запроса. Затем выполняется операция XOR этого значения с первыми 16 октетами пароля, полученное значение помещается в первые 16 октет поля String атрибута User-Password.
Если пароль длиннее 16 символов, второй раз используется хэш-функция MD5, на вход которой подается разделяемый секрет, за которым следует результат первого XOR. После этого выполняется XOR результата второго использования MD5 и вторых 16 октетов пароля. При необходимости данная операция повторяется нужное число раз.
Обозначим разделяемый секрет – S, псевдослучайный 128-битный аутентификатор запроса – RA. 16-октетные части пароля – р1, р2 и т.д.
b1 = MD5 (S + RA) c(1) = p1 xor b1 b2 = MD5 (S + c(1)) c(2) = p2 xor b2 String содержит с(1) + с(2) + ….., где + обозначает конкатенацию.
Атрибут СНАР-Password
В данном атрибуте указывается ответ на запрос, предоставленный протоколом СНАР, в ответ на Вызов (Challenge). Атрибут используется только в пакетах Access-Request.
Значение Вызова СНАР берется из атрибута CHAP-Challenge, если он присутствует в пакете, в противном случае используется поле Аутентификатора запроса.
Атрибут NAS-IP-Address
Данный атрибут определяет IP-адрес NAS, который запросил аутентификацию пользователя. Этот IP-адрес должен быть уникальным у данного RADIUS-сервера. NAS-IP-Address используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать либо NAS-IP-Address, либо NAS-Identifier.
Заметим, что NAS-IP-Address не должен использоваться для выбора разделяемого секрета, который используется для аутентификации запроса. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.
Атрибут NAS-Port
Атрибут определяет номер физического порта NAS, который аутентифицирует пользователя. Атрибут используется только в пакетах Access-Request. Заметим, что это порт физического соединения NAS, а не ТСР или UDP номер порта. В пакете Access-Request должен присутствовать либо NAS-Port, либо NAS-Port-Type.
Атрибут Service-Type
Данный атрибут определяет тип сервиса, который запросил пользователь, или тип сервиса, который будет предоставлен. Он может использоваться в пакетах Access-Request и Access-Accept. Не требуется, чтобы NAS мог реализовывать все типы сервисов, неизвестные или не поддерживаемые сервисы игнорируются и должны рассматриваться как Access-Reject.
Следующие типы сервисов могут использоваться в Access-Request. При использовании в Access-Request они могут рассматриваться как подсказка RADIUS-серверу какой тип сервиса требуется пользователю. Но при этом не требуется, чтобы сервер следовал этой подсказке.
| Login | Пользователь должен войти на хост. |
|---|---|
Framed | Для соединения с пользователем должен использоваться такой протокол, как РРР или SLIP. |
Callback Login | Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего пользователь должен быть снова подсоединен к хосту. |
Callback Framed | Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего должен начать выполняться такой протокол, как РРР или SLIP. |
Outbound | Пользователю должен быть предоставлен доступ к внешним устройствам. |
Administrative | Пользователю должен быть предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды. |
NAS prompt | Пользователю должно быть выдано приглашение для ввода непривилегированных команд NAS. |
Authenticate Only | Требуется только аутентификация, в Access-Request не должно возвращаться никакой авторизационной информации (обычно используется прокси-серверами, а не самим NAS). |
Callback NAS Prompt | Пользователь отсоединяется, осуществляется обратный вызов и пользователю выдается приглашение для выполнения непривилегированных команд NAS. |
Call Check | Используется NAS в пакете Access-Request для указания того, что вызов был получен, и что в ответ на вызов RADIUS-сервер должен послать сообщение Access-Accept или Access-Reject, обычно основываясь на атрибутах Called-Station-Id или Calling-Station-Id. Рекомендуется, чтобы Access-Request использовал Calling-Station-Id в качестве значения User-Name. |
Callback Administrative | Пользователь должен быть отсоединен, выполнен обратный вызов, затем предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды. |
Атрибут Framed-Protocol
Атрибут указывает внешний протокол, который используется для получения доступа. Может использоваться в пакетах Access-Request и Access-Accept.
Атрибут Framed-IP-Address
Данный атрибут определяет IP-адрес, который должен быть выдан пользователю. Атрибут может быть указан в пакетах Access-Accept. Он также может быть указан в пакете Access-Request в качестве предпочтительного IP-адреса, но сервер не обязан следовать этому указанию.
Атрибут Framed-IP-Netmask
Данный атрибут определяет IP-маску, которая будет сконфигурирована для пользователя при доступе в сеть. Атрибут может использоваться в пакетах Access-Accept. Он может также использоваться в пакете Access-Request для указания предпочтений NAS серверу, но сервер не обязан следовать этому.
Атрибут Framed-MTU
Данный атрибут определяет MTU, который будет сконфигурирован для пользователя, если об этом значении не ведутся переговоры каким-либо другим способом, например в РРР. Атрибут может использоваться в Access-Accept пакетах. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Framed-Compression
Данный атрибут определяет протокол сжатия. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Может быть послано несколько атрибутов, определяющих протокол сжатия. За использование корректного протокола сжатия отвечает NAS.
Атрибут Login-IP-Host
Данный атрибут определяет систему, к которой должен подсоединиться пользователь, если используется атрибут Login-Service. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Login-Service
Данный атрибут указывает сервис, который будет использоваться при соединении пользователя с хостом. Он может использоваться только в пакетах Acces-Accept.
Атрибут Login-TCP-Port
Данный атрибут определяет ТСР-порт, с которым будет устанавливать соединение пользователь, если присутствует атрибут Login-Service. Используется только в пакетах Access-Request.
Атрибут Reply-Message
Данный атрибут содержит текст, который будет показан пользователю. Может означать необходимость создания диалогового окна и определять приглашение пользователю перед следующей попыткой выполнения запроса на доступ Access-Request.
Если используется в пакете Access-Challenge, может содержать диалоговое сообщение, которое выдается пользователю для ввода ответа.
Если в сообщении содержится несколько Reply-Message, то они показываются в том же порядке, в каком расположены в пакете.
Атрибут Callback-Number
Атрибут определяет строку, которая будет использоваться при обратном вызове. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.
Атрибут Callback-Id
Данный атрибут определяет имя, которое будет использовано при обратном вызове и которое должно будет интерпретироваться NAS. Атрибут может использоваться в Access-Accept пакетах.
Атрибут Framed-Route
Данный атрибут предоставляет информацию маршрутизации, которая будет сконфигурирована для пользователя NAS. Атрибут используется в пакете Access-Accept, и может появиться там несколько раз.
Атрибут State
Атрибут посылается сервером клиенту в сообщении Access-Challenge и должен быть отправлен без изменения обратно клиентом серверу в новом Access-Request, который является ответом на запрос.
Данный атрибут может быть послан сервером клиенту в сообщении Access-Accept, в котором должен быть также атрибут Termination-Action со значением RADIUS-Request. Если NAS выполняет Termination-Action, посылая новый Access-Request при завершении текущей сессии, он должен включить без изменения атрибут State в этот Access-Request.
В любом случае клиент не должен интерпретировать данный атрибут локально. В пакете не может быть больше одного атрибута State. Использование данного атрибута во многом зависит от реализации.
Атрибут Class
Данный атрибут посылается сервером клиенту в Access-Accept, и должен отправляется без изменения клиентом серверу, хранящему учетные записи (аккаунтинг) как часть Accounting-Request пакета, если используется аккаунтинг. Клиент не должен интерпретировать данный атрибут локально.
Атрибут Vendor-Specific
Данный атрибут позволяет производителям поддерживать свои собственные атрибуты. Данный атрибут не должен влиять на операции протокола RADIUS.
Сервер, который не знает, как интерпретировать относящуюся к производителю информацию, должен игнорировать данный атрибут.
Атрибут Session-Timeout
Данный атрибут устанавливает максимальное время (в секундах) перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.
Атрибут Idle-Timeout
Данный атрибут устанавливает максимально допустимое число секунд простоя соединения перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.
Атрибут Termination-Action
Данный атрибут определяет действие, которое должен выполнить NAS при завершении определенного сервиса. Используется только в пакетах Access-Accept.
Атрибут Called-Station-Id
Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, который использовал пользователь. Заметим, что это может отличаться от номера телефона, с которого пришел вызов. Данный атрибут используется только в пакетах Access-Request.
Атрибут Calling-Station-Id
Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, с которого пришел вызов. Атрибут используется только в пакетах Access-Request.
Атрибут NAS-Identifier
Данный атрибут содержит строку, идентифицирующую NAS, который создал исходный Access-Request. Атрибут используется только в пакетах Access-Request. Либо NAS-IP-Address, либо NAS-Identifier должен присутствовать в пакете Access-Request.
Заметим, что NAS-Identifier не должен использоваться для выбора разделяемого секрета, аутентифицирующего запрос. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.
Атрибут Proxy-State
Данный атрибут может быть послан прокси-сервером другому серверу при перенаправлении Access-Request. Атрибут должен быть возвращен без изменения в Access-Accept, Access-Reject или Access-Challenge. Когда прокси-сервер получает ответ на свой запрос, он должен удалить свой собственный Proxy-State (последний Proxy-State в пакете) перед тем, как перенаправить ответ к NAS.
Если атрибут Proxy-State добавляется в пакет, то он должен быть добавлен после всех имеющихся атрибутов Proxy-State.
Содержимое всех других атрибутов Proxy-State, отличных от добавляемого, должно рассматриваться как неформатированные данные и не должно влиять на операции протокола.
Использование атрибута Proxy-State зависит от протокола.
Атрибут CHAP-Challenge
Данный атрибут содержит CHAP Challenge, посылаемый NAS. Он используется только в Access-Request пакетах.
Если значение вызова СНАР имеет длину в 16 октетов, то оно может быть размещено в поле аутентификатора запроса, а не в данном атрибуте.
Атрибут NAS-Port-Type
Данный атрибут определяет тип физического порта NAS, с которого выполняется аутентификация пользователя. Атрибут может использоваться вместо или в дополнение к атрибуту NAS-Port. Данный атрибут используется только в Access-Request пакетах. Если NAS различает свои порты, то в пакете Access-Request должен присутствовать либо атрибут NAS-Port, либо атрибут NAS-Port-Type, либо оба эти атрибута.
Атрибут Port-Limit
Данный атрибут устанавливает максимальное количество портов, которое может предоставить NAS своим пользователям. Атрибут может быть послан сервером клиенту в пакете Access-Accept. Предполагается, что он будет использоваться вместе с многоканальным РРР или в аналогичной технологии. Он также может быть послан NAS к серверу в качестве предпочтения, какое количество портов может использоваться, но сервер может игнорировать это.
Атрибуты RADIUS, специфичные для ПО Microsoft
Рассмотрим атрибуты, которые могут быть переданы в одном или более атрибутах RADIUS, тип которых есть Vendor-Specific. В одном Vendor-Specific атрибуте могут быть переданы несколько атрибутов; в этом случае эти атрибуты пакетируются в виде последовательности троек Vendor-Type/Vendor-Length/Value, которые следуют за начальными полями Type, Length и Vendor-Id. Поле Vendor-ID должно быть установлено в десятичное значение 311 (Microsoft).
Атрибуты для поддержки MS-CHAP V1
Microsoft разработала протокол MS-CHAP для аутентификации удаленных рабочих станций Windows, обеспечивая функциональность, аналогичную той, к которой привыкли пользователи сети. Где это возможно, MS-CHAP аналогичен стандартному СНАР. Основная разница в следующем:
Algorithm) в аутентификационном протоколе.Response протокола MS-CHAP имеет формат, совместимый с Microsoft Windows и сетевым ПО Microsoft. Формат MS-CHAP не требует, чтобы аутентифицирующая сторона хранила пароли в явном виде или в обратимом зашифрованном виде. Message пакета Failure.Атрибуты RADIUS отражают эти отличия.
Атрибут MS-CHAP-Challenge
Данный атрибут содержит вызов, посылаемый NAS к пользователю MS-CHAP. Он может использоваться в пакетах Access-Request и Access-Challenge.
Атрибут MS-CHAP-Response
Данный атрибут содержит ответ, передаваемый пользователем в ответ на вызов. Атрибут используется только в пакетах Access-Request.
Атрибут MS-CHAP-Domain
Атрибут MS-CHAP-Domain определяет Window-домен, в котором пользователь был аутентифицирован. Данный атрибут может быть включен в пакеты Access-Accept и Accounting-Request.
Атрибут MS-CHAP-Error
Атрибут MS-CHAP-Error содержит информацию об ошибке, относящуюся к предыдущему MS-CHAP-обмену. Данный атрибут может использоваться в обменах как MS-CHAP-V1, так и MS-CHAP-V2. Данный атрибут используется только в пакетах Access-Reject.
Атрибут MS-CHAP-CPW-1
Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут может использоваться только в пакетах Access-Request и должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP не меньше 2.
Атрибут MS-CHAP-CPW-2
Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут используется только в пакетах Access-Request, и включается только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль истек, и версия MS-CHAP равна 2.
Атрибут MS-CHAP-LM-Enc-PW
Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, пароль разделяется на несколько частей и передается в нескольких атрибутах. В атрибут включается последовательный номер (2 октета), чтобы обеспечить возможность правильной сборки фрагментов пароля.
Атрибут используется только в пакетах Access-Request совместно с атрибутом MS-CHAP-CPW-2. Атрибут должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP равна 2 или более.
Атрибут MS-CHAP-NT-Enc-PW
Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля Windows. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, то пароль разделяется на несколько частей и передается в нескольких атрибутах. Последовательный номер включается в атрибут, чтобы обеспечить сборку фрагментов пароля.
Данный атрибут используется только в пакете Access-Request совместно с атрибутами MS-CHAP-CPW-2 и MS-CHAP-CPW. Он включает только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия протокола MS-СНАР равна 2 или более.
Атрибуты для поддержки MS-CHAP V2
Рассмотрим RADIUS-атрибуты, необходимые для поддержки второй версии протокола MS-CHAP. Протокол MS-CHAP-V2 аналогичен, но не совместим с протоколом MS-CHAP-V1. Некоторые поля удалены или используются по-другому. Протокол MS-CHAP-V2 максимально согласован как с протоколом MS-CHAP-V1, так и со стандартным протоколом СНАР.
Кратко различия между протоколами MS-CHAP-V2 и MS-CHAP-V1 следующие:
Response и аутентифицируя ответ в пакете Success.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 для доставки информации об учетных записях от NAS к серверу учетных записей RADIUS.
(рис 12.19) Последовательность пакетов при выполнении аккаунтинга
Если клиент сконфигурирован для использования RADIUS-аккаунтинга, то перед началом получения сервиса создается пакет Accounting Start, описывающий тип сервиса и пользователя, которому необходим этот сервис. Эта информация посылается к серверу аккаунтинга RADIUS.
(рис 12.20) Пример первого пакета Accounting Start RADIUS
Затем этот сервер присылает подтверждение, что пакет был получен.
После завершения получения сервиса NAS создает пакет Accounting Stop, в котором описан тип полученного сервиса и возможно различная статистическая информация, такая как затраченное время, количество входящего и исходящего трафика. Этот пакет посылается к серверу аккаунтинга RADIUS, который присылает подтверждение, что пакет был получен.
Клиент посылает пакеты Accounting-Request до тех пор, пока не получит тем или иным способом подтверждения. После того, как клиент не получил подтверждения в течение определенного времени, он может перенаправить запрос альтернативному серверу.
Сервер аккаунтинга RADIUS может делать запросы другим серверам, в этом случае он действует как клиент.
Аккаунтинг прокси функционирует аналогично аутентификационному прокси.
(рис 12.21) Топология сети при использовании прокси-сервера RADIUS
Proxy-State (если требуется) после всех остальных атрибутов Proxy-State, изменяет Аутентификатор запроса и перенаправляет запрос удаленному серверу.Proxy-State, а также помещает их в пакет ответа и посылает перенаправляющему серверу.Перенаправляющий сервер не должен модифицировать существующие в пакете атрибуты 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 могут быть включена атрибуты разных типов. Атрибуты некоторых типов могут быть включены несколько раз. В этом случае порядок атрибутов одного и того же типа фиксирован.
Тип пакета RADIUS определяется полем Code.
Пакет Accounting-Request
Пакеты Accounting-Request посылаются от клиента (обычно NAS или прокси) к аккаунтинг-серверу RADIUS и содержат информацию, используемую для авторизации доступа к сервису, предоставляемого пользователю. Клиент передает RADIUS-пакет с полем Code, установленным в 4 (Accounting-Request).
При получении Accounting-Request сервер должен передать ответ Accounting-Response, если он успешно записал пакет аккаунтинга, и не должен передавать никакого ответа, если произошел сбой при записи пакета аккаунтинга.
Любой атрибут, который используется в пакетах Access-Request и Access-Accept, может использоваться и в пакете Accounting-Request, за исключением следующих атрибутов, которые не должны присутствовать в пакетах Accounting-Request: User-Password, CHAP-Password, Reply-Message, State. В пакете Accounting-Request должен присутствовать атрибуты либо NAS-IP-Address, либо NAS-Identifier. Пакет должен содержать NAS-Port, или NAS-Port-Type, или оба атрибута, если только в сервисе не определен порт, или NAS не различает свои порты.
Если пакет Accounting-Request содержит Framed-IP-Address, то атрибут должен содержать IP-адрес пользователя. Если Access-Request использует специальные значения для Framed-IP-Address, которые означают, что NAS должен назначить IP-адрес пользователю или вести о нем переговоры, то Framed-IP-Address (если есть) в Accounting-Request должен содержать реальный IP-адрес, который назначен или о котором договорились.
Пакет Accounting-Response
Пакеты Accounting-Response посылаются сервером RADIUS клиенту как подтверждение того, что Accounting-Request был получен и успешно записан. Если Accounting-Request был успешно записан, то аккаунинг сервер должен передать пакет с полем Code, установленным в 5 (Accounting-Response). При получении Accounting-Response клиент проверяет, что поле Identifier соответствует отправленному в запросе. Аутентификатор ответа должен содержать корректное значение. Недействительный пакет молча отбрасывается.
Атрибуты отражают детали аутентификации, авторизации и аккаунтинга в запросе и ответе.
Некоторые атрибуты могут быть включены несколько раз. Результат такого включения зависит от атрибута.
Атрибуты имеют следующий формат.
(рис 12.23) Формат RADIUS-атрибутов
Поле Type
Поле Type имеет длину один октет. Основные типы атрибутов следующие:
40 Acct-Status-Type 41 Acct-Delay-Time 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause 50 Acct-Multi-Session-Id 51 Acct-Link-Count
Поле Length
Поле Length имеет длину один октет и определяет длину данного атрибута, включая поля Type, Length и Value. Если в Accounting-Request получен атрибут с неправильным значением поля Length, то весь пакет отбрасывается.
Поле Value
Поле Value состоит из нуля или более октетов и содержит информацию, зависящую от атрибута. Формат и длина поля Value зависят от типа и длины данного атрибута.
Атрибут Acct-Status-Type
Атрибут указывает, маркирует ли данный пакет Accounting-Request начало пользовательского сервиса (Start) или конец (Stop).
Он может использоваться клиентом для маркировки начала аккаунтинга (например, после перезагрузки), указав специальное значение атрибута Accounting-On и пометив конец аккаунтинга (например, перед плановым перезапуском) специальным значением атрибута Accounting-Off.
Атрибут Acct-Delay-Time
Атрибут указывает сколько секунд клиент пытается послать данную запись, и может вычитаться из времени получения сервером пакета Accounting-Request, т.е. время передачи по сети будет игнорироваться.
Атрибут Acct-Input-Octets
Атрибут определяет, сколько октетов было получено с порта, на котором был предоставлен сервис, и может присутствовать только в пакетах Accounting-Request, в которых Acct-Status-Type установлен в Stop.
Атрибут Acct-Output-Octets
Атрибут определяет, сколько октетов было послано на порт, на котором выполняется данный сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Session-Id
Атрибут содержит уникальный идентификатор, который используется для нахождения соответствующих пар старт- и стоп-записей в лог-файле. Старт- и стоп-записи для данной сессии должны иметь один и тот же Acct-Session-Id. Пакет Access-Request может содержать атрибут Acct-Session-Id. Если он содержит этот атрибут, то NAS должен использовать тот же самый Acct-Session-Id во всех пакетах Accounting-Request, относящихся к данной сессии.
Атрибут Acct-Authentic
Атрибут может быть включен в пакет Accounting-Request для указания того, был ли пользователь аутентифицирован самим NAS или использовался протокол RADIUS или другой протокол удаленной аутентификации. Для пользователей, которые получили сервис без выполнения аутентификации, не должны создаваться записи аккаунтинга.
Атрибут Acct-Session-Time
Атрибут указывает, сколько секунд пользователь получал сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Input-Packets
Атрибут указывает, сколько пакетов было получено с порта в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Output-Packets
Атрибут указывает, сколько пакетов было послано на порт в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Terminate-Cause
Атрибут указывает, как сессия была завершена, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.
Атрибут Acct-Multi-Session-Id
Данный атрибут является уникальным Accounting ID, что позволяет легко объединить в лог-файле несколько взаимосвязанных сессий. Каждая сессия имеет уникальный атрибут Acct-Session-Id, но взаимосвязанные сессии имеют один и тот же атрибут Acct-Link-Count.
Атрибут Acct-Link-Count
Атрибут содержит количество взаимосвязанных (с помощью атрибута Acct-Link-Count) сессий. NAS может включить атрибут Acct-Link-Count в любой пакет Accounting-Request, который связан с несколькими сессиями.
Это дает возможность аккаунтинг-серверу объединить все записи в логах, относящиеся к взаимосвязанным сессиям.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.