RFC: 4305
Оригинал: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
Другие версии: RFC 1826, RFC 1827, RFC 2402, RFC 2406, RFC 4835
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа "Internet Official Protocol Standards" (STD 1). Допускается свободное распространение документа.

Тезисы

В серии протоколов IPsec используются различные криптографические алгоритмы для защиты передаваемых через сеть данных. Протоколы ESP и AH обеспечивают два механизма защиты данных при передаче через защищенные связи IPsec SA. Для обеспечения интероперабельности разнородных реализаций требуется задать набор обязательных для реализации алгоритмов, чтобы всем реализациям был доступен по крайней мере один алгоритм. В этом документе определен текущий вариант набора обязательных для реализаций ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут стать обязательными в будущем.

  • ESP (Encapsulating Security Payload) - и инкапсуляция защищенных данных.
  • AH (Authentication Header) - идентификационный заголовок.
  • SA (Security Association) - защищенная связь.

Оглавление

1. Введение

Протоколы ESP и AH обеспечивают два механизма защиты данных при передаче через защищенные связи IPsec SA [IPsec, ESP, AH]. Для обеспечения интероперабельности разнородных реализаций требуется задать набор обязательных для реализации алгоритмов, чтобы всем реализациям был доступен по крайней мере один алгоритм. В этом документе определен текущий вариант набора обязательных для реализаций ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут стать обязательными в будущем.

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

Наконец, следует признать, что обязательные для реализации алгоритмы нужно менять время от времени с учетом происходящих в мире изменений. По этой причине выбор обязательных для реализации алгоритмов не включен в основные спецификации IPsec, ESP и AH. Вместо этого был создан настоящий документ. При смене алгоритмов достаточно будет обновить только один документ.

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

2. Обозначения уровня требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

В этом документе определены также дополнительные уровни требований:

  • SHOULD+
  • Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD+, в будущем перейдет в число обязательных (MUST).
  • SHOULD-
  • Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD-, может перейти на уровень разрешенных (MAY) в будущих версиях этого документа.
  • MUST-
  • Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным и может перейти на уровень SHOULD или SHOULD-.

3. Выбор алгоритма

Для того, чтобы реализация IPsec была интероперабельной, она должна поддерживать по крайней мере один алгоритм защиты. В этом разделе приведены требования по реализации алгоритмов защиты для соответствующих спецификации реализаций протоколов ESP и AH. Алгоритмы защиты, реальго используемые любой конкретной защищенной связью ESP или AH, определяются механизмом согласования (таким, как IKE1 [RFC2409, IKEv2]) или задаются заранее.

Естественно, допускается реализация дополнительных (стандартных или фирменных) алгоритмов, не упомянутых в этом документе.

3.1. Протокол ESP

Требования в поддержке алгоритмов защиты для соответствующих спецификации реализаций протокола ESP приведены ниже. Определения уровней требований содержатся в разделе 2.

Требования Алгоритм шифрования
MUST — обязательно NULL
MUST- — обязательно, но может утратить статус TripleDES-CBC [RFC2451]
SHOULD+ — следует, но может стать обязательным AES-CBC с ключами размером 128 битов [RFC3602]
SHOULD — следует AES-CTR [RFC3686]
SHOULD NOT — не следует DES-CBC [RFC2405]
Требования Алгоритм идентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]
MUST — обязательно NULL
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно HMAC-MD5-96 [RFC2403]

3.1.2. Комбинированные алгоритмы для ESP

Как указано в [ESP], протокол поддерживает использование комбинированных алгоритмов, которые обеспечивают услуги конфиденциальности и идентификации. Поддержка таких алгоритмов требует соответствующего структурирования реализации ESP. Во многих ситуациях комбинированные алгоритмы обеспечивают значительные преимущества в части эффективности и пропускной способности. Хотя в настоящее время не указывается предлагаемых или обязательных к реализации комбинированных алгоритмов, предполагается, что в ближайшем будущем представит интерес алгоритм AES-CCM [CCM], адаптированный в качестве предпочтительного для IEEE 802.11 [802.11i].

3.2. Протокол AH

Ниже приведены требования к реализации алгоритмов защиты в соответствующих спецификации реализациях протокола AH. Описания уровней требования приведены в разделе 2. Как вы понимаете, все перечисленные алгоритмы относятся к числу алгоритмов идентификации.

Требования Алгоритм идентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно HMAC-MD5-96 [RFC2403]

4. Вопросы безопасности

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

Этот документ посвящен выбору криптографических алгоритмов для использования с протоколами ESP и AH и, в частности, обязательных для реализации алгоритмов. Алгоритмы, указнные в этой спецификации, как обязательные (MUST) или рекомендуемые (SHOULD), не имеют в данный момент известных фактов взлома и выполненные криптографические исследования позволяют надеяться, что эти алгоритмы останутся безопасными в обозримом будущем. Однако, такое положение дел не обязательно будет всегда. Мы, следовательно, предполагаем появление новых версий этого документа, отражающих накопленный в сфере защиты опыт.

5. Благодарности

Большая часть приведенного здесь текста была заимствована из RFC 4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", автором которого является Jeffrey I. Schiller.

6. Отличия от RFC 2402 и 2406

[RFC2402] и [RFC2406] определяли протоколы IPsec AH и IPsec ESP. Каждый из этих документов содержал требования к криптографическим алгоритмам для соответствующего протокола. В настоящее время эти спецификации заменены документами [AH] и [ESP], которые не содержат требований к реализации криптографических алгоритмов. В настоящем документе указаны такие требования для обоих протоколов — [AH] и [ESP].

Сравнение требований приведено ниже.

Старое требование Старый RFC Новое требование Алгоритм
MUST — требуется 2406 SHOULD NOT — не следует DES-CBC [RFC2405]
MUST — требуется 2402, 2406 MAY — возможно HMAC-MD5-96 [RFC2403]
MUST — требуется 2402, 2406 MUST — требуется HMAC-SHA1-96 [RFC2404]

7. Нормативные документы

[AH] S. Kent, «Идентификационный заголовок IP», RFC 4302, Декабрь 2005
[ESP] S. Kent, «Инкапсуляция защищенных данных IP (ESP)», RFC 4303, Декабрь 2005.
[IPsec] S. Kent, «Security Architecture for the Internet Protocol», RFC 4301, Декабрь 2005.
[RFC2119] S. Bradner, «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, Март 1997.
[RFC2403] C. Madson and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, Ноябрь 1998.
[RFC2404] C. Madson and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, Ноябрь 1998.
[RFC2405] C. Madson and N. Doraswamy, «The ESP DES-CBC Cipher Algorithm With Explicit IV», RFC 2405, Ноябрь 1998.
[RFC3566] S. Frankel and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, Сентябрь 2003.
[RFC3602] S. Franke, R. Glenn, S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, Сентябрь 2003.
[RFC3686] R. Housley, «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, Январь 2004.

8. Дополнительная литература

[802.11i] LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Medium Access Control (MAC) Security Enhancements, IEEE Std 802.11i, Июнь 2004.
[JIS] J. Schiller, «Криптографические алгоритмы для использования с IKEv2», RFC 4307, Декабрь 2005.
[CCM] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, Январь 2004.
[IKEv2] C. Kaufman, «Протокол IKEv2», RFC 4306, Декабрь 2005.
[RFC791] J. Postel, «Internet Protocol», STD 5, RFC 791, Сентябрь 1981.
[RFC2402] S. Kent and R. Atkinson, «IP Authentication Header», RFC 2402, Ноябрь 1998.
[RFC2406] S Kent and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, Ноябрь 1998.
[RFC2407] D. Piper, «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, Ноябрь 1998.
[RFC2409] D. Harkins and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, Ноябрь 1998.

Адрес автора

Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-786-7554 (w) +1-508-634-2066 (h)
EMail: moc.alorotom@ekaltsae.dlanod

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