Протоколы ААА: RADIUS и Diameter. Книга 9 Б. С. Гольдштейн, В. С. Елагин, Ю. Л. Сенченко

У нас вы можете скачать книгу Протоколы ААА: RADIUS и Diameter. Книга 9 Б. С. Гольдштейн, В. С. Елагин, Ю. Л. Сенченко в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

Основные положения 39 2. Базовая схема работы протокола 45 2. Формат соощения 54 2. Типы пакетов 57 2. Протокол Diameter 3. Предпосылки появления нового протокола ААА 3. Защита уровня передачи 3. Надежный транспорт 3. Поддержка функций агентов 3. Поддержка сообщений, инициируемых сервером 3. Согласование возможностей 3. Динамическое обнаружение узлов 3. Поддержка роуминга 3. Расширяемость протокола 3. Спецификации Diameter 3. Основы базового протокола Diameter 3.

Идентификаторы приложений 3. Соединения и сессии 3. Таблица узлов 3. Таблица маршрутизации по административным доменам Realm 3. Роль Diameter-агентов 3. Заголовок сообщения Diameter 3. Структура заголовка 3. Коды команд 3. Пары атрибут - значение базового протокола Diameter 3. Заголовок AVP 3. Базовые форматы данных пар атрибут-значение 3.

Производные форматы данных AVP 3. Групповые AVP 3. Узлы Diameter 3. Соединения между узлами 3. Обнаружение узлов 3. Разрыв соединений 3. Обнаружение проблем траспортного уровня 3. Обработка сообщений Diameter 3. Маршрутизация запросов Diameter 3. Обработка ответов Diameter 3. Обработка ошибок 3. Сессии пользователей Diameter 3. Завершение сессий 3. Принудительное завершение сессий 3. Сообщения протокола учета 3. Записи учета 3. Сопоставление записей учета Приложение кредитного контроля Diameter 4.

Предоплата инфокоммуникационных услуг 4 2. Архитектура кредитного контроля 4. Сообщения кредитного контроля 4. Credit - Control - Request 4. Credit - Control - Answer 4. Обзор приложения кредитного контроля Diameter 4. Передача специфической для услуги информации 4. Сессионный кредитный контроль 4. Основные принципы 4. Начальный запрос 4.

Промежуточный запрос 4. Финальный запрос 4. Реавторизация кредита, инициированная сервером 4. Например, учет использования ресурса с целью выставления счета не имеет смысла, если субъект, которому предоставляется услуга, не может быть достоверно идентифицирован, то есть аутентифицирован. После того как субъект установлен, следует определить, доступ к каким ресурсам и на каких условиях параметры качества обслуживания, виды услуг, виды носителей может быть ему предоставлен.

Процедура авторизации позволяет применять правила доступа к ресурсам в соответствии с соглашением с Оператором. Выставление счетов за услуги в большинстве случаев основывается на информации о количестве и типе потребленных абонентом ресурсов и длительности этого потребления. Сбор такого рода информации осуществляется в рамках процедур учета. Главной телекоммуникационной услугой на протяжении большей части XX века являлась традиционная телефонная связь, местная, междугородная и международная.

Таким образом, аутентификация при доступе к сети выполнялась непосредственно подключением на кроссе АТС, а счет за услуги выставлялся владельцу линии. Авторизация как таковая также была элементарна, так как абоненту была доступна только услуга телефонной связи. Если абонент не оплачивал услуги связи в соответствии с условиями договора, его линия физически блокировалась. Учет длительности разговоров осуществлялся первоначально только на междугородных станциях АМТС с помощью процедуры АОН, а несколько позже и на АТС тоже с помощью дополнительно устанавливаемого оборудования учета стоимости.

Аутентификация, как и раньше, производилась на основе анализа номера абонентской линии, по которой поступал вызов. Однако, в отличие от предшественников, в цифровых АТС действовала полноценная процедура авторизации. Предоставление дополнительных услуг, таких как переадресация или автоматическая побудка, требовало создания профиля абонента, в котором фиксировались правила доступа к подобным услугам.

При каждом запросе система обращалась к профилю и выполняла проверку прав абонента, и дальнейшее обслуживание зависело от результатов проверки. Появилось и встроенное программное обеспечение учета стоимости услуг связи, являющееся неотъемлемой частью программного обеспечения цифровых АТС. Ситуация радикально изменилась с появлением Интернет-технологий.

