- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt
1
2
3
4
5
6
7 Network Working Group                                        J. Schiller
8 Request for Comments: 4307         Massachusetts Institute of Technology
9 Category: Standards Track                                  December 2005
10
11
12                 Cryptographic Algorithms for Use in the
13                 Internet Key Exchange Version 2 (IKEv2)
14
15 Status of This Memo
16
17    This document specifies an Internet standards track protocol for the
18    Internet community, and requests discussion and suggestions for
19    improvements.  Please refer to the current edition of the "Internet
20    Official Protocol Standards" (STD 1) for the standardization state
21    and status of this protocol.  Distribution of this memo is unlimited.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2005).
26
27 Abstract
28
29    The IPsec series of protocols makes use of various cryptographic
30    algorithms in order to provide security services.  The Internet Key
31    Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
32    which algorithms should be used in any given association.  However,
33    to ensure interoperability between disparate implementations, it is
34    necessary to specify a set of mandatory-to-implement algorithms to
35    ensure that there is at least one algorithm that all implementations
36    will have available.  This document defines the current set of
37    algorithms that are mandatory to implement as part of IKEv2, as well
38    as algorithms that should be implemented because they may be promoted
39    to mandatory at some future time.
40
41 1.  Introduction
42
43    The Internet Key Exchange protocol provides for the negotiation of
44    cryptographic algorithms between both endpoints of a cryptographic
45
46    association.  Different implementations of IPsec and IKE may provide
47    different algorithms.  However, the IETF desires that all
48    implementations should have some way to interoperate.  In particular,
49    this requires that IKE define a set of mandatory-to-implement
50    algorithms because IKE itself uses such algorithms as part of its own
51    negotiations.  This requires that some set of algorithms be specified
52    as "mandatory-to-implement" for IKE.
53
54
55
56
57
58 Schiller                    Standards Track                     [Page 1]
59 \f
60 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
61
62
63    The nature of cryptography is that new algorithms surface
64    continuously and existing algorithms are continuously attacked.  An
65    algorithm believed to be strong today may be demonstrated to be weak
66    tomorrow.  Given this, the choice of mandatory-to-implement algorithm
67    should be conservative so as to minimize the likelihood of it being
68    compromised quickly.  Thought should also be given to performance
69    considerations as many uses of IPsec will be in environments where
70    performance is a concern.
71
72    Finally, we need to recognize that the mandatory-to-implement
73    algorithm(s) may need to change over time to adapt to the changing
74    world.  For this reason, the selection of mandatory-to-implement
75    algorithms was removed from the main IKEv2 specification and placed
76    in this document.  As the choice of algorithm changes, only this
77    document should need to be updated.
78
79    Ideally, the mandatory-to-implement algorithm of tomorrow should
80    already be available in most implementations of IPsec by the time it
81    is made mandatory.  To facilitate this, we will attempt to identify
82    those algorithms (that are known today) in this document.  There is
83    no guarantee that the algorithms we believe today may be mandatory in
84    the future will in fact become so.  All algorithms known today are
85    subject to cryptographic attack and may be broken in the future.
86
87 2.  Requirements Terminology
88
89    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
90    "MAY" that appear in this document are to be interpreted as described
91    in [RFC2119].
92
93    We define some additional terms here:
94
95    SHOULD+    This term means the same as SHOULD.  However, it is likely
96               that an algorithm marked as SHOULD+ will be promoted at
97               some future time to be a MUST.
98
99    SHOULD-    This term means the same as SHOULD.  However, an algorithm
100               marked as SHOULD- may be deprecated to a MAY in a future
101               version of this document.
102
103    MUST-      This term means the same as MUST.  However, we expect at
104               some point that this algorithm will no longer be a MUST in
105               a future document.  Although its status will be determined
106               at a later time, it is reasonable to expect that if a
107               future revision of a document alters the status of a MUST-
108               algorithm, it will remain at least a SHOULD or a SHOULD-.
109
110
111
112
113
114 Schiller                    Standards Track                     [Page 2]
115 \f
116 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
117
118
119 3.  Algorithm Selection
120
121 3.1.  IKEv2 Algorithm Selection
122
123 3.1.1.  Encrypted Payload Algorithms
124
125    The IKEv2 Encrypted Payload requires both a confidentiality algorithm
126    and an integrity algorithm.  For confidentiality, implementations
127    MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC.  For
128    integrity, HMAC-SHA1 MUST be implemented.
129
130 3.1.2.  Diffie-Hellman Groups
131
132    There are several Modular Exponential (MODP) groups that are defined
133    for use in IKEv2.  They are defined in both the [IKEv2] base document
134    and in the MODP extensions document.  They are identified by group
135    number.  Any groups not listed here are considered as "MAY be
136    implemented".
137
138       Group Number        Bit Length            Status     Defined
139       2                   1024 MODP Group       MUST-      [RFC2409]
140       14                  2048 MODP Group       SHOULD+    [RFC3526]
141
142 3.1.3.  IKEv2 Transform Type 1 Algorithms
143
144    IKEv2 defines several possible algorithms for Transfer Type 1
145    (encryption).  These are defined below with their implementation
146    status.
147
148       Name                     Number    Defined In      Status
149       RESERVED                 0
150       ENCR_3DES                3         [RFC2451]       MUST-
151       ENCR_NULL                11        [RFC2410]       MAY
152       ENCR_AES_CBC             12        [AES-CBC]       SHOULD+
153       ENCR_AES_CTR             13        [AES-CTR]       SHOULD
154
155 3.1.4.  IKEv2 Transform Type 2 Algorithms
156
157    Transfer Type 2 Algorithms are pseudo-random functions used to
158    generate random values when needed.
159
160       Name                Number     Defined In   Status
161       RESERVED            0
162       PRF_HMAC_MD5        1          [RFC2104]    MAY
163       PRF_HMAC_SHA1       2          [RFC2104]    MUST
164       PRF_AES128_CBC      4          [AESPRF]     SHOULD+
165
166
167
168
169
170 Schiller                    Standards Track                     [Page 3]
171 \f
172 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
173
174
175 3.1.5.  IKEv2 Transform Type 3 Algorithms
176
177    Transfer Type 3 Algorithms are Integrity algorithms used to protect
178    data against tampering.
179
180       Name                     Number       Defined In           Status
181       NONE                     0
182       AUTH_HMAC_MD5_96         1            [RFC2403]            MAY
183       AUTH_HMAC_SHA1_96        2            [RFC2404]            MUST
184       AUTH_AES_XCBC_96         5            [AES-MAC]            SHOULD+
185
186 4.  Security Considerations
187
188    The security of cryptographic-based systems depends on both the
189    strength of the cryptographic algorithms chosen and the strength of
190    the keys used with those algorithms.  The security also depends on
191    the engineering of the protocol used by the system to ensure that
192    there are no non-cryptographic ways to bypass the security of the
193    overall system.
194
195    This document concerns itself with the selection of cryptographic
196    algorithms for the use of IKEv2, specifically with the selection of
197    "mandatory-to-implement" algorithms.  The algorithms identified in
198    this document as "MUST implement" or "SHOULD implement" are not known
199    to be broken at the current time, and cryptographic research so far
200    leads us to believe that they will likely remain secure into the
201    foreseeable future.  However, this isn't necessarily forever.  We
202    would therefore expect that new revisions of this document will be
203    issued from time to time that reflect the current best practice in
204    this area.
205
206 5.  Normative References
207
208    [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
209                 (IKE)", RFC 2409, November 1998.
210
211    [IKEv2]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
212                 Protocol", RFC 4306, December 2005.
213
214    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
215                 Requirement Levels", BCP 14, RFC 2119, March 1997.
216
217    [RFC3526]    Kivinen, T. and M. Kojo, "More Modular Exponential
218                 (MODP) Diffie-Hellman groups for Internet Key Exchange
219                 (IKE)", RFC 3526, May 2003.
220
221    [RFC2451]    Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
222                 Algorithms", RFC 2451, November 1998.
223
224
225
226 Schiller                    Standards Track                     [Page 4]
227 \f
228 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
229
230
231    [RFC2410]    Glenn, R. and S. Kent, "The NULL Encryption Algorithm
232                 and Its Use With IPsec", RFC 2410, November 1998.
233
234    [AES-CBC]    Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
235                 Cipher Algorithm and Its Use with IPsec", RFC 3602,
236                 September 2003.
237
238    [AES-CTR]    Housley, R., "Using Advanced Encryption Standard (AES)
239                 Counter Mode With IPsec Encapsulating Security Payload
240                 (ESP)", RFC 3686, January 2004.
241
242    [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
243                 Keyed-Hashing for Message Authentication", RFC 2104,
244                 February 1997.
245
246    [AESPRF]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
247                 Internet Key Exchange Protocol (IKE)", RFC 3664, January
248                 2004.
249
250    [RFC2403]    Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
251                 ESP and AH", RFC 2403, November 1998.
252
253    [RFC2404]    Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
254                 within ESP and AH", RFC 2404, November 1998.
255
256    [AES-MAC]    Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
257                 Algorithm and Its Use With IPsec", RFC 3566, September
258                 2003.
259
260 Author's Address
261
262    Jeffrey I. Schiller
263    Massachusetts Institute of Technology
264    Room W92-190
265    77 Massachusetts Avenue
266    Cambridge, MA 02139-4307
267    USA
268
269    Phone: +1 (617) 253-0161
270    EMail: jis@mit.edu
271
272
273
274
275
276
277
278
279
280
281
282 Schiller                    Standards Track                     [Page 5]
283 \f
284 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
285
286
287 Full Copyright Statement
288
289    Copyright (C) The Internet Society (2005).
290
291    This document is subject to the rights, licenses and restrictions
292    contained in BCP 78, and except as set forth therein, the authors
293    retain all their rights.
294
295    This document and the information contained herein are provided on an
296    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
297    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
298    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
299    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
300    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
301    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
302
303 Intellectual Property
304
305    The IETF takes no position regarding the validity or scope of any
306    Intellectual Property Rights or other rights that might be claimed to
307    pertain to the implementation or use of the technology described in
308    this document or the extent to which any license under such rights
309    might or might not be available; nor does it represent that it has
310    made any independent effort to identify any such rights.  Information
311    on the procedures with respect to rights in RFC documents can be
312    found in BCP 78 and BCP 79.
313
314    Copies of IPR disclosures made to the IETF Secretariat and any
315    assurances of licenses to be made available, or the result of an
316    attempt made to obtain a general license or permission for the use of
317    such proprietary rights by implementers or users of this
318    specification can be obtained from the IETF on-line IPR repository at
319    http://www.ietf.org/ipr.
320
321    The IETF invites any interested party to bring to its attention any
322    copyrights, patents or patent applications, or other proprietary
323    rights that may cover technology that may be required to implement
324    this standard.  Please address the information to the IETF at ietf-
325    ipr@ietf.org.
326
327 Acknowledgement
328
329    Funding for the RFC Editor function is currently provided by the
330    Internet Society.
331
332
333
334
335
336
337
338 Schiller                    Standards Track                     [Page 6]
339 \f