WikiDer > Керберизованное Интернет-согласование ключей
Керберизованное Интернет-согласование ключей (КИНК) - протокол, определенный в 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 включает следующие поля:
| Битовое смещение | 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, как определено в Ассоциация интернет-безопасности и протокол управления ключами (ИСАКМП)
- идентификатор транзакции (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 определяются как:
| Битовое смещение | 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 в настоящее время доступны:
Смотрите также
Рекомендации
- ^ RFC 3129: Требования для согласования ключей через Интернет с использованием протокола Kerberized, Инженерная группа Интернета, Июнь 2001 г., стр. 2
- ^ RFC 3129: Требования для согласования ключей через Интернет с использованием протокола Kerberized, Инженерная группа Интернета, Июнь 2001 г., стр. 1
- ^ RFC 4322: оппортунистическое шифрование с использованием Internet Key Exchange (IKE), Инженерная группа Интернета, Июнь 2001 г., стр. 5