Кратко

  • RFC 3129 предложил брать основу ключей для Security Association IPsec из сеансовых ключей билетов Kerberos и тем самым уменьшить число долговременных попарных секретов.
  • KINK прямо не считался заменой IKE: централизованное управление и экономия вычислений покупались зависимостью от активной доверенной третьей стороны.
  • Сложность перемещалась к доступности KDC, realms, часам и именам, а разрешение туннелей и traffic selectors оставалось на локальных узлах.

Самая выразительная формула RFC 3129 считала не биты, а отношения. Если каждой паре узлов IPsec выдать отдельный предварительно согласованный секрет, документ описывал распределение как задачу O(n²). В Kerberos каждый principal поддерживает долговременную связь с Key Distribution Center, а KDC выдаёт сервисные билеты с сеансовыми ключами. В упрощённой модели число долговременных секретов приближается к O(n).

Это не полный бюджет эксплуатации Kerberos. Смысл сравнения в другом: криптография может оставаться стойкой, а система стать неуправляемой из-за числа секретов, которые нужно учитывать, доставлять, менять и отзывать.

Архитектура IPsec уже разделяла защиту и переговоры. RFC 2401 описывал Security Associations, AH и ESP. RFC 2409 определял IKE, с помощью которого два узла взаимно аутентифицировались, согласовывали параметры и получали ключевой материал. Способность работать без активного центрального посредника была важным свойством IKE.

Независимость распределяла нагрузку по краям. Масштабная аутентификация через X.509 требовала сертификатов, путей доверия и операций подписи. Diffie–Hellman создавал общий секрет, но требовал вычислений и делал ответчика целью для отказа в обслуживании. Предварительно согласованные ключи обходили сертификаты, однако возвращали попарное распределение. Политика организации тоже оказывалась на множестве устройств с разным качеством управления.

Kerberos предлагал другую топологию доверия. По RFC 1510 клиент аутентифицировался перед KDC, получал билет для сервиса и сеансовый ключ. Сервис мог извлечь тот же ключ из билета. KINK должен был использовать такой ключ как основу материала для SA IPsec.

Менялось не только сообщение протокола. Долговременные секреты связывали principal с KDC, а не каждую возможную пару узлов. При PKINIT дорогая первоначальная public-key аутентификация могла обслужить билеты для многих сервисов. Часть политики становилась управляемой в realm, а не зависела исключительно от того, как каждый удалённый узел понял общую инструкцию.

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

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

Требования ограничивали её участие. Инициатором должен был стать любой IPsec peer: и Kerberos-клиент только с TGT, и сервис с keytab. Режим user-to-user покрывал случай, когда ответчик не мог расшифровать обычный сервисный билет. Требовались несколько realms и корректная обработка абсолютного расхождения часов.

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

На них оставалась большая часть IPsec. KINK должен был создавать, менять, обновлять и удалять SA, согласовывать suites и selectors, поддерживать transport и tunnel mode, AH и ESP, IPv4 и IPv6. Удостоверенная Kerberos личность не получала автоматически право представлять конкретный префикс. Авторизацию сохраняла локальная политика.

Разница между аутентификацией и авторизацией здесь принципиальна. Настоящий билет отвечает на вопрос о личности и предоставляет общий ключ. Он сам не разрешает открыть туннель для любой сети. Если локальное правило связывает подлинный principal со слишком широким selector, центральное подтверждение только придаёт ошибке убедительность.

RFC 3129 не был готовым KINK. Документ категории Informational перечислял требования. В 2006 году RFC 4430 описал KINK как Proposed Standard и сослался на 3129 как на основание. Требования и интероперабельный протокол — разные исторические этапы. Ни один из них не доказывает широкое внедрение или вытеснение IKE.

Соседние стандарты продолжали меняться. RFC 4120 обновил Kerberos V5, RFC 3961 оформил framework шифрования и checksums, RFC 4556 стандартизировал PKINIT, RFC 6113 обобщил pre-authentication. IKE превратился в IKEv2 в RFC 4306 и был позднее изложен в RFC 7296. Интернет сохранил несколько моделей доверия, потому что среды выбирают разные допустимые отказы.

Поэтому O(n) против O(n²) нельзя принимать за итоговую смету. KDC сокращает попарные долговременные секреты, но требует защиты master keys, смены keytabs, резервирования, cross-realm отношений, синхронизации времени, аудита и расчёта мощности. Много малых обязательств заменяется меньшим числом системно важных институтов.

Отказ проявляется поэтапно. Действующие SA могут продолжать работу, а действующий билет — позволять локальный rekey. Новые credentials, истёкшие билеты и ещё не начатые сервисные отношения потребуют центра раньше. Граница определяется сроками билета и SA, cache и моментом следующего обращения, а не фразой «KDC недоступен — весь IPsec остановлен».

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

Security Considerations RFC 3129 были трезвы: созданные SA наследуют объединение слабостей IPsec и Kerberos. Сочетание двух зрелых механизмов не отменяет их недостатков и может добавить ошибку на стыке.

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

KDC не устранял доверие. Он делал его повторно используемым, наблюдаемым и концентрированным. Это давало операционную выгоду и общий системный риск. RFC 3129 записал обе стороны сделки до завершения протокола.

Источники