1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Network Working Group P. Hoffman
Request for Comments: 4308 VPN Consortium
Category: Standards Track December 2005
<span class="h1">Cryptographic Suites for IPsec</span>
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 IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on
security algorithms to provide privacy and authentication between the
initiator and responder. There are many such algorithms available,
and two IPsec systems cannot interoperate unless they are using the
same algorithms. This document specifies optional suites of
algorithms and attributes that can be used to simplify the
administration of IPsec when used in manual keying mode, with IKEv1
or with IKEv2.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document is a companion to IPsec [<a href="./rfc2401" title=""Security Architecture for the Internet Protocol"">RFC2401</a>] and its two key
exchange protocols, IKE [<a href="./rfc2409" title=""The Internet Key Exchange (IKE)"">RFC2409</a>] and IKEv2 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>]. Like most
security protocols, IPsec, IKE, and IKEv2 allow users to chose which
cryptographic algorithms they want to use to meet their security
needs.
Implementation experience with IPsec in manual key mode and with IKE
has shown that there are so many choices for typical system
administrators to make that it is difficult to achieve
interoperability without careful pre-agreement. Because of this, the
IPsec Working Group agreed that there should be a small number of
named suites that cover typical security policies. These suites may
be presented in the administrative interface of the IPsec system.
These suites, often called "UI suites" ("user interface suites"), are
optional and do not prevent implementers from allowing individual
selection of the security algorithms.
<span class="grey">Hoffman Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
Although the UI suites listed here are optional to implement, this
document is on the standards track because implementers who call
particular suites by the names used here have to conform to the
suites listed in this document. These suites should not be
considered extensions to IPsec, IKE, and IKEv2, but instead
administrative methods for describing sets of configurations.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. UI Suites</span>
This section lists optional, non-mandatory suites that may be
presented to system administrators to ease the burden of choosing
among the many options in IPsec systems. These suites cannot cover
all of the options that an administrator needs to select. Instead,
they give values for a subset of the options.
Note that these UI suites are simply collections of values for some
options in IPsec. Use of UI suites does not change the IPsec, IKE,
or IKEv2 protocols in any way. Specifically, the transform
substructure in IKE and IKEv2 must be used to give the value for each
specified option regardless of whether or not UI suites are used.
Implementations that use UI suites SHOULD also provide a management
interface for specifying values for individual cryptographic options.
That is, it is unlikely that UI suites are a complete solution for
matching the security policies of many IPsec users, and therefore an
interface that gives a more complete set of options should be used as
well.
IPsec implementations that use these UI suites SHOULD use the suite
names listed here. IPsec implementations SHOULD NOT use names
different than those listed here for the suites that are described,
and MUST NOT use the names listed here for suites that do not match
these values. These requirements are necessary for interoperability.
Note that the suites listed here are for use of IPsec in virtual
private networks. Other uses of IPsec will probably want to define
their own suites and give them different names.
Additional suites can be defined by RFCs. The strings used to
identify UI suites are registered by IANA.
<span class="grey">Hoffman Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Suite "VPN-A"</span>
This suite matches the commonly used corporate VPN security used in
IKEv1 at the time of this document's publication.
IPsec:
Protocol Encapsulating Security Payload (ESP) [<a href="./rfc2406" title=""IP Encapsulating Security Payload (ESP)"">RFC2406</a>]
ESP encryption TripleDES in CBC mode [<a href="./rfc2451" title=""The ESP CBC-Mode Cipher Algorithms"">RFC2451</a>]
ESP integrity HMAC-SHA1-96 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>]
IKE and IKEv2:
Encryption TripleDES in CBC mode [<a href="./rfc2451" title=""The ESP CBC-Mode Cipher Algorithms"">RFC2451</a>]
Pseudo-random function HMAC-SHA1 [<a href="./rfc2104" title=""HMAC: Keyed-Hashing for Message Authentication"">RFC2104</a>]
Integrity HMAC-SHA1-96 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>]
Diffie-Hellman group 1024-bit Modular Exponential (MODP) [<a href="./rfc2409" title=""The Internet Key Exchange (IKE)"">RFC2409</a>]
Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST
be supported by both parties in this suite. The initiator of this
exchange MAY include a new Diffie-Hellman key; if it is included, it
MUST be of type 1024-bit MODP. If the initiator of the exchange
includes a Diffie-Hellman key, the responder MUST include a Diffie-
Hellman key, and it MUST of type 1024-bit MODP.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Suite "VPN-B"</span>
This suite is what many people expect the commonly used corporate VPN
security that will be used within a few years of the time this
document's publication.
IPsec:
Protocol ESP [<a href="./rfc2406" title=""IP Encapsulating Security Payload (ESP)"">RFC2406</a>]
ESP encryption AES with 128-bit keys in CBC mode [<a href="#ref-AES-CBC" title=""The AES-CBC Cipher Algorithm and Its Use with IPsec"">AES-CBC</a>]
ESP integrity AES-XCBC-MAC-96 [<a href="#ref-AES-XCBC-MAC" title=""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"">AES-XCBC-MAC</a>]
IKE and IKEv2:
Encryption AES with 128-bit keys in CBC mode [<a href="#ref-AES-CBC" title=""The AES-CBC Cipher Algorithm and Its Use with IPsec"">AES-CBC</a>]
Pseudo-random function AES-XCBC-PRF-128 [<a href="#ref-AES-XCBC-PRF-128" title=""The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)"">AES-XCBC-PRF-128</a>]
Integrity AES-XCBC-MAC-96 [<a href="#ref-AES-XCBC-MAC" title=""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"">AES-XCBC-MAC</a>]
Diffie-Hellman group 2048-bit MODP [<a href="./rfc3526" title=""More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)"">RFC3526</a>]
Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST
be supported by both parties in this suite. The initiator of this
exchange MAY include a new Diffie-Hellman key; if it is included, it
MUST be of type 2048-bit MODP. If the initiator of the exchange
includes a Diffie-Hellman key, the responder MUST include a Diffie-
Hellman key, and it MUST of type 2048-bit MODP.
<span class="grey">Hoffman Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Lifetimes for IKEv1</span>
IKEv1 has two security parameters that do not appear in IKEv2,
namely, the lifetime of the Phase 1 and Phase 2 security associations
(SAs). Systems that use IKEv1 with either the VPN-A or VPN-B suites
MUST use an SA lifetime of 86400 seconds (1 day) for Phase 1 and an
SA lifetime of 28800 seconds (8 hours) for Phase 2.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Acknowledgements</span>
Much of the text and ideas in this document came from earlier
versions of the IKEv2 document edited by Charlie Kaufman. Other text
and ideas were contributed by other members of the IPsec Working
Group.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document inherits all of the security considerations of the
IPsec, IKE, and IKEv2 documents.
Some of the security options specified in these suites may be found
in the future to have properties significantly weaker than those that
were believed at the time this document was produced.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
IANA has created and will maintain a registry called, "Cryptographic
Suites for IKEv1, IKEv2, and IPsec". The registry consists of a text
string and an RFC number that lists the associated transforms. New
entries can be added to the registry only after RFC publication and
approval by an expert designated by the IESG.
The initial values for the new registry are:
Identifier Defined in
VPN-A <a href="./rfc4308">RFC 4308</a>
VPN-B <a href="./rfc4308">RFC 4308</a>
<span class="grey">Hoffman Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Normative References</span>
[<a id="ref-AES-CBC">AES-CBC</a>] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", <a href="./rfc3602">RFC</a>
<a href="./rfc3602">3602</a>, September 2003.
[<a id="ref-AES-XCBC-MAC">AES-XCBC-MAC</a>] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", <a href="./rfc3566">RFC 3566</a>,
September 2003.
[<a id="ref-AES-XCBC-PRF-128">AES-XCBC-PRF-128</a>] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for
the Internet Key Exchange Protocol (IKE)", <a href="./rfc3664">RFC</a>
<a href="./rfc3664">3664</a>, January 2004.
[<a id="ref-IKEv2">IKEv2</a>] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", <a href="./rfc4306">RFC 4306</a>, December 2005.
[<a id="ref-RFC2104">RFC2104</a>] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", <a href="./rfc2104">RFC</a>
<a href="./rfc2104">2104</a>, February 1997.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
March 1997.
[<a id="ref-RFC2401">RFC2401</a>] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November
1998.
[<a id="ref-RFC2404">RFC2404</a>] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", <a href="./rfc2404">RFC 2404</a>, November 1998.
[<a id="ref-RFC2406">RFC2406</a>] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
[<a id="ref-RFC2409">RFC2409</a>] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.
[<a id="ref-RFC2451">RFC2451</a>] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", <a href="./rfc2451">RFC 2451</a>, November 1998.
[<a id="ref-RFC3526">RFC3526</a>] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)", <a href="./rfc3526">RFC 3526</a>, May 2003.
<span class="grey">Hoffman Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
Author's Address
Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
USA
EMail: paul.hoffman@vpnc.org
<span class="grey">Hoffman Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4308">RFC 4308</a> Cryptographic Suites for IPsec December 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Hoffman Standards Track [Page 7]
</pre>
|
