RFC 4121

RFC 4121 — это запрос комментариев (Request for Comments) номер 4121, опубликованный в июле 2005 года, который определяет механизм безопасности для протокола аутентификации Kerberos версии 5 (RFC 4120) в контексте использования протокола Generic Security Service Application Program Interface (GSS-API) (RFC 2743). Документ является частью серии стандартов Интернета и описывает, как Kerberos V5 используется в качестве механизма GSS-API для обеспечения взаимной аутентификации, целостности и конфиденциальности данных при обмене между клиентом и сервером.

История и контекст разработки

До появления RFC 4121 существовал ряд более ранних RFC, описывающих механизмы безопасности на основе Kerberos для GSS-API. В частности, RFC 1964 (1996 год) определял механизм Kerberos V5 для GSS-API, который, однако, имел ряд ограничений и не учитывал некоторые поздние расширения протокола Kerberos. С развитием криптографии и появлением новых требований к безопасности (например, необходимость поддержки более сильных алгоритмов шифрования, таких как AES и 3DES) возникла потребность в обновлённом стандарте. RFC 4121 был разработан для замены RFC 1964 и устранения его недостатков, включая проблемы с совместимостью с новыми типами шифров и улучшение поддержки атрибутов делегирования.

Основной целью создания RFC 4121 было приведение механизма GSS-API для Kerberos в соответствие с современными на тот момент криптографическими стандартами и обеспечение обратной совместимости с существующими реализациями. Документ был подготовлен рабочей группой IETF (Internet Engineering Task Force) по Kerberos и опубликован как Proposed Standard.

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

RFC 4121 определяет, как протокол Kerberos V5 используется в качестве механизма GSS-API. GSS-API — это абстрактный интерфейс, позволяющий приложениям использовать различные механизмы безопасности (например, Kerberos, NTLM, SPNEGO) единообразно. RFC 4121 описывает конкретную реализацию этого интерфейса для Kerberos.

Механизм аутентификации

Механизм основан на стандартном протоколе Kerberos V5. Клиент и сервер проходят взаимную аутентификацию с использованием сервера ключей (Key Distribution Center, KDC). Процесс включает:

1. Инициализация: Клиент получает билет предоставления билетов (Ticket-Granting Ticket, TGT) от KDC.
2. Запрос службы: Клиент запрашивает у KDC билет для доступа к конкретному серверу.
3. Обмен сообщениями GSS-API: Клиент и сервер обмениваются сообщениями, содержащими билеты и аутентификаторы, зашифрованные с использованием сессионного ключа.

RFC 4121 уточняет формат этих сообщений для GSS-API, включая идентификаторы механизма (OID — Object Identifier) и кодировку токенов.

Поддержка криптографических алгоритмов

Ключевым нововведением RFC 4121 по сравнению с RFC 1964 является явная поддержка нескольких типов шифрования. В документе определены следующие алгоритмы:

• des-cbc-crc: Алгоритм на основе DES (Data Encryption Standard) с контрольной суммой CRC-32. Считается устаревшим и небезопасным.
• des-cbc-md5: DES с хешированием MD5.
• des3-cbc-sha1: Тройной DES с хешированием SHA-1.
• aes128-cts-hmac-sha1-96: AES (Advanced Encryption Standard) с длиной ключа 128 бит, использующий режим CTS (Ciphertext Stealing) и HMAC-SHA1-96.
• aes256-cts-hmac-sha1-96: AES с длиной ключа 256 бит.

Выбор алгоритма зависит от конфигурации на стороне клиента и сервера. RFC 4121 не вводит новых алгоритмов, а лишь стандартизирует их использование в рамках GSS-API. Поддержка AES стала важным шагом для повышения безопасности, поскольку DES к тому времени был признан нестойким.

Формат токенов (Tokens)

RFC 4121 определяет два основных типа токенов GSS-API для Kerberos:

• Токен инициализации (Initial Context Token, ICT): Создаётся клиентом и отправляется серверу. Содержит билет Kerberos, аутентификатор и, опционально, данные о делегировании. Токен кодируется в формате ASN.1 (Abstract Syntax Notation One) с использованием DER (Distinguished Encoding Rules).
• Токен ответа (Response Token): Создаётся сервером в ответ на ICT. Подтверждает успешную аутентификацию и может содержать данные для взаимной проверки.

Также определены токены для последующей передачи данных с обеспечением целостности и конфиденциальности:

• Токен целостности (Integrity Token): Подписывает данные с использованием сессионного ключа, но не шифрует их.
• Токен конфиденциальности (Privacy Token): Шифрует данные с использованием сессионного ключа и подписывает их.

Делегирование и атрибуты

RFC 4121 поддерживает делегирование полномочий (delegation), позволяя серверу использовать учётные данные клиента для доступа к другим службам от его имени. В документе уточняется, как передаются атрибуты делегирования в токене инициализации. Это важно для сценариев, где требуется многоуровневая аутентификация, например, в распределённых системах.

Отличия от RFC 1964

Основные различия между RFC 4121 и RFC 1964 включают:

• Поддержка новых шифров: RFC 4121 добавил AES и 3DES, в то время как RFC 1964 поддерживал только DES.
• Улучшенная обработка ошибок: RFC 4121 уточняет коды ошибок и их интерпретацию в контексте GSS-API.
• Корректность кодировки: Исправлены некоторые неоднозначности в спецификации ASN.1 для токенов, что повысило совместимость между разными реализациями.
• Совместимость с расширениями Kerberos: RFC 4121 учитывает более поздние расширения Kerberos, такие как поддержка типов шифрования (RFC 3961) и предварительная аутентификация (RFC 4120).

Применение и реализация

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

• Microsoft Windows: Встроенная реализация Kerberos в Windows использует механизм, основанный на RFC 4121, для аутентификации в доменах Active Directory. Протокол SPNEGO (RFC 4178) часто используется для согласования механизма Kerberos между клиентом и сервером.
• Linux и Unix: Библиотека MIT Kerberos (krb5) и Heimdal Kerberos реализуют RFC 4121. Эти библиотеки используются в таких службах, как NFS (Network File System), SSH (Secure Shell) и веб-серверах Apache.
• Java: Платформа Java SE включает реализацию GSS-API, которая поддерживает механизм Kerberos по RFC 4121.
• Веб-протоколы: В протоколе HTTP аутентификация Kerberos через GSS-API (например, в схеме Negotiate) часто базируется на RFC 4121.

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

Несмотря на широкое распространение, RFC 4121 имеет некоторые недостатки:

• Сложность реализации: Формат токенов на основе ASN.1 и DER требует точного кодирования, что может приводить к ошибкам совместимости между разными библиотеками.
• Устаревшие алгоритмы: Поддержка DES (des-cbc-crc и des-cbc-md5) сохраняется для обратной совместимости, но эти алгоритмы считаются небезопасными и не рекомендуются к использованию в новых системах.
• Отсутствие гибкости в делегировании: Механизм делегирования, определённый в RFC 4121, не поддерживает ограничение области действия делегированных полномочий (например, ограничение по времени или целевым службам), что может создавать риски безопасности.

Источники

• RFC 4121: "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (июль 2005).
• RFC 1964: "The Kerberos Version 5 GSS-API Mechanism" (июнь 1996).
• RFC 2743: "Generic Security Service Application Program Interface Version 2, Update 1" (январь 2000).
• RFC 4120: "The Kerberos Network Authentication Service (V5)" (июль 2005).
• RFC 3961: "Encryption and Checksum Specifications for Kerberos 5" (февраль 2005).
• RFC 4178: "The Simple and Protected GSS-API Negotiation Mechanism" (октябрь 2005).