Первым популярным способом доступа в Интернет стал Dial-Up коммутируемый доступ через модем по двухпроводной телефонной линии. Заключая договор с Интернет-провайдером, абонент получал логин и пароль, по которым система могла аутентифицировать его запрос подключения к сети.

Чуть позже, в середине года, спецификации этого протокола были пересмотрены в RFC , а затем еще раз в году в RFC [67]. Выставление счетов пользователям выполнялось на основе информации о продолжительности доступа к сети и объема данных, переданных в рамках Интернет-сессии. Эту информацию было целесообразно накапливать централизованно, что потребовало разработки протокола передачи такого рода информации от NAS на сервер учета.

Согласно этому протоколу, в момент начала сессии NAS отправляет на сервер учета сообщение, сигнализирующее о необходимости начала отсчета времени.

В конце сессии NAS отправляет еще одно сообщение, уведомляющее об окончании сессии и об объеме переданной информации, предоставляя серверу учета необходимые данные для формирования счетов. Эволюция сетей связи, выражающаяся в усложнении сетевого и пользовательского оборудования, в увеличении количества услуг, в новом уровне угроз защите информации, а также в необходимости обеспечения согласованного качества обслуживания, привела к тому, что разработанный без учета всех этих факторов протокол RADIUS в силу своих ограничений стал во многих случаях неприменимым для решения задач ААА в рамках новых инфокоммуникационных реалий.

Одним из отличий протокола Diameter от RADIUS является то, что стандартизация практических приложений, работающих на основе базового протокола Diameter, ведется в рамках отдельных RFC, каждый из которых, по сути, представляет собой отдельный стандарт.

Глава 4 посвящена рассмотрению приложения кредитного контроля Diameter [53] одному из наиболее распространенных на сегодня Diameter-приложений, которое позволяет на основе стандартизированных механизмов выполнять контроль расходования ресурсов мультисервисной сети в режиме реального времени по принципу предварительного резервирования. Де-факто, последователем протокола RADIUS является не базовый протокол Diameter, а рассматриваемое в главе 5 Diameter-приложение сервера доступа к сети [38], так как именно оно описывает процедуры взаимодействия сервера доступа к сети NAS и ААА-сервера при обслуживании пользователей, запрашивающих доступ к сетевым ресурсам.

В силу того что, по понятным причинам, единовременный переход на новый ААА-протокол невозможен, большое внимание в главе 5 уделяется задачам преобразования протоколов RADIUS и Diameter для обеспечения совместимости существующего и нового оборудования. Традиционная для книг этой серии глава 6 охватывает вопросы реализации и тестирования протоколов ААА, а в главе 7 рассматриваются вопросы реализации законного перехвата сообщений СОРМ которым посвящена отдельная книга этой же серии [8] для протоколов RADIUS и Diameter.

Обсуждение материала, содержащегося в главах , требует согласования понятийного аппарата и краткого обзора процедур ААА без привязки к конкретной реализации протокола.

Основные определения и описание обобщенной ААА-архитектуры приводятся в главе 1. Бонч-Бруевича, коллегам из отдела системных исследований НИИТС, специалистам сертификационного центра ЛО ЦНИИС и инженерам ведущих зарубежных компаний, с которыми изучались, обсуждались и тестировались спецификации протоколов, рассматриваемых в этой книге.

Все три составляющие архитектуры ААА уже давно укрепились в современных телекоммуникационных сетях. Аутентификация, авторизация и учет в том или ином виде всегда сопровождают каждую попытку доступа к любым инфокоммуникационным услугам, будь то доступ в Интернет, традиционный телефонный вызов ТфОП, роуминг в сетях мобильной связи, заказ VAS, etc.

Реализация функций ААА в разных сетях связи принимает разнообразные формы. Конвергенция вышеупомянутых сетей и услуг связи побудила IETF, начиная с года, приступить к выпуску ряда документов [51], [18], [27], [9], [32] и др. Представлению основных концепций и описанию базовой архитектуры ААА и посвящена эта глава.

Основные идеи реализации архитектуры построения систем аутентификации, авторизации и учета ААА представлены в документе RFC Перед тем как перейти непосредственно к рассмотрению протоколов ААА, приведем определения терминов, входящих в аббревиатуру ААА, согласно RFC Как уже упоминалось во введении, Аутентификация это верификация идентификационной информации, предъявляемой в форме имени из обоюдно согласованного пространства имен.

