Керберизованное Интернет-согласование ключей - Kerberized Internet Negotiation of Keys

Керберизованное Интернет-согласование ключей (КИНК) - протокол, определенный в RFC 4430 используется для создания IPsec ассоциация безопасности (SA), аналогично Обмен ключами в Интернете (IKE), используя Kerberos протокол, позволяющий доверенным третьим сторонам выполнять аутентификацию одноранговых узлов и управлять политиками безопасности централизованно.^[1]

Его мотивация приведена в RFC 3129 в качестве альтернативы IKE, в которой каждый одноранговый узел должен использовать X.509 сертификаты для аутентификации, используйте Обмен ключами Диффи-Хеллмана (DH) для шифрования, знать и реализовывать политику безопасности для каждого однорангового узла, с которым он будет соединяться,^[2] с аутентификацией сертификатов X.509 либо заранее, либо с использованием DNS предпочтительно с DNSSEC.^[3] Используя Kerberos, узлы KINK должны взаимно аутентифицировать с соответствующим сервером аутентификации (AS), с центр распределения ключей (KDC), в свою очередь, контролирует распределение ключевой материал для шифрования и, следовательно, для управления политикой безопасности IPsec.

Описание протокола

KINK - это протокол команды / ответа, который может создавать, удалять и поддерживать IPsec SAs. Каждая команда или ответ содержит общий заголовок вместе с набором полезных данных типа длина-значение. Тип команды или ответа ограничивает полезную нагрузку, отправляемую в сообщениях обмена.

KINK сам по себе является протоколом без сохранения состояния, в котором каждая команда или ответ не требует хранения жесткого состояния для KINK. В этом отличие от IKE, в котором основной режим используется для первой установки ассоциации безопасности в Интернете и протокола управления ключами (ИСАКМП ) SA с последующими обменами в быстром режиме.

KINK использует Kerberos механизмы для обеспечения взаимной аутентификации и защиты от воспроизведения. Для установления SA KINK обеспечивает конфиденциальность полезных данных, следующих за полезными данными Kerberos AP-REQ. Дизайн KINK смягчает атаки типа «отказ в обслуживании», требуя аутентифицированного обмена перед использованием любых операций с открытым ключом и установкой любого состояния. KINK также предоставляет средства использования механизмов Kerberos User-to-User, когда нет общего ключа между сервером и KDC. Это обычно, но не ограничивается случаем с одноранговыми узлами IPsec, использующими PKINIT для начальной аутентификации.

KINK напрямую повторно использует полезные данные быстрого режима, определенные в разделе 5.5. АЙК, с небольшими изменениями и упущениями. В большинстве случаев обмены KINK представляют собой одну команду и ответ на нее. Необязательное третье сообщение требуется при создании SA, только если отвечающая сторона отклоняет первое предложение от инициатора или хочет внести ключевые материалы. KINK также обеспечивает смену ключей и Обнаружение мертвого узла.

Формат пакета

Сообщение KINK включает следующие поля:

Сообщение KINK
Битовое смещение	0	8	16
0	тип	версия	длина
32	область интерпретации (DOI)
64	идентификатор транзакции (XID)
96	следующая полезная нагрузка	А	длина контрольной суммы
128 ...	полезные нагрузки ...
... ...	контрольная сумма ...

тип: CREATE, DELETE, REPLY, GETTGT, ACK, STATUS или частное использование
версия: основной номер версии протокола
длина: длина всего сообщения
область интерпретации (DOI): DOI, как определено в Ассоциация интернет-безопасности и протокол управления ключами (ИСАКМП)
идентификатор транзакции (XID): идентификация транзакции, определяемая как команда, ответ и дополнительное подтверждение
следующая полезная нагрузка: тип первой полезной нагрузки после заголовка сообщения как KINK_DONE, KINK_AP_REQ, KINK_AP_REP, KINK_KRB_ERROR, KINK_TGT_REQ, KINK_TGT_REP, KINK_ISAKMP, KINK_ENCRYPT или KINK_ERROR
Бит ACK или ACKREQ: 1, если ответчик требует явного подтверждения получения REPLY, в противном случае 0
длина контрольной суммы: длина в байтах криптографической контрольной суммы сообщения
полезные данные: список полезных данных типа / длины / значения (TLV)
контрольная сумма: контрольная сумма с ключом Kerberos по всему сообщению, за исключением самого поля контрольной суммы

Полезные нагрузки

Полезные данные KINK определяются как:

KINK полезная нагрузка
Битовое смещение	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	следующая полезная нагрузка																длина полезной нагрузки
32 ...	ценить ...

следующая полезная нагрузка: тип первой полезной нагрузки
length: длина полезной нагрузки

Определены следующие полезные данные:

KINK_AP_REQ: полезная нагрузка, которая передает Kerberos AP-REQ ответчику
KINK_AP_REP: полезная нагрузка, которая передает Kerberos AP-REP инициатору
KINK_KRB_ERROR: полезная нагрузка, которая передает ошибки типа Kerberos обратно инициатору
KINK_TGT_REQ: полезная нагрузка, которая предоставляет средства для получения TGT от однорангового узла, чтобы получить билет службы User-to-User от KDC.
KINK_TGT_REP: полезная нагрузка, которая содержит TGT, запрошенный в предыдущей полезной нагрузке KINK_TGT_REQ команды GETTGT
KINK_ISAKMP: полезная нагрузка для инкапсуляции полезной нагрузки ISAKMP IKE Quick Mode (фаза 2), чтобы обеспечить обратную совместимость с IKE и ISAKMP, если есть последующие версии
KINK_ENCRYPT: полезная нагрузка для инкапсуляции других полезных данных KINK, зашифрованная с использованием сеансового ключа и алгоритма, указанного в его etype.
KINK_ERROR: полезная нагрузка, которая возвращает состояние ошибки

Реализации

Следующее Открытый исходный код реализации KINK в настоящее время доступны:

Racoon2 от ШИРОКИЙ ПРОЕКТ.

Смотрите также

Обмен ключами в Интернете