RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 16 из 62

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывает предложения в части выбора протоколов IPsec (IKE, ESP и/или AH) для SA, а также криптографических алгоритмов, связанных с каждым протоколом.

Элемент данных SA включает одно или несколько предложений. Каждое из предложений включает один или несколько протоколов (обычно один). Каждый протокол включает одно или несколько преобразований, каждое из которых задает криптографический алгоритм. Каждое преобразование может включать атрибуты (атрибуты нужны лишь в тех случаях, когда идентификатор преобразования не задает криптографический алгоритм полностью).

Такая иерархическая структура была разработана для эффективного представления предложений по выбору криптографических наборов, когда число поддерживаемых наборов велико, поскольку множество значений приемлемо для множества платформ. Отвечающая сторона должна выбрать один набор, который может быть любым подмножеством предложения в SA, выбранным в соответствии с приведенными ниже правилами:

  • Каждое предложение включает, по крайней мере, один протокол. Если предложение принимается элемент SA в отклике должен содержать те же протоколоы в том же порядке, как они были указаны в предложении. Ответчик должен принять одно из предложений или отвергнуть все предложения и возвратить сообщение об ошибке (Например, если предложение включает протоколы ESP и AH и это предложение принимается, оба протокола ESP и AH должны восприниматься. Если ESP и AH включены в разные предложения, ответчик должен принять только один из этих протоколов).
  • Каждый предлагаемый протокол IPsec содержит, по крайней мере, одно преобразование. Каждое преобразование включает тип преобазования. Принимаемые криптографические наборы должны содержать в точности одно преобразование каждого типа, включенного в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен включать одно преобразование ENCR_ и одно преобразование AUTH_. Таким образом, возможно шесть комбинаций.

Поскольку инициатор передает свое значение Diffie-Hellman в сообщении IKE_SA_INIT, он должен угадать группу Diffie-Hellman, которую ответчик выберет из списка поддерживаемых групп. Если выбор инициатора окажется ошибочным, ответчик будет возвращать элемент данных Notify типа INVALID_KE_PAYLOAD, показывающий выбранную группу. В таком случае инициатор должен повторить запрос IKE_SA_INIT с указанием корректной группы Diffie-Hellman. Инициатор должен снова предложить полный набор допустимых криптографических наборов, поскольку сообщение с отказом было передано без идентификации. Если этого не делать, активный атакующий сможет принудить конечные точки к выбору наиболее слабого криптографического набора из числа поддерживаемых обеими сторонами.

Страница 16 из 62

2007 - 2022 © Русские переводы RFC, IETF, ISOC.