AAA

RFC 4305 — Требования к реализациям криптографических алгоритмов для ESP и AH

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

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

Тезисы

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

Оглавление

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].

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

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 — требуется2406SHOULD NOT — не следуетDES-CBC [RFC2405]
MUST — требуется2402, 2406MAY — возможноHMAC-MD5-96 [RFC2403]
MUST — требуется2402, 2406MUST — требуетсяHMAC-SHA1-96 [RFC2404]

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

  1. [AH] S. Kent, "IP Authentication Header", RFC 4302, December 2005
  2. [ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  3. [IPsec] S. Kent, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  4. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  5. [RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
  6. [RFC2404] C. Madson and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
  7. [RFC2405] C. Madson and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
  8. [RFC3566] S. Frankel and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
  9. [RFC3602] S. Franke, R. Glenn, S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
  10. [RFC3686] R. Housley, "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.

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

  1. [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, June 2004.
  2. [JIS] J. Schiller, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
  3. [CCM] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
  4. [IKEv2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  5. [RFC791] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
  6. [RFC2402] S. Kent and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  7. [RFC2406] S Kent and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  8. [RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  9. [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 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

Перевод на русский язык

Николай Малых, moc.milib@hkylamn