分享
 
 
 

RFC4109 - Algorithms for Internet Key Exchange version 1 (IKEv1)

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group P. Hoffman

Request for Comments: 4109 VPN Consortium

Updates: 2409 May 2005

Category: Standards Track

Algorithms for Internet Key Exchange version 1 (IKEv1)

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

The required and suggested algorithms in the original Internet Key

Exchange version 1 (IKEv1) specification do not reflect the current

reality of the IPsec market requirements. The original specification

allows weak security and suggests algorithms that are thinly

implemented. This document updates RFC 2409, the original

specification, and is intended for all IKEv1 implementations deployed

today.

1. IntrodUCtion

The original IKEv1 definition, [RFC2409], has a set of MUST-level and

SHOULD-level requirements that do not match the needs of IPsec users.

This document updates RFC 2409 by changing the algorithm requirements

defined there.

The keyWords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,

SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this

document, are to be interpreted as described in [RFC2119].

2. Old Algorithm Requirements

RFC 2409 has the following MUST-level and SHOULD-level requirements:

o DES for encryption MUST be supported.

o MD5 and SHA-1 for hashing and HMAC functions MUST be supported.

o Pre-shared secrets for authentication MUST be supported.

o Diffie-Hellman MODP group 1 (discrete log 768 bits) MUST be

supported.

o TripleDES for encryption SHOULD be supported.

o Tiger for hashing SHOULD be supported.

o DSA and RSA for authentication with signatures SHOULD be

supported.

o RSA for authentication with encryption SHOULD be supported.

o Diffie-Hellman MODP group 2 (discrete log 1024 bits) SHOULD be

supported.

RFC 2409 gives two conflicting requirement levels for Diffie-Hellman

MODP groups with elliptic curves. Section 4 of that specification

says that "IKE implementations ... MAY support ECP and EC2N groups",

but Sections 6.3 and 6.4 say that MODP groups 3 and 4 for EC2N groups

SHOULD be supported.

3. New Algorithm Requirements

The new requirements for IKEv1 are listed here. Note that some of

the requirements are the same as those in RFC 2409, whereas others

are changed.

o TripleDES for encryption MUST be supported.

o AES-128 in CBC mode [RFC3602] for encryption SHOULD be supported.

o SHA-1 for hashing and HMAC functions MUST be supported.

o Pre-shared secrets for authentication MUST be supported.

o AES-128 in XCBC mode for PRF functions ([RFC3566] and [RFC3664])

SHOULD be supported.

o Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be

supported.

o Diffie-Hellman MODP group 14 (discrete log 2048 bits) [RFC3526]

SHOULD be supported.

o RSA for authentication with signatures SHOULD be supported.

If additional updates are made to IKEv1 in the future, then it is

very likely that implementation of AES-128 in CBC mode for encryption

will become mandatory.

The other algorithms that were listed at MUST-level and SHOULD-level

in RFC 2409 are now MAY-level. This includes DES for encryption, MD5

and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman

MODP groups with elliptic curves, DSA for authentication with

signatures, and RSA for authentication with encryption.

DES for encryption, MD5 for hashing, and Diffie-Hellman MODP group 1

are dropped to MAY due to cryptographic weakness.

Tiger for hashing, Diffie-Hellman MODP groups with elliptic curves,

DSA for authentication with signatures, and RSA for authentication

with encryption are dropped due to lack of any significant deployment

and interoperability.

4. Summary

Algorithm RFC 2409 This document

------------------------------------------------------------------

DES for encryption MUST MAY (crypto weakness)

TripleDES for encryption SHOULD MUST

AES-128 for encryption N/A SHOULD

MD5 for hashing and HMAC MUST MAY (crypto weakness)

SHA1 for hashing and HMAC MUST MUST

Tiger for hashing SHOULD MAY (lack of deployment)

AES-XCBC-MAC-96 for PRF N/A SHOULD

Pre-shared secrets MUST MUST

RSA with signatures SHOULD SHOULD

DSA with signatures SHOULD MAY (lack of deployment)

RSA with encryption SHOULD MAY (lack of deployment)

D-H Group 1 (768) MUST MAY (crypto weakness)

D-H Group 2 (1024) SHOULD MUST

D-H Group 14 (2048) N/A SHOULD

D-H elliptic curves SHOULD MAY (lack of deployment)

5. Security Considerations

This document is all about security. All the algorithms that are

either MUST-level or SHOULD-level in the "new algorithm requirements"

section of this document are believed to be robust and secure at the

time of this writing.

6. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange

(IKE)", RFC 2409, November 1998.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular EXPonential (MODP)

Diffie-Hellman groups for Internet Key Exchange (IKE)",

RFC 3526, May 2003.

[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm

and Its Use With IPsec", RFC 3566, September 2003.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher

Algorithm and Its Use with IPsec", RFC 3602, September

2003.

[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the

Internet Key Exchange Protocol (IKE)", RFC 3664, January

2004.

Author's Address

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

US

EMail: paul.hoffman@vpnc.org

Full Copyright Statement

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.

Intellectual Property

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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有