RFC: 4422
Оригинал: Simple Authentication and Security Layer (SASL)
Предыдущие версии: RFC 2222
Категория: Предложенный стандарт
Дата публикации:
Авторы: ,
Перевод: Николай Малых

6.2. Пассивные атаки

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

6.3. Замена ключей

Безопасные или административно разрешенные значения времени жизни уровней защиты в механизмах SASL конечны. Эффективность криптографических ключей снижается с течением времени при их использовании — наличие времени и/или зашифрованного текста, который криптоаналитик получает при первом использовании ключа упрощает анализ и организацию атак.

Административные ограничения на продолжительность существования защитного уровня могут задаваться в форме сертификатов X.509, ярлыков Kerberos V или каталогов. Такие ограничения часто весьма желательны. На практике же очевидным результатом административного ограничения срока жизни является то, что приложение может столкнуться с прекращением работы уровня защиты во время операции прикладного уровня (например, при передаче большого объема данных). В результате соединение будет закрыто (см. параграф 3.7), что приведет к негативной реакции пользователей.

Замена ключей (Re-keying — процесс повторного согласования ключей) является способом решения проблемы. Схема SASL сама по себе не обеспечивает замены ключей, но это могут делать механизмы SASL. Разработчикам новых механизмов SASL следует обратить внимание на вопрос замены ключей.

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

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