Авторизация это выяснение того, может ли. Учет это сбор информации об использовании ресурса с целью анализа, контроля, выставления счетов или распределения стоимости Аутентификация Перефразируя приведенное выше определение, можно сказать, что аутентификация это процедура, состоящая из двух операций.

Первая операция заключается в предоставлении аутентифицируемой стороной некой информации, которая позволяет аутентифицирующей стороне выполнить проверку достоверности переданной идентификационной информации. Вторая операция представляет собой проверку, выполняемую аутентифицирующей стороной. Бытовым примером процедуры аутентификации является предъявление паспорта при входе в вагон поезда дальнего следования.

Железнодорожный билет содержит имя и фамилию человека, который имеет право проезда по данному билету из пункта А в пункт Б. Для того чтобы пропустить пассажира в вагон, проводник должен быть уверен, что предъявитель билета действительно является тем человеком, имя которого указано в билете. Фактически, имя и фамилия в билете являются идентификационной информацией пассажира, требующей подтверждения, аутентифицируемой стороной выступает потенциальный пассажир, а аутентифицирующей проводник вагона поезда.

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

Для корректности изложения следует добавить, что идентификационная информация, подлежащая верификации, должна обладать свойством уникальности, чтобы процедура аутентификации имела смысл.

Возвращаясь к примеру с железнодорожным билетом, предположим, что в билете указан пассажир Сергей Кузнецов или Иван Смирнов. Такая совокупность имени и фамилии как, впрочем, значительное число сочетаний имен и фамилий в большой стране не является уникальной, таким образом, процедура аутентификации с предъявлением пас-.

Для этого помимо имени и фамилии в билеты добавляется номер паспорта, который обеспечивает уникальность идентификации пассажира. Выделяют следующие виды аутентификации: Приведенный пример с железнодорожным билетом можно отнести к категории аутентификации клиента, когда обслуживающая система проверяет аутентичность пользователя, желающего получить доступ к ее ресурсам.

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

В мобильной сети аутентификация устройства выполняется на основе карты SIM, вставляемой в мобильный телефон. Проблема в данном случае состоит в том, что аутентификация устройства не позволяет провести аутентификацию пользователя. Если каким-либо образом подключенный к сети телефон попадет в чужие руки, ресурсы мобильной сети станут автоматически доступны новому обладателю мобильного устройства, так как он не будет отличим для сети от его предыдущего владельца в силу отсутствия аутентификации пользователя.

Незаконное использование может продолжаться до тех пор, пока владелец не заявит администрации сети об утере мобильного устройства и необходимости его отключения. Отметим, что для выполнения такого рода операции по телефону пользователю придется пройти аутентификацию, чтобы сотрудники Оператора убедились в его праве на отключение соответствующего устройства от сети. Аутентификация в данном случае будет проведена в виде ответа на секретный вопрос. Фактически, провайдеру безразлично, кто из обитателей квартиры пользуется Интернет-доступом, главное, чтобы MAC-адрес устройства совпадал с допустимым для данного кабельного подключения.

Аутентификация сообщений в наши дни является не менее серьезной задачей, нежели аутентификация клиента. К примеру, при удаленной торговле на бирже важной является не только аутентичность клиента, пытающегося продать или купить акции, пользуясь ресурсами своего счета, но и аутентичность команды, которую передает данный клиент по сети. Если на пути следования запроса от клиента к электронной бирже сообщение передается в открытом виде, злоумышленник может поменять команду клиента на выгодную для себя или невыгодную для клиента.

Таким образом, клиенту будет нанесен ущерб в виде потери времени или денег за счет покупки не тех бумаг, которые интересовали его в момент совершения сделки. Более того, операция может быть изменена на противоположную, и бумаги будут не куплены, а проданы.

Для обеспечения целостности сообщения отправитель выполняет операцию хеширования передаваемых данных и некоторого секретного слова, известного только ему и получателю сообщения бирже , после чего передает сообщение, добавляя в его конец получившуюся на выходе хэш-функции последовательность.

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

