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

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

3.3.6. Согласование атрибутов

При согласовании защищенной связи инициатор вносит свои предложения ответчикам. Ответчики должны выбирать из предложений один полный набор параметров или отвергать все предложения, если они не подходят. Если имеется множество предложений, ответчик должен выбрать номер одного из них и вернуть инициатору все субструктуры Proposal с этим номером предложения. Если имеется множество однотипных преобразований, ответчик должен выбрать одно из них. Все атрибуты выбранного преобразования должны возвращаться в неизменном виде. Инициатор обмена должен убедиться в том, что принятое предложение согласуется со сделанными им предложениями. При наличии расхождений отклик должен быть отвергнут.

Согласование групп Diffie-Hellman имеет некоторые особенности. Предложение SA включает предлагаемые атрибуты и открытый номер Diffie-Hellman (KE) в одно сообщение. Если в начальном обмене инициатор предлагает использовать одну из нескольких групп Diffie-Hellman, ему следует выбрать ту, которую ответчик с высокой вероятностью примет, и включить соответствующее этой группе значение KE. Если предсказание окажется неверным, ответчик укажет в отклике корректную группу и инициатору следует найти для своего KE элемент в этой группе при повторе сообщения. Однако ему следует по-прежнему предлагать полный набор поддерживаемых групп, чтобы предотвратить возможность организации атак, направленных на снижение уровня защиты.

Примечание для разработчиков. Некоторые согласуемые атрибуты могут включать диапазоны, со множеством подходящих значений (например, размеры ключа переменной длины для симметричного шифра). Для повышения уровня интероперабельности и обеспечения возможности независимого обновления конечных точек разработчикам реализаций этого протокола следует принимать значения, которые они считают обеспечивающими лучшую защиту. Например, если партнер настроен на принятие шифра с переменным размером ключа для размера X (битов) и предлагается более длинный ключ, реализации следует принять такое предложение, если она может работать с более длинным ключом.

Поддержка такой возможности позволяет реализации выражать концепции защиты не ниже определенного уровня — «ключ размером не менее X битов для шифра Y».

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

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