Керберизованное интернет-согласование ключей
Керберизованное согласование ключей в Интернете ( KINK ) — это протокол, определенный в 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 SA. Каждая команда или ответ содержит общий заголовок вместе с набором полезных данных типа-длины-значения. Тип команды или ответа ограничивает полезные данные, отправляемые в сообщениях обмена.
KINK сам по себе является протоколом без сохранения состояния, в котором каждая команда или ответ не требуют хранения жесткого состояния для KINK. В этом отличие от IKE, который использует основной режим для сначала установления ассоциации безопасности Интернета и протокола управления ключами ( ISAKMP ) SA с последующим обменом в быстром режиме.
KINK использует механизмы Kerberos для обеспечения взаимной аутентификации и защиты от повторного воспроизведения. Для установления SA KINK обеспечивает конфиденциальность полезных данных, следующих за полезными данными Kerberos AP-REQ. Конструкция KINK смягчает атаки типа «отказ в обслуживании», требуя аутентифицированного обмена перед использованием любых операций с открытым ключом и установкой любого состояния. KINK также предоставляет средства использования механизмов Kerberos User-to-User, когда нет общего ключа между сервером и KDC. Обычно, помимо прочего, это относится к узлам IPsec, использующим PKINIT для начальной аутентификации.
KINK напрямую повторно использует полезные данные быстрого режима, определенные в разделе 5.5 IKE , с некоторыми незначительными изменениями и упущениями. В большинстве случаев обмены KINK представляют собой одну команду и ее ответ. Необязательное третье сообщение требуется при создании SA, только если ответчик отклоняет первое предложение инициатора или желает предоставить материалы для ключей. 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 | область интерпретации (DOI) | |||||||||||||||||||||||||||||||
| 64 | идентификатор транзакции (XID) | |||||||||||||||||||||||||||||||
| 96 | следующая полезная нагрузка | А | длина контрольной суммы | |||||||||||||||||||||||||||||
| 128 ... |
полезная нагрузка ... | |||||||||||||||||||||||||||||||
| ... ... |
контрольная сумма ... | |||||||||||||||||||||||||||||||
- тип: CREATE, DELETE, REPLY, GETTGT, ACK, STATUS или частное использование.
- версия: номер основной версии протокола.
- длина: длина всего сообщения
- область интерпретации (DOI): DOI, определенный в Ассоциации безопасности Интернета и протоколе управления ключами (ISAKMP).
- Идентификатор транзакции (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, если ответчик требует явного подтверждения того, что ответ был получен, в противном случае 0
- длина контрольной суммы: длина криптографической контрольной суммы сообщения в байтах.
- полезные нагрузки: список полезных нагрузок типа/длины/значения (TLV).
- контрольная сумма: контрольная сумма с ключом Kerberos для всего сообщения, за исключением самого поля контрольной суммы.
Полезная нагрузка
[ редактировать ]Полезные нагрузки 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: полезная нагрузка, которая передает ответчику AP-REQ Kerberos.
- KINK_AP_REP: полезная нагрузка, которая передает AP-REP Kerberos инициатору.
- KINK_KRB_ERROR: полезная нагрузка, которая передает ошибки типа Kerberos обратно инициатору.
- KINK_TGT_REQ: полезная нагрузка, которая предоставляет средства для получения TGT от узла, чтобы получить билет службы пользователь-пользователь от KDC.
- KINK_TGT_REP: полезная нагрузка, содержащая TGT, запрошенный в предыдущей полезной нагрузке KINK_TGT_REQ команды GETTGT.
- KINK_ISAKMP: полезные данные для инкапсуляции полезных данных быстрого режима ISAKMP IKE (фаза 2), обеспечивающие обратную совместимость с IKE и ISAKMP при наличии последующих версий.
- KINK_ENCRYPT: полезные данные для инкапсуляции других полезных данных KINK, которые шифруются с использованием сеансового ключа и алгоритма, указанного в его etype.
- KINK_ERROR: полезная нагрузка, которая возвращает состояние ошибки.
Реализации
[ редактировать ]В настоящее время доступны следующие с открытым исходным кодом реализации KINK :
- Racoon2. Архивировано 15 октября 2008 г. в Wayback Machine из проекта WIDE .
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ RFC 3129: Требования к керберизованному согласованию ключей в Интернете , Рабочая группа по проектированию Интернета , июнь 2001 г., стр. 2
- ^ RFC 3129: Требования к керберизованному согласованию ключей в Интернете , Рабочая группа по проектированию Интернета , июнь 2001 г., стр. 1
- ^ RFC 4322: Оппортунистическое шифрование с использованием обмена ключами в Интернете (IKE) , Рабочая группа по разработке Интернета , июнь 2001 г., стр. 5