RFC 2743

RFC 2743 (Generic Security Service Application Program Interface, Version 2, Update 1) — это спецификация интернет-стандарта, опубликованная в январе 2000 года Инженерным советом Интернета (IETF), которая определяет абстрактный интерфейс прикладного программирования (API) для служб обеспечения безопасности в компьютерных сетях. RFC 2743 является обновлением предыдущей версии GSS-API (RFC 2078) и устанавливает единый механизм, позволяющий приложениям выполнять аутентификацию, устанавливать контексты безопасности и защищать передаваемые данные, не завися от конкретных криптографических протоколов нижнего уровня.

История и предпосылки создания

Разработка GSS-API началась в середине 1990-х годов в связи с необходимостью унификации механизмов безопасности в гетерогенных сетевых средах. До появления GSS-API каждое приложение или протокол (например, Kerberos, Secure Socket Layer (SSL), протоколы аутентификации в UNIX) использовали собственные API для работы с криптографией и аутентификацией. Это затрудняло интеграцию различных систем и требовало от разработчиков глубоких знаний о каждом конкретном механизме.

Первая версия GSS-API была опубликована как RFC 1508 в 1993 году, а затем уточнена в RFC 2078 (1997 год). RFC 2743, выпущенный через три года, внёс ряд исправлений и дополнений, в частности, уточнил обработку ошибок, добавил поддержку новых типов данных и расширил возможности делегирования учётных данных. Документ был подготовлен рабочей группой IETF по вопросам безопасности (Common Authentication Technology Working Group) под руководством Джона Линна (John Linn).

Основные положения и архитектура

RFC 2743 описывает GSS-API как абстрактный интерфейс, который оперирует понятиями учётных данных (credentials), контекста безопасности (security context) и токенов (tokens). Архитектура GSS-API построена на принципе разделения уровней: приложение (клиент или сервер) вызывает функции API, а реализация (провайдер GSS-API) взаимодействует с базовым механизмом безопасности.

Учётные данные (Credentials)

Учётные данные представляют собой информацию, подтверждающую личность субъекта (пользователя, процесса или службы). Они могут включать криптографические ключи, сертификаты, пароли или билеты (tickets). В GSS-API учётные данные могут быть инициирующими (для стороны, начинающей аутентификацию) или целевыми (для стороны, принимающей запрос). Учётные данные могут быть делегированы — переданы от одного субъекта другому для выполнения действий от имени первого.

Контекст безопасности (Security Context)

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

Токены (Tokens)

Токены — это блоки данных, которые передаются между сторонами в процессе установления контекста или при защите сообщений. RFC 2743 определяет три типа токенов:

• Токены инициализации (initiator tokens) — отправляются инициатором аутентификации.
• Токены ответа (target tokens) — отправляются целевой стороной.
• Токены защиты сообщений (per-message tokens) — используются для шифрования, подписи или проверки целостности данных после установления контекста.

Основные функции API

RFC 2743 определяет набор функций, которые должны быть реализованы провайдером GSS-API. Ниже приведены ключевые категории:

Управление учётными данными

• GSS_Acquire_cred — получение учётных данных для субъекта.
• GSS_Release_cred — освобождение учётных данных.
• GSS_Inquire_cred — запрос атрибутов учётных данных (например, срок действия, имя субъекта).

Установление контекста безопасности

• GSS_Init_sec_context — инициирование контекста безопасности (вызывается инициатором).
• GSS_Accept_sec_context — принятие контекста безопасности (вызывается целевой стороной).
• GSS_Delete_sec_context — удаление контекста.
• GSS_Process_context_token — обработка входящего токена, связанного с контекстом.

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

• GSS_GetMIC — создание кода аутентичности сообщения (Message Integrity Code) для проверки целостности.
• GSS_VerifyMIC — проверка кода аутентичности.
• GSS_Wrap — шифрование и/или подпись сообщения с возможностью упаковки (wrap).
• GSS_Unwrap — расшифровка и проверка сообщения.

Вспомогательные функции

• GSS_Display_status — преобразование кода ошибки в читаемое сообщение.
• GSS_Indicate_mechs — получение списка доступных механизмов безопасности.
• GSS_Release_buffer — освобождение памяти, выделенной под токены.

Механизмы безопасности

