Перевод RFC 4307

Network Working Group J. Schiller

Request for Comments: 4307 Massachusetts Institute of Technology Category: Standards Track December 2005

Криптографические алгоритмы для использования с IKEv2

Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

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

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

Авторские права

Тезисы

Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения защиты информации. Протоколы IKE¹ (RFC 2409) и IKEv2 обеспечивают механизм согласования алгоритма, который должен использоваться для данного соединения (association). Однако для обеспечения интероперабельности между независимыми реализациями необходимо задать набор обязательных для реализации алгоритмов, чтобы по крайней мере один алгоритм поддерживался всеми реализациями. В этом документе определяется набор алгоритмов, являющихся обязательными для реализации, как часть IKEv2, а также алгоритмы, которые следует реализовать потому, что они могут стать обязательными в будущем.

1. Введение

Протокол IKE обеспечивает согласование криптографических алгоритмов между конечными точками криптографической ассоциации². Различные реализации IPsec и IKE могут поддерживать разные алгоритмы. Однако IETF желает обеспечить между всеми реализациями тот или иной вариант интероперабельности. В частности, требуется, чтобы протокол IKE определял набор обязательных для реализации алгоритмов, поскольку сам протокол IKE использует такие алгоритмы как часть процесса согласования. По этой причине некий набор алгоритмов требуется задать в качестве обязательного для реализации в IKE.

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

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

В идеальном варианте алгоритмы, обязательные завтра для реализации, уже доступны сегодня в большинстве реализаций 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-.

¹Internet Key Exchange – обмен ключами в Internet ²Шифрованное соединение. Прим. перев.

rfc.com.ru

Перевод RFC 4307

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

3.1. Выбор алгоритма IKEv2 Algorithm

3.1.1. Алгоритмы шифрования данных

