RFC: 3748
Оригинал: Extensible Authentication Protocol (EAP)
Предыдущие версии: RFC 2284
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

RFC 3748, Страница 37 из 46

7.10. Создание ключей

Для сервера EAP и его партнера возможна взаимная идентификация и создание ключей. Для обеспечения ключевого материала, который будет впоследствии использоваться согласованным криптографическим набором, поддерживающий создание ключей метод EAP должен экспортировать основной ключ сеанса (MSK) размером не менее 64 октетов и расширенный основной ключ сеанса (EMSK) размером не менее 64 октетов. Методы EAP, создающие ключи, должны поддерживать взаимную идентификацию между сервером EAP и его партнером.

Ключи MSK и EMSK недопустимо использовать напрямую для защиты данных — их размер достаточен для создания ключа AAA, который впоследствии используется для создания временных сеансовых ключей (TSK) используемых с выбранным криптографическим набором. Каждый криптонабор отвечает за спецификацию создания ключей TSK по ключу AAA.

Ключ AAA создается из материала, экспортируемого методом EAP (MSK и EMSK). Процедура создания ключа выполняется на сервере AAA. Во многих протоколах, использующих EAP, ключи AAA и MSK эквивалентны, но возможны и более сложные механизмы (см. [KEYFRAME]).

Методам EAP следует поддерживать «свежесть» ключей MSK и EMSK даже в тех случаях, когда одна из сторон может не иметь высококачественного генератора случайных чисел. Рекомендуется каждой стороне передавать значение nonce размером, по крайней мере, 128 битов, используемое для создания ключей MSK и EMSK.

Методы EAP экспортируют ключи MSK и EMSK, но не TSK, чтобы обеспечить независимость методов EAP от криптографического набора и среды. Ключевой материал, экспортируемый методами EAP, должен быть независимым от криптонабора, согласованного для защиты данных.

В зависимости от протокола нижележащего уровня методы EAP могут работать до или после согласования криптографического набора, поэтому выбранный криптонабор может быть неизвестен методу EAP. За счет предоставления ключевого материала пригодного для любого криптонабора методы EAP могут использоваться с широким спекторм криптографических наборов и сред.

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

Стойкость ключей TSK, используемых для защиты данных, в конечном итоге зависит от стойкости ключей, созданных методом EAP. Если этот метод не может обеспечивать достаточно стойкий ключевой материал, ключи TSK могут взломаны методом тупого перебора. Для поддержки систем, требующих стойких ключей, поддерживающим генерацию ключей методам EAP следует обеспечивать возможность генерации ключей MSK и EMSK с эффективной стойкостью не менее 128 битов.

Методы, поддерживающие генерацию ключей, должны демонстрировать криптографическое разделение ветвей MSK и EMSK в иерархии ключей EAP. Атакующий, который получил ключ MSK или EMSK, не должен получить возможность восстановления других данных с существенно меньшей затратой усилий, чем при тупом переборе, без нарушения фундаментальных криптографических допущений (таких, как необратимость односторонней функции).

Не перекрывающиеся подстроки MSK должны быть криптографически отделены одна от другой, как определено в параграфе 7.2.1. Т. е., знание одной подстроки не должно помогать в раскрытии других подстрок без нарушения фундаментальных криптографических допущений. Это требование обусловлено тем, что некоторые криптонаборы создают ключи TSK простым разбиением ключа AAA на части подходящего размера. Подобно этому, не перекрывающиеся подстроки EMSK должны быть криптографически отделены одна от другой, как и подстроки MSK.

Ключи EMSK зарезервированы для использования в будущем и должны сохраняться на сервере и идентифицируемой стороне EAP, где ключ был создан; эти ключи недопустимо передавать или использовать совместно с другими, а также применять для генерации других ключей.

Поскольку EAP не поддерживает явного согласования срока жизни ключей, идентифицирующие стороны, серверы и партнеры EAP должны быть готовы к ситуациям, когда одна из сторон сбрасывает состояние ключа, который остается корректным для другой стороны.

В данной спецификации не содержится детального руководства по созданию методами EAP ключей MSK и EMSK, генерации AAA-Key из MSK и/или EMSK и генерации TSK из AAA-Key.

Разработка и проверка алгоритмов генерации ключей сложна, поэтому методам EAP следует пользоваться хорошо известными и проверенными механизмами создания ключей (такими, какие указаны в спецификациях IKE [RFC2409] или TLS [RFC2246]) вместо разработки новых. Методам EAP следует также использовать хорошо известные и проверенные механизмы генерации ключей MSK и EMSK. Дополнительные сведения о генерации ключей EAP приведены в работе [KEYFRAME].

Страница 37 из 46

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