Взаимная аутентификация это аутентификация не только сервером клиента, но и клиентом сервера, либо, в конфигурации peer-to-peer, взаимная аутентификация взаимодействующих узлов. Взаимная аутентификация необходима в окружении, где клиент не может доверять идентификатору сервера, либо равноправный узел не может доверять идентификатору равноправного узла. Примером взаимной аутентификации является аутентификация пользователем сайта, который требует введения логина и пароля для аутентификации пользователя.

В данном примере аутентификация будет выполнена с помощью подписанного сертификата, который пользователь принимает от сайта перед тем, как выполнить аутентификацию.

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

Примером двусторонней аутентификации является аутентификация при удаленном доступе к оборудованию например, по протоколу SSH. При поступлении запроса аутентификации аутентифицирующая сторона выполняет аутентификацию локально, на основе хранящейся в данном узле информации.

Для выполнения аутентификации при удаленном доступе к серверу взаимодействие с третьей стороной не требуется, так как обычно параметры клиентов конфигурируются непосредственно на аутентифицирующем узле Трехсторонняя модель Двусторонняя модель аутентификации не может лежать в основе больших распределенных сетей для выполнения аутентификации в этом случае каждый элемент такой сети должен обладать всей полнотой информации о пользователях, для того чтобы иметь возможность выполнить аутентификацию любого подключающегося клиента.

Например, в двусторонней модели сеть Wi-Fi хотспотов должна состоять из точек доступа, каждая из которых хранит учетные записи всех пользователей в сети. Понятно, что данная модель является менее эффективной, чем трехсторонняя, при которой точки доступа из приведенного примера будут не более чем передатчиками аутентификационной информации к единому хранилищу, которое содержит всю необходимую для аутентификации любого пользователя информацию.

Сервер доступа к сети получает от пользователя информацию аутентификации и передает ее на ААА-сервер для выполнения процедуры аутентификации; с ААА-сервер элемент, содержащий информацию, достаточную для проведения аутентификации пользователя.

Он выполняет проверку учетных данных пользователя по запросу сервера доступа к сети. Если запрос завершается успешно, то есть пользователь действительно является тем, за кого себя выдает, АААсервер дает серверу доступа к сети команду предоставить пользователю сетевой доступ в соответствии с его полномочиями которые определяются при процедуре авторизации, речь о которой в следующем параграфе.

Пользователь не является ААА-клиентом. В первом случае обмен данными происходит в большинстве случаев до получения IP-адреса так как IP-адрес является ресурсом сети, доступ к которому может быть предоставлен только после аутентификации и авторизации пользователя. Кроме того, передача данных на сервер сетевого доступа выполняется в режиме без посредников, так как точка подключения к сети, как правило, является сервером следующего перехода по отношению к поставщику аутентификационной информации и не требует каких-либо посредников для передачи информации.

Совокупность этих факторов является причиной того, что протокол передачи аутентификационной информации до сервера сетевого доступа работает поверх функций второго уровня семиуровневой модели OSI. Именно информационный обмен на данном участке лежит в зоне ответственности ААА-протоколов предмета, которому посвящена большая часть настоящего издания. Тем не менее, авторизация имеет важное значение в обеспечении функций ААА, поэтому ей посвящены отдельные RFC [34], [33], [35], описывающие, соответственно, инфраструктуру авторизации, примеры приложений авторизации и требования к авторизации.

Как следует из определения, приведенного в начале главы, авторизация это определение полномочий доступа к некоторым ресурсам. Аутентификация позволяет только убедиться, что претендующее на ресурсы лицо или устройство является именно тем, за кого себя выдает.

После того как личность претендующего достоверно установлена, начинается процесс авторизации, то есть определения, какая часть ресурсов может быть предоставлена данному пользователю. Фактически, авторизация имеет место в любой сети, а если рассматривать шире, в процессе получения доступа к любой услуге, в рамках которой пользователю предлагаются как минимум два вида ресурсов.

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

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

Как следует из предисловия к RFC , утвержденной в году, целью создания инфраструктуры, представленной в этой RFC, было введение единой архитектуры и терминологии, подходящих для обсуждения большого числа приложений. Эта организация проверяет, имеет ли данный пользователь право доступа к требуемому ресурсу или услуге. Этот элемент является хранилищем информации, которая может быть неизвестна сервис-провайдеру к примеру, лимит средств на счете ; ААА-сервер сервис-провайдера, который авторизует доступ к услуге на основе соглашения с домашней организацией пользователя; оборудование услуги, которое непосредственно предоставляет услугу.

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

Более сложным случаем является роуминг, когда пользователь уходит из домашнего домена к сервис-провайдеру, имеющему свой собственный ААА-сервер. Рассмотрим возможные последовательности обмена сообщениями авторизации в случаях одного домена, после чего рассмотрим случай роуминга Обмен сообщениями внутри одного домена Агентская последовательность В агентской последовательности ААА-сервер сервис-провайдера выступает в качестве агента между пользователем и услугой.

ААА-сервер получает запрос пользователя и перенаправляет информацию авторизации вместе с информацией конфигурации на оборудование услуги. В модели агентской последовательности на рис. ААА-сервер отправляет запрос к оборудованию услуги, и оборудование услуги организует ее предоставление шаг 2. ААА-сервер отвечает пользователю, что услуга подключена и тот может использоваться ею шаг 4.

Пользователь отправляет запрос на оборудование услуги шаг 1 , которое перенаправляет его на ААА-сервер сервис-провайдера шаг 2.

ААА-сервер выполняет обработку запроса и передает соответствующий ответ на оборудование услуги шаг 3 , которое устанавливает услугу и уведомляет пользователя о готовности шаг 4.

Пользователь прикладывает к запросу, отправляемому на оборудование услуги, полученный билет шаг 3. Оборудование услуги на основе этого билета выполняет верификацию запроса и отвечает подтверждением пользователю шаг 4. Сервис-провайдер Пользователь 1 2 AAA-сервер 3 4 Оборудование услуги Рис Последовательность с билетом Обмен сообщениями между разными доменами роуминг Во многих случаях организация, аутентифицирующая и авторизующая пользователя, и организация, предоставляющая услугу, не совпадают.

Данная ситуация рассматривается как роуминг, когда пользователь домашней сети уходит в гостевую сеть и запрашивает услугу оттуда. В роуминговых сценариях применяются те же последовательности обмена сообщениями, что и в сценариях с одним доменом агентская последовательность, последовательность с опросом и последовательность с билетом. Для простоты изображения сгруппируем ААА-сервер и оборудование услуги сервис-провайдера в один логический элемент. Описанные последовательности для случая роуминга представлены на рис.

Примером может служить пользователь, требующий обеспечения определенного уровня качества обслуживания на пути сообщений, пересекающих сети нескольких сервис-провайдеров Интернет. Услуга, предоставляемая более чем одним сервиспровайдером, считается распределенной.

Следует отметить, что последовательности обмена сообщениями при обработке запроса первой и второй организациями могут различаться. К примеру, первая может использовать последовательность с опросом, в то время как вторая агентскую последовательность рис. Новым элементом на этом изображении является Суперорганизация, предназначение которой заключается в выполнении аутентификации и авторизации пользователей для организаций, предоставляющих услуги.

Фактически, эта организация является брокером, или продавцом услуг всех взаимодействующих организаций. Понятие учета является широким и охватывает несколько видов деятельности, причем различные стандартизующие структуры определяют его по-разному. IETF, к примеру, определяет учет как сбор информации об использовании ресурса с целью анализа, контроля, выставления счетов или распределения стоимости.

Кроме того, распределение стоимости является в большей степени организационной, а не технической задачей, в то время как сбор информации об использовании ресурса является преимущественно технической и стандартизируемой задачей. Несмотря на расхождения некоторых других относящихся к учету определений, 3GPP и IETF, тем не менее, одинаково определяют стандарты для выполнения сходных операций, что естественно в условиях конвергенции сетей и использования одного и того же набора протоколов для выполнения сходных задач.

RFC , специфицирующая основные понятия процедур учета, а также формулирующая определения основных относящихся к учету терминов, была утверждена IETF в году. Целью ее создания была выработка универсальных требований к приложениям учета, которые можно было бы использовать при последующем создании универсального протокола учета и разработке универсальных механизмов обеспечения защиты информации.

Биллинг совокупность действий, нужных для приготовления счета. Аудит акт верификации корректности этой совокупности действий. Промежуточный учет данные об использовании ресурсов во время сессии пользователя. Это может быть полезно в случае перезагрузки устройства или возникновения сетевой проблемы, которая препятствует генерации итоговой записи учета по всей сессии.

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

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