Спецификация Internet-сообщества Обобщенный прикладной программный интерфейс службы безопасности

Основные понятия

Обобщенный прикладной программный интерфейс службы безопасности содержит следующие основные понятия:

Удостоверение - это структура данных, позволяющая ее владельцу доказать партнеру по общению или третьей стороне, что он (владелец) является именно тем, за кого себя выдает. Таким образом, в GSS-API удостоверения выступают как средство аутентификации.

Естественно, что служба безопасности (например, Kerberos) совместно с операционной системой должны обеспечить защиту удостоверений от несанкционированного использования и/или изменения. Процессам, действующим от имени пользователей, не предоставляется прямого доступа к удостоверениям. Вместо этого при необходимости процессы снабжаются дескрипторами удостоверений, которые не содержат секретной информации и не нуждаются в защите. Нет смысла воровать дескрипторы, поскольку их интерпретация для разных процессов-предъявителей будет различной.

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

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

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

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

Интерфейс GSS-API не зависит от используемых коммуникационных протоколов, поэтому формирование контекста безопасности никак не связано с установлением соединения в сетевом смысле. Более того, для GSS-API безразлично, какой протокол используется - с установлением соединения или без такового. Организация потока сообщений, а также выделение из входного потока данных, генерируемых в рамках GSS-API, - обязанность прикладных систем.

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

Перед началом общения с удаленным партнером приложение обращается к интерфейсу GSS-API с просьбой инициализировать контекст. В ответ возвращается контекстный токен безопасности, который приложение обязано переслать партнеру. Тот, получив токен, передает его локальному экземпляру GSS-API для проверки подлинности инициатора и продолжения (обычно - завершения) формирования контекста.

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

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

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

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

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

Если токены являются структурой, закрытой для приложений, то структура имен, употребляемых при формировании контекста безопасности (имеются в виду имена партнеров по общению), закрыта для функций GSS-API. Имена рассматриваются этими функциями как последовательности байт, интерпретируемые, вероятно, коммуникационными компонентами приложений.

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

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

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

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

Основные коды подразделяются на информирующие и сигнализирующие об ошибке. Перечислим некоторые информирующие коды:

Следующие значения входят в число кодов, сигнализирующих об ошибке:

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

Функции для работы с удостоверениями

Работа приложения, опирающегося на интерфейс GSS-API, должна начинаться с получения удостоверения, которое засвидетельствует, что приложение имеет право выступать от имени определенного субъекта.

Интерфейс GSS-API предоставляет следующие функции для применения удостоверений:

Как уже указывалось, приложение получает в свое распоряжение не само удостоверение, а его дескриптор, впоследствии используемый в качестве аргументов функций GSS_Release_cred, GSS_Inquire_cred, GSS_Add_cred, а также функций формирования контекста безопасности.

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

Функция GSS_Inquire_cred позволяет получить информацию об удостоверении: имя ассоциированного субъекта, срок годности, возможность употребления в операциях с контекстом (инициация и/или принятие), поддерживаемые механизмы безопасности. Данная функция особенно полезна применительно к подразумеваемому удостоверению, характеристики которого могут меняться от системы к системе.

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

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

Создание и уничтожение контекстов безопасности

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

Для работы с контекстами обобщенный интерфейс безопасности GSS-API предоставляет следующие функции:

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

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

Если инициатор общения (обычно это клиент) желает убедиться в подлинности партнера, он передает функции GSS_Init_sec_context флаг mutual_req_flag (требуется взаимная аутентификация ). В таком случае вызов GSS_Init_sec_context возвращает в качестве основного кода значение GSS_S_CONTINUE_NEEDED (а не GSS_S_COMPLETE ). Соответствующим образом меняется и генерируемый контекстный токен. Партнер, приняв и обработав (с помощью функции GSS_Accept_sec_context ) присланную информацию, получит на выходе установленный флаг mutual_state и новый контекстный токен, который следует вернуть инициатору. Последний должен повторно обратиться к функции GSS_Init_sec_context с полученным токеном. При отсутствии ошибок GSS_Init_sec_context вернет, наконец, основной код GSS_S_COMPLETE, и формирование контекста на этом завершится.

При формировании контекста служба безопасности может требовать обмена несколькими токенами (даже без взаимной аутентификации ). Тогда инициатору придется несколько раз вызывать функцию GSS_Init_sec_context, а его партнеру - функцию GSS_Accept_sec_context. Все вызовы, кроме последнего, вернут основной код GSS_S_CONTINUE_NEEDED. Последний вызов, завершающий формирование контекста на соответствующей стороне, в нормальном случае выдаст основной код GSS_S_COMPLETE.