RFC 2743 не привязывается к какому-либо конкретному протоколу безопасности. Вместо этого он определяет, как механизмы (например, Kerberos, NTLM, SPKM, LIPKEY) могут быть встроены в GSS-API через объектно-ориентированную модель. Каждый механизм регистрируется с уникальным идентификатором объекта (OID). При установлении контекста стороны могут согласовать используемый механизм.

Наиболее распространённым механизмом, реализующим GSS-API, является Kerberos V5 (определённый в RFC 1964). Другие механизмы включают:

• SPKM (Simple Public-Key GSS-API Mechanism) — на основе асимметричной криптографии.
• LIPKEY (Low Infrastructure Public Key Mechanism) — упрощённый вариант для сред с низкими требованиями к инфраструктуре.
• NTLMSSP — механизм для совместимости с протоколами Microsoft Windows (используется в SMB/CIFS).

Применение

GSS-API широко используется в сетевых протоколах и приложениях, требующих безопасного взаимодействия. Основные области применения:

Аутентификация в распределённых системах

• SSH — в некоторых реализациях (например, OpenSSH) поддерживает GSS-API для аутентификации через Kerberos.
• HTTP — протокол SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) на основе GSS-API используется для единого входа (SSO) в веб-приложениях, в частности, в Microsoft Active Directory.
• SMB/CIFS — протоколы файловых служб Windows используют GSS-API для аутентификации и шифрования.

Защита данных в протоколах прикладного уровня

• LDAP — протокол доступа к каталогам может использовать GSS-API для аутентификации и защиты соединений.
• NFS — версия 4 протокола сетевой файловой системы (NFSv4) опирается на GSS-API для обеспечения безопасности.
• RPC — в средах, использующих удалённый вызов процедур (RPC), GSS-API может применяться для аутентификации и шифрования.

Реализации в операционных системах

• В Linux и других UNIX-подобных системах GSS-API реализован в библиотеке libgssapi (часть пакета krb5 или heimdal).
• В Microsoft Windows GSS-API реализован через подсистему Security Support Provider Interface (SSPI), которая предоставляет аналогичный функционал, но с некоторыми отличиями в API.
• В macOS GSS-API доступен через фреймворк GSS.framework.

Критика и ограничения

Несмотря на широкое распространение, RFC 2743 и GSS-API имеют ряд недостатков, которые отмечались в сообществе разработчиков:

• Сложность реализации — абстрактный интерфейс требует от провайдеров поддержки множества функций, что увеличивает сложность разработки и тестирования.
• Отсутствие поддержки современных криптографических алгоритмов — спецификация была создана до широкого внедрения эллиптической криптографии (ECC) и квантово-устойчивых алгоритмов. Обновления (например, RFC 5587) частично решают эту проблему, но не полностью.
• Проблемы с делегированием — механизм делегирования учётных данных может приводить к уязвимостям, если не реализован корректно (например, возможность кражи делегированных учётных данных злоумышленником).
• Зависимость от механизма — хотя GSS-API абстрагирует приложение от деталей, выбор конкретного механизма (например, Kerberos) всё равно накладывает ограничения на архитектуру (требование наличия центрального сервера аутентификации).

Влияние на последующие стандарты

RFC 2743 послужил основой для ряда последующих спецификаций IETF, в том числе:

• RFC 4121 — уточнение использования GSS-API с Kerberos V5 в контексте протокола SPNEGO.
• RFC 4178 — определение протокола SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) для согласования механизмов безопасности.
• RFC 5587 — расширение GSS-API для поддержки новых криптографических алгоритмов и типов данных.

Источники

1. RFC 2743 — Generic Security Service Application Program Interface, Version 2, Update 1. IETF, January 2000.
2. RFC 2078 — Generic Security Service Application Program Interface, Version 2. IETF, January 1997.
3. RFC 1508 — Generic Security Service Application Program Interface. IETF, September 1993.
4. RFC 1964 — The Kerberos Version 5 GSS-API Mechanism. IETF, June 1996.
5. RFC 4121 — The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. IETF, July 2005.
6. RFC 4178 — The Simple and Protected GSS-API Negotiation Mechanism. IETF, October 2005.
7. RFC 5587 — Extended Generic Security Service Mechanism for Kerberos. IETF, July 2009.
8. Linn, J. (1994). "Generic Security Service Application Program Interface (GSS-API) — Overview and Rationale". Proceedings of the 1994 Internet Society Symposium on Network and Distributed System Security.