Классификация функций безопасности

Общие положения

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

Вспомогательные средства

В число вспомогательных входят следующие функции:

и некоторые другие. Мы не будем подробно описывать вспомогательные функции.

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