Партнеры должны сами определять (способами, внешними по отношению к GSS-API), что именно из пересылаемой информации представляет собой контекстный токен и какой функции его следует передать. При отказе от контекста, ставшего ненужным, функция GSS_Delete_sec_context может передать управляющий токен, подлежащий пересылке партнеру. Партнер, приняв токен, должен вызвать функцию GSS_Process_context_token, которая проанализирует управляющую информацию и удалит вторую половину сбрасываемого контекста.

Как правило, в процессе формирования контекста партнер получает информацию о его инициаторе. Инициатор может запросить формирование "анонимного" контекста посредством флага anon_req_flag. Это имеет смысл при пользовании общедоступными услугами (получение свободно распространяемой информации и т.п.). Партнер вправе принять или отвергнуть анонимный контекст.

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

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

Для приема (импорта) контекста безопасности служит функция GSS_Import_sec_context.

Защита сообщений

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

Интерфейс GSS-API предоставляет следующие функции для работы с сообщениями:

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

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

Служба безопасности способна предоставлять дополнительные услуги в виде отслеживания продублированных сообщений и усиленного контроля последовательности сообщений. При формировании контекста эти услуги могут быть заказаны (флаги replay_det_req_flag и sequence_req_flag ). Ответные флаги показывают, действительно ли обеспечивается запрошенный уровень защиты - тогда в ассоциированные токены безопасности или инкапсулированные сообщения прозрачным для приложения образом могут вставляться порядковые номера, временные штампы и т.п. Соответственно, приложение должно быть готово получить от функций GSS_VerifyMIC / GSS_Unwrap основные коды завершения: GSS_S_DUPLICATE_TOKEN (обнаружено дублирование сообщений), GSS_S_OLD_TOKEN (старое сообщение), GSS_S_UNSEQ_TOKEN (опоздавшее сообщение), GSS_S_GAP_TOKEN (сообщение пришло слишком рано - некоторые предшествующие сообщения еще не получены). Подозрительные сообщения, несмотря на ненормальный код завершения, передаются приложению, которое трактует ситуацию в соответствии с избранной политикой безопасности (в частности, ничто не мешает обработать сообщение обычным образом).

Некоторые службы безопасности могут предоставлять различное качество защиты (Quality Of Protection - QOP). Выбор подходящего качества важен для приложения с точки зрения разумного расходования ресурсов, поскольку сильная защита может требовать значительных накладных расходов. В спецификациях интерфейса GSS_API определяется формат элемента данных, описывающего качество защиты. Это 32-битное целое, состоящее из двух 16-битных частей, одна из которых относится к контролю целостности, а другая - к обеспечению конфиденциальности. В обоих случаях задается степень контроля, идентификаторы используемых алгоритмов и информация, специфичная для выбранного алгоритма.

Логика работы пользователей интерфейса безопасности

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

Детали, связанные с преобразованием имен, опущены. Текст в фигурных скобках является комментарием. Стрелка --> отделяет входные параметры от выходных.

Мы видим, что общая схема взаимодействия удаленных партнеров под защитой интерфейса безопасности GSS-API довольно проста, однако практическая реализация всех необходимых проверок (кодов завершения, установленных флагов) требует известной аккуратности.

Представление некоторых объектов интерфейса безопасности в среде языка C

Представление средствами языка C объектов, фигурирующих в обобщенном интерфейсе безопасности GSS-API, по большей части довольно очевидно (или не может быть стандартизовано, так как зависит от специфики механизма безопасности ).

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

typedef struct gss_buffer_desc_struct {
   size_t length;
   void *value;
} gss_buffer_desc, *gss_buffer_t;

Тип gss_buffer_t используется при задании составных аргументов - имен, дескрипторов, токенов, сообщений и т.п.

Идентификаторы объектов представляются следующим образом (см. листинг 11.2).

typedef struct gss_OID_desc_struct {
   OM_uint32 length;
   void *elements;
} gss_OID_desc, *gss_OID;

Указатели elements ссылаются на начало представления идентификаторов, т. е. на последовательности байт, устроенных в соответствии с базовыми правилами ASN.1.

Наборы объектных идентификаторов представляются так, как показано на листинге 11.3.

typedef struct gss_OID_set_desc_struct {
   int    count;
   gss_OID elements;
} gss_OID_set_desc, *gss_OID_set;

Вводятся и некоторые другие типы, уточняющие представление структурированных значений.

На листинге 11.4 показано, как выглядит на языке C описание функции GSS_Init_sec_context.

OM_uint32 GSS_Init_sec_context (
   OM_uint32 *minor_status,
   const gss_cred_id_t initiator_cred_handle,
   gss_ctx_id_t	*context_handle,
   const gss_name_t	target_name,
   const gss_OID mech_type,
   OM_uint32 req_flags,
   OM_uint32 time_req,
   const gss_channel_bindings_t 
       input_chan_bindings,
   const gss_buffer_t input_token
   gss_OID *actual_mech_type,
   gss_buffer_t output_token,
   OM_uint32 *ret_flags,
   OM_uint32 *time_rec
);

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

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