Шифрование данных IKEv2 требует как алгоритма обеспечения конфиденциальности, так и алгоритма обеспечения целостности. Для обеспечения конфиденциальности реализация должна (MUST-) поддерживать 3DES-CBC и следует (SHOULD+0 также поддерживать AES-128-CBC. Для обеспечения целостности должен поддерживаться алгоритм HMAC-SHA1.

3.1.2. Группы Diffie-Hellman

Существует несколько групп MODP³, определенных для использования в IKEv2. Эти группы определены как в базовом документе [IKEv2], так и в документе, посвященном расширениям MODP. Группы идентифицируются номерами. Все группы, не указанные здесь, рассматриваются как возможные для реализации.

Номер группы

Длина в битах

1024

Статус

MUST-

Документ

[RFC2409]

2048

SHOULD+ [RFC3526]

3.1.3. Алгоритмы преобразования IKEv2 типа 1

IKEv2 определяет несколько алгоритмов для Transfer Type 1 (шифрование). Ниже эти алгоритмы перечислены с указанием статуса для каждого.

Имя

Номер

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


	Резерв	0
	ENCR_3DES	3
	ENCR_NULL	11

[RFC2451] [RFC2410]

MUST-MAY

ENCR_AES_CBC ENCR_AES_CTR

12 13

[AES-CBC] [AES-CTR]

SHOULD+ SHOULD

3.1.4. Алгоритмы преобразования IKEv2 типа 2

Алгоритмы Transfer Type 2 являются псевдо-случайными функциями для генерации случайных значений.

Имя

Номер Документ Статус


Резерв	0
PRF_HMAC_MD5	1	[RFC2104]	MAY
PRF_HMAC_SHA1	2	[RFC2104]	MUST
PRF_AES128_CBC	4	[AESPRF]	SHOULD+

3.1.5. Алгоритмы преобразования IKEv2 типа 3

Алгоритмы Transfer Type 3 служат для обеспечения целостности и защищают данные от подделки.

Имя Номер

NONE 0

AUTH_HMAC_MD5_96 1

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

[RFC2403]

MAY

AUTH_HMAC_SHA1_96 2 AUTH_AES_XCBC_96 5

[RFC2404] MUST [AES-MAC] SHOULD+

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

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

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

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

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

³Modular Exponential

rfc.com.ru

моульная экспоненциальная.

rfc.com.ru

Перевод RFC 4307

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119⁴, March 1997.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.

[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.

[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.

[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.

Адрес автора

Jeffrey I. Schiller

Massachusetts Institute of Technology

Room W92-190

77 Massachusetts Avenue

Cambridge, MA 02139-4307

USA

Phone: +1 (617) 253-0161

EMail: jis@mit.edu

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

BiLiM Systems nmalykh@bilim.com тел. (812) 4490770

Полное заявление авторских прав

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

⁴Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 3

rfc.com.ru


	На главную

	Network Working Group J. Schiller Request for Comments: 4307 Massachusetts Institute of Technology Category: Standards Track December 2005 Криптографические алгоритмы для использования с IKEv2 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) *Статус документа* В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе "Internet Official Protocol Standards" (STD 1). Данный документ может распространяться свободно. *Авторские права* Copyright (C) The Internet Society (2005). *Тезисы* Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения защиты информации. Протоколы IKE¹ (RFC 2409) и IKEv2 обеспечивают механизм согласования алгоритма, который должен использоваться для данного соединения (association). Однако для обеспечения интероперабельности между независимыми реализациями необходимо задать набор обязательных для реализации алгоритмов, чтобы по крайней мере один алгоритм поддерживался всеми реализациями. В этом документе определяется набор алгоритмов, являющихся обязательными для реализации, как часть IKEv2, а также алгоритмы, которые следует реализовать потому, что они могут стать обязательными в будущем. *1. Введение* Протокол IKE обеспечивает согласование криптографических алгоритмов между конечными точками криптографической ассоциации². Различные реализации IPsec и IKE могут поддерживать разные алгоритмы. Однако IETF желает обеспечить между всеми реализациями тот или иной вариант интероперабельности. В частности, требуется, чтобы протокол IKE определял набор обязательных для реализации алгоритмов, поскольку сам протокол IKE использует такие алгоритмы как часть процесса согласования. По этой причине некий набор алгоритмов требуется задать в качестве обязательного для реализации в IKE. В криптографии постоянно появляются новые алгоритмы, а существующие подвергаются непрерывным атакам. Алгоритм, представляющийся сегодня достаточно сильным, может завтра обнаружить свою слабость. По этой причине выбор обязательных для реализации алгоритмов должен быть достаточно осторожным, чтобы снизить вероятность компрометации выбранных алгоритмов в течение короткого времени. Следует также принимать во внимание производительность, поскольку многие используют IPsec в средах, где производительность имеет большое значение. Наконец, следует принимать во внимание, что обязательные для реализации алгоритмы могут изменяться с течением времени для адаптации к меняющимся условиям. По этой причине выбор обязательных для реализации алгоритмов был удален из спецификации протокола IKEv2 и помещен в данный документ. При изменении набора обязательных алгоритмов требуется обновить лишь данный документ. В идеальном варианте алгоритмы, обязательные завтра для реализации, уже доступны сегодня в большинстве реализаций 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-.

	¹Internet Key Exchange – обмен ключами в Internet ²Шифрованное соединение. Прим. перев. rfc.com.ru		rfc.com.ru



	Перевод RFC 4307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119⁴, March 1997. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. [AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004. [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003. *Адрес автора* Jeffrey I. Schiller Massachusetts Institute of Technology Room W92-190 77 Massachusetts Avenue Cambridge, MA 02139-4307 USA Phone: +1 (617) 253-0161 EMail: jis@mit.edu

	Перевод на русский язык Николай Малых BiLiM Systems nmalykh@bilim.com тел. (812) 4490770 *Полное заявление авторских прав* Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

	*Интеллектуальная собственность* The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. *Подтверждение* Финансирование функций RFC Editor обеспечено Internet Society.

	⁴Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 3	rfc.com.ru