]>
Commit | Line | Data |
---|---|---|
71baf5a8 TB |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group D. McGrew | |
8 | Request for Comments: 4543 Cisco Systems, Inc. | |
9 | Category: Standards Track J. Viega | |
10 | McAfee, Inc. | |
11 | May 2006 | |
12 | ||
13 | ||
14 | The Use of Galois Message Authentication Code (GMAC) in | |
15 | IPsec ESP and AH | |
16 | ||
17 | Status of This Memo | |
18 | ||
19 | This document specifies an Internet standards track protocol for the | |
20 | Internet community, and requests discussion and suggestions for | |
21 | improvements. Please refer to the current edition of the "Internet | |
22 | Official Protocol Standards" (STD 1) for the standardization state | |
23 | and status of this protocol. Distribution of this memo is unlimited. | |
24 | ||
25 | Copyright Notice | |
26 | ||
27 | Copyright (C) The Internet Society (2006). | |
28 | ||
29 | Abstract | |
30 | ||
31 | This memo describes the use of the Advanced Encryption Standard (AES) | |
32 | Galois Message Authentication Code (GMAC) as a mechanism to provide | |
33 | data origin authentication, but not confidentiality, within the IPsec | |
34 | Encapsulating Security Payload (ESP) and Authentication Header (AH). | |
35 | GMAC is based on the Galois/Counter Mode (GCM) of operation, and can | |
36 | be efficiently implemented in hardware for speeds of 10 gigabits per | |
37 | second and above, and is also well-suited to software | |
38 | implementations. | |
39 | ||
40 | ||
41 | ||
42 | ||
43 | ||
44 | ||
45 | ||
46 | ||
47 | ||
48 | ||
49 | ||
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | McGrew & Viega Standards Track [Page 1] | |
59 | \f | |
60 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1. Introduction ....................................................2 | |
66 | 1.1. Conventions Used in This Document ..........................3 | |
67 | 2. AES-GMAC ........................................................3 | |
68 | 3. The Use of AES-GMAC in ESP ......................................3 | |
69 | 3.1. Initialization Vector ......................................4 | |
70 | 3.2. Nonce Format ...............................................4 | |
71 | 3.3. AAD Construction ...........................................5 | |
72 | 3.4. Integrity Check Value (ICV) ................................6 | |
73 | 3.5. Differences with AES-GCM-ESP ...............................6 | |
74 | 3.6. Packet Expansion ...........................................7 | |
75 | 4. The Use of AES-GMAC in AH .......................................7 | |
76 | 5. IKE Conventions .................................................8 | |
77 | 5.1. Phase 1 Identifier .........................................8 | |
78 | 5.2. Phase 2 Identifier .........................................8 | |
79 | 5.3. Key Length Attribute .......................................9 | |
80 | 5.4. Keying Material and Salt Values ............................9 | |
81 | 6. Test Vectors ....................................................9 | |
82 | 7. Security Considerations ........................................10 | |
83 | 8. Design Rationale ...............................................11 | |
84 | 9. IANA Considerations ............................................11 | |
85 | 10. Acknowledgements ..............................................11 | |
86 | 11. References ....................................................12 | |
87 | 11.1. Normative References .....................................12 | |
88 | 11.2. Informative References ...................................12 | |
89 | 1. Introduction | |
90 | ||
91 | This document describes the use of AES-GMAC mode (AES-GMAC) as a | |
92 | mechanism for data origin authentication in ESP [RFC4303] and AH | |
93 | [RFC4302]. We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and | |
94 | AUTH_AES_GMAC, respectively. ENCR_NULL_AUTH_AES_GMAC is a companion | |
95 | to the AES Galois/Counter Mode ESP [RFC4106], which provides | |
96 | authentication as well as confidentiality. ENCR_NULL_AUTH_AES_GMAC | |
97 | is intended for cases in which confidentiality is not desired. Like | |
98 | GCM, GMAC is efficient and secure, and is amenable to high-speed | |
99 | implementations in hardware. ENCR_NULL_AUTH_AES_GMAC and | |
100 | AUTH_AES_GMAC are designed so that the incremental cost of | |
101 | implementation, given an implementation is AES-GCM-ESP, is small. | |
102 | ||
103 | This document does not cover implementation details of GCM or GMAC. | |
104 | Those details can be found in [GCM], along with test vectors. | |
105 | ||
106 | ||
107 | ||
108 | ||
109 | ||
110 | ||
111 | ||
112 | ||
113 | ||
114 | McGrew & Viega Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
117 | ||
118 | ||
119 | 1.1. Conventions Used in This Document | |
120 | ||
121 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
122 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
123 | document are to be interpreted as described in [RFC2119]. | |
124 | ||
125 | 2. AES-GMAC | |
126 | ||
127 | GMAC is a block cipher mode of operation providing data origin | |
128 | authentication. It is defined in terms of the GCM authenticated | |
129 | encryption operation as follows. The GCM authenticated encryption | |
130 | operation has four inputs: a secret key, an initialization vector | |
131 | (IV), a plaintext, and an input for additional authenticated data | |
132 | (AAD). It has two outputs, a ciphertext whose length is identical to | |
133 | the plaintext and an authentication tag. GMAC is the special case of | |
134 | GCM in which the plaintext has a length of zero. The (zero-length) | |
135 | ciphertext output is ignored, of course, so that the only output of | |
136 | the function is the Authentication Tag. In the following, we | |
137 | describe how the GMAC IV and AAD are formed from the ESP and AH | |
138 | fields, and how the ESP and AH packets are formed from the | |
139 | Authentication Tag. | |
140 | ||
141 | Below we refer to the AES-GMAC IV input as a nonce, in order to | |
142 | distinguish it from the IV fields in the packets. The same nonce and | |
143 | key combination MUST NOT be used more than once, since reusing a | |
144 | nonce/key combination destroys the security guarantees of AES-GMAC. | |
145 | ||
146 | Because of this restriction, it can be difficult to use this mode | |
147 | securely when using statically configured keys. For the sake of good | |
148 | security, implementations MUST use an automated key management | |
149 | system, such as the Internet Key Exchange (IKE) (either version two | |
150 | [RFC4306] or version one [RFC2409]), to ensure that this requirement | |
151 | is met. | |
152 | ||
153 | 3. The Use of AES-GMAC in ESP | |
154 | ||
155 | The AES-GMAC algorithm for ESP is defined as an ESP "combined mode" | |
156 | algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP | |
157 | integrity algorithm. It is called ENCR_NULL_AUTH_AES_GMAC to | |
158 | highlight the fact that it performs no encryption and provides no | |
159 | confidentiality. | |
160 | ||
161 | Rationale: ESP makes no provision for integrity transforms to | |
162 | place an initialization vector within the Payload field; only | |
163 | encryption transforms are expected to use IVs. Defining GMAC as | |
164 | an encryption transform avoids this issue, and allows GMAC to | |
165 | benefit from the same pipelining as does GCM. | |
166 | ||
167 | ||
168 | ||
169 | ||
170 | McGrew & Viega Standards Track [Page 3] | |
171 | \f | |
172 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
173 | ||
174 | ||
175 | Like all ESP combined modes, it is registered in IKEv2 as an | |
176 | encryption transform, or "Type 1" transform. It MUST NOT be used in | |
177 | conjunction with any other ESP encryption transform (within a | |
178 | particular ESP encapsulation). If confidentiality is desired, then | |
179 | GCM ESP [RFC4106] SHOULD be used instead. | |
180 | ||
181 | 3.1. Initialization Vector | |
182 | ||
183 | With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV) | |
184 | is included in the ESP Payload, at the outset of that field. The IV | |
185 | MUST be eight octets long. For a given key, the IV MUST NOT repeat. | |
186 | The most natural way to meet this requirement is to set the IV using | |
187 | a counter, but implementations are free to set the IV field in any | |
188 | way that guarantees uniqueness, such as a linear feedback shift | |
189 | register (LFSR). Note that the sender can use any IV generation | |
190 | method that meets the uniqueness requirement without coordinating | |
191 | with the receiver. | |
192 | ||
193 | 3.2. Nonce Format | |
194 | ||
195 | The nonce passed to the AES-GMAC authentication algorithm has the | |
196 | following layout: | |
197 | ||
198 | 0 1 2 3 | |
199 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
201 | | Salt | | |
202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
203 | | Initialization Vector | | |
204 | | | | |
205 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
206 | ||
207 | Figure 1: Nonce Format | |
208 | ||
209 | The components of the nonce are as follows: | |
210 | ||
211 | Salt | |
212 | The salt field is a four-octet value that is assigned at the | |
213 | beginning of the security association, and then remains constant | |
214 | for the life of the security association. The salt SHOULD be | |
215 | unpredictable (i.e., chosen at random) before it is selected, but | |
216 | need not be secret. We describe how to set the salt for a | |
217 | Security Association established via the Internet Key Exchange in | |
218 | Section 5.4. | |
219 | ||
220 | Initialization Vector | |
221 | The IV field is described in Section 3.1. | |
222 | ||
223 | ||
224 | ||
225 | ||
226 | McGrew & Viega Standards Track [Page 4] | |
227 | \f | |
228 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
229 | ||
230 | ||
231 | 3.3. AAD Construction | |
232 | ||
233 | Data integrity and data origin authentication are provided for the | |
234 | SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad | |
235 | Length, and Next Header fields. This is done by including those | |
236 | fields in the AES-GMAC Additional Authenticated Data (AAD) field. | |
237 | Two formats of the AAD are defined: one for 32-bit sequence numbers, | |
238 | and one for 64-bit extended sequence numbers. The format with 32-bit | |
239 | sequence numbers is shown in Figure 2, and the format with 64-bit | |
240 | extended sequence numbers is shown in Figure 3. | |
241 | ||
242 | 0 1 2 3 | |
243 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
244 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
245 | | SPI | | |
246 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
247 | | 32-bit Sequence Number | | |
248 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
249 | | | | |
250 | ~ Authenticated Payload (variable) ~ | |
251 | | | | |
252 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
253 | | Padding (0-255 bytes) | | |
254 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
255 | | | Pad Length | Next Header | | |
256 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
257 | ||
258 | Figure 2: AAD Format with 32-bit Sequence Number | |
259 | ||
260 | 0 1 2 3 | |
261 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
262 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
263 | | SPI | | |
264 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
265 | | 64-bit Extended Sequence Number | | |
266 | | | | |
267 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
268 | | | | |
269 | ~ Authenticated Payload (variable) ~ | |
270 | | | | |
271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
272 | | Padding (0-255 bytes) | | |
273 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
274 | | | Pad Length | Next Header | | |
275 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
276 | ||
277 | Figure 3: AAD Format with 64-bit Extended Sequence Number | |
278 | ||
279 | ||
280 | ||
281 | ||
282 | McGrew & Viega Standards Track [Page 5] | |
283 | \f | |
284 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
285 | ||
286 | ||
287 | The use of 32-bit sequence numbers vs. 64-bit extended sequence | |
288 | numbers is determined by the security association (SA) management | |
289 | protocol that is used to create the SA. For IKEv2 [RFC4306] this is | |
290 | negotiated via Transform Type 5, and the default for ESP is to use | |
291 | 64-bit extended sequence numbers in the absence of negotiation (e.g., | |
292 | see Section 2.2.1 of [RFC4303]). | |
293 | ||
294 | 3.4. Integrity Check Value (ICV) | |
295 | ||
296 | The ICV consists solely of the AES-GMAC Authentication Tag. The | |
297 | Authentication Tag MUST NOT be truncated, so the length of the ICV is | |
298 | 16 octets. | |
299 | ||
300 | 3.5. Differences with AES-GCM-ESP | |
301 | ||
302 | In this section, we highlight the differences between this | |
303 | specification and AES-GCM-ESP [RFC4106]. The essential difference is | |
304 | that in this document, the AAD consists of the SPI, Sequence Number, | |
305 | and ESP Payload, and the AES-GCM plaintext is zero-length, while in | |
306 | AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, | |
307 | and the AES-GCM plaintext consists of the ESP Payload. These | |
308 | differences are illustrated in Figure 4. This figure shows the case | |
309 | in which the Extended Sequence Number option is not used. When that | |
310 | option is exercised, the Sequence Number field in the figure would be | |
311 | replaced with the Extended Sequence Number. | |
312 | ||
313 | Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM- | |
314 | ESP with encryption "turned off". However, the ICV computations | |
315 | performed in both cases are similar because of the structure of the | |
316 | GHASH function [GCM]. | |
317 | ||
318 | ||
319 | ||
320 | ||
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | McGrew & Viega Standards Track [Page 6] | |
339 | \f | |
340 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
341 | ||
342 | ||
343 | +-> +-----------------------+ <-+ | |
344 | AES-GCM-ESP | | SPI | | | |
345 | AAD -------+ +-----------------------+ | | |
346 | | | Sequence Number | | | |
347 | +-> +-----------------------+ | | |
348 | | Authentication | | | |
349 | | IV | | | |
350 | +->+-> +-----------------------+ + | |
351 | AES-GCM-ESP | | | | | |
352 | Plaintext -+ ~ ESP Payload ~ | | |
353 | | | | | | |
354 | | +-----------+-----+-----+ | | |
355 | | | Padding | PL | NH | | | |
356 | +----> +-----------+-----+-----+ <-+ | |
357 | | | |
358 | ENCR_NULL_AUTH_AES_GMAC AAD --+ | |
359 | ||
360 | Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP | |
361 | ||
362 | 3.6. Packet Expansion | |
363 | ||
364 | The IV adds an additional eight octets to the packet and the ICV adds | |
365 | an additional 16 octets. These are the only sources of packet | |
366 | expansion, other than the 10-13 bytes taken up by the ESP SPI, | |
367 | Sequence Number, Padding, Pad Length, and Next Header fields (if the | |
368 | minimal amount of padding is used). | |
369 | ||
370 | 4. The Use of AES-GMAC in AH | |
371 | ||
372 | In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV | |
373 | and the Authentication Tag, as shown in Figure 5. Unlike the usual | |
374 | AH case, the Authentication Data field contains both an input to the | |
375 | authentication algorithm (the IV) and the output of the | |
376 | authentication algorithm (the tag). No padding is required in the | |
377 | Authentication Data field, because its length is a multiple of 64 | |
378 | bits. | |
379 | ||
380 | ||
381 | ||
382 | ||
383 | ||
384 | ||
385 | ||
386 | ||
387 | ||
388 | ||
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | McGrew & Viega Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
397 | ||
398 | ||
399 | 0 1 2 3 | |
400 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
401 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
402 | | Initialization Vector (IV) | | |
403 | | (8 octets) | | |
404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
405 | | | | |
406 | | Integrity Check Value (ICV) (16 octets) | | |
407 | | | | |
408 | | | | |
409 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
410 | ||
411 | Figure 5: The AUTH_AES_GMAC Authentication Data Format | |
412 | ||
413 | The IV is as described in Section 3.1. The Integrity Check Value | |
414 | (ICV) is as described in Section 3.4. | |
415 | ||
416 | The GMAC Nonce input is formed as described in Section 3.2. The GMAC | |
417 | AAD input consists of the authenticated data as defined in Section | |
418 | 3.1 of [RFC4302]. These values are provided as to that algorithm, | |
419 | along with the secret key, and the resulting authentication tag given | |
420 | as output is used to form the ICV. | |
421 | ||
422 | 5. IKE Conventions | |
423 | ||
424 | This section describes the conventions used to generate keying | |
425 | material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and | |
426 | AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one | |
427 | [RFC2409] and two [RFC4306]. | |
428 | ||
429 | 5.1. Phase 1 Identifier | |
430 | ||
431 | This document does not specify the conventions for using AES-GMAC for | |
432 | IKE Phase 1 negotiations. For AES-GMAC to be used in this manner, a | |
433 | separate specification would be needed, and an Encryption Algorithm | |
434 | Identifier would need to be assigned. Implementations SHOULD use an | |
435 | IKE Phase 1 cipher that is at least as strong as AES-GMAC. The use | |
436 | of AES-CBC [RFC3602] with the same AES key size as used by | |
437 | ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED. | |
438 | ||
439 | 5.2. Phase 2 Identifier | |
440 | ||
441 | For IKE Phase 2 negotiations, IANA has assigned identifiers as | |
442 | described in Section 9. | |
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | McGrew & Viega Standards Track [Page 8] | |
451 | \f | |
452 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
453 | ||
454 | ||
455 | 5.3. Key Length Attribute | |
456 | ||
457 | AES-GMAC can be used with any of the three AES key lengths. The way | |
458 | that the key length is indicated is different for AH and ESP. | |
459 | ||
460 | For AH, each key length has its own separate integrity transform | |
461 | identifier and algorithm name (Section 9). The IKE Key Length | |
462 | attribute MUST NOT be used with these identifiers. This transform | |
463 | MUST NOT be used with ESP. | |
464 | ||
465 | For ESP, there is a single encryption transform identifier (which | |
466 | represents the combined transform) (Section 9). The IKE Key Length | |
467 | attribute MUST be used with each use of this identifier to indicate | |
468 | the key length. The Key Length attribute MUST have a value of 128, | |
469 | 192, or 256. | |
470 | ||
471 | 5.4. Keying Material and Salt Values | |
472 | ||
473 | IKE makes use of a pseudo-random function (PRF) to derive keying | |
474 | material. The PRF is used iteratively to derive keying material of | |
475 | arbitrary size, called KEYMAT. Keying material is extracted from the | |
476 | output string without regard to boundaries. | |
477 | ||
478 | The size of the KEYMAT for the ENCR_NULL_AUTH_AES_GMAC and | |
479 | AUTH_AES_GMAC MUST be four octets longer than is needed for the | |
480 | associated AES key. The keying material is used as follows: | |
481 | ||
482 | ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC | |
483 | The KEYMAT requested for each AES-GMAC key is 20 octets. The | |
484 | first 16 octets are the 128-bit AES key, and the remaining four | |
485 | octets are used as the salt value in the nonce. | |
486 | ||
487 | ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC | |
488 | The KEYMAT requested for each AES-GMAC key is 28 octets. The | |
489 | first 24 octets are the 192-bit AES key, and the remaining four | |
490 | octets are used as the salt value in the nonce. | |
491 | ||
492 | ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC | |
493 | The KEYMAT requested for each AES-GMAC key is 36 octets. The | |
494 | first 32 octets are the 256-bit AES key, and the remaining four | |
495 | octets are used as the salt value in the nonce. | |
496 | ||
497 | 6. Test Vectors | |
498 | ||
499 | Appendix B of [GCM] provides test vectors that will assist | |
500 | implementers with AES-GMAC. | |
501 | ||
502 | ||
503 | ||
504 | ||
505 | ||
506 | McGrew & Viega Standards Track [Page 9] | |
507 | \f | |
508 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
509 | ||
510 | ||
511 | 7. Security Considerations | |
512 | ||
513 | Since the authentication coverage is different between AES-GCM-ESP | |
514 | and this specification (see Figure 4), it is worth pointing out that | |
515 | both specifications are secure. In ENCR_NULL_AUTH_AES_GMAC, the IV | |
516 | is not included in either the plaintext or the additional | |
517 | authenticated data. This does not adversely affect security, because | |
518 | the IV field only provides an input to the GMAC IV, which is not | |
519 | required to be authenticated (see [GCM]). In AUTH_AES_GMAC, the IV | |
520 | is included in the additional authenticated data. This fact has no | |
521 | adverse effect on security; it follows from the property that GMAC is | |
522 | secure even against attacks in which the adversary can manipulate | |
523 | both the IV and the message. Even an adversary with these powerful | |
524 | capabilities cannot forge an authentication tag for any message | |
525 | (other than one that was submitted to the chosen-message oracle). | |
526 | Since such an adversary could easily choose messages that contain the | |
527 | IVs with which they correspond, there are no security problems with | |
528 | the inclusion of the IV in the AAD. | |
529 | ||
530 | GMAC is provably secure against adversaries that can adaptively | |
531 | choose plaintexts, ICVs and the AAD field, under standard | |
532 | cryptographic assumptions (roughly, that the output of the underlying | |
533 | cipher under a randomly chosen key is indistinguishable from a | |
534 | randomly selected output). Essentially, this means that, if used | |
535 | within its intended parameters, a break of GMAC implies a break of | |
536 | the underlying block cipher. The proof of security is available in | |
537 | [GCMP]. | |
538 | ||
539 | The most important security consideration is that the IV never | |
540 | repeats for a given key. In part, this is handled by disallowing the | |
541 | use of AES-GMAC when using statically configured keys, as discussed | |
542 | in Section 2. | |
543 | ||
544 | When IKE is used to establish fresh keys between two peer entities, | |
545 | separate keys are established for the two traffic flows. If a | |
546 | different mechanism is used to establish fresh keys, one that | |
547 | establishes only a single key to protect packets, then there is a | |
548 | high probability that the peers will select the same IV values for | |
549 | some packets. Thus, to avoid counter block collisions, ESP or AH | |
550 | implementations that permit use of the same key for protecting | |
551 | packets with the same peer MUST ensure that the two peers assign | |
552 | different salt values to the security association (SA). | |
553 | ||
554 | The other consideration is that, as with any block cipher mode of | |
555 | operation, the security of all data protected under a given security | |
556 | association decreases slightly with each message. | |
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | McGrew & Viega Standards Track [Page 10] | |
563 | \f | |
564 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
565 | ||
566 | ||
567 | To protect against this problem, implementations MUST generate a | |
568 | fresh key before processing 2^64 blocks of data with a given key. | |
569 | Note that it is impossible to reach this limit when using 32-bit | |
570 | Sequence Numbers. | |
571 | ||
572 | Note that, for each message, GMAC calls the block cipher only once. | |
573 | ||
574 | 8. Design Rationale | |
575 | ||
576 | This specification was designed to be as similar to AES-GCM-ESP | |
577 | [RFC4106] as possible. We re-use the design and implementation | |
578 | experience from that specification. We include all three AES key | |
579 | sizes since AES-GCM-ESP supports all of those sizes, and the larger | |
580 | key sizes provide future users with more high-security options. | |
581 | ||
582 | 9. IANA Considerations | |
583 | ||
584 | IANA has assigned the following IKEv2 parameters. For the use of AES | |
585 | GMAC in AH, the following integrity (type 3) transform identifiers | |
586 | have been assigned: | |
587 | ||
588 | "9" for AUTH_AES_128_GMAC | |
589 | ||
590 | "10" for AUTH_AES_192_GMAC | |
591 | ||
592 | "11" for AUTH_AES_256_GMAC | |
593 | ||
594 | For the use of AES-GMAC in ESP, the following encryption (type 1) | |
595 | transform identifier has been assigned: | |
596 | ||
597 | "21" for ENCR_NULL_AUTH_AES_GMAC | |
598 | ||
599 | 10. Acknowledgements | |
600 | ||
601 | Our discussions with Fabio Maino and David Black significantly | |
602 | improved this specification, and Tero Kivinen provided us with useful | |
603 | comments. Steve Kent provided guidance on ESP interactions. This | |
604 | work is closely modeled after AES-GCM, which itself is closely | |
605 | modeled after Russ Housley's AES-CCM transform [RFC4309]. | |
606 | Additionally, the GCM mode of operation was originally conceived as | |
607 | an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi | |
608 | Kohno participated. We express our thanks to Fabio, David, Tero, | |
609 | Steve, Russ, Doug, and Yoshi. | |
610 | ||
611 | ||
612 | ||
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | McGrew & Viega Standards Track [Page 11] | |
619 | \f | |
620 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
621 | ||
622 | ||
623 | 11. References | |
624 | ||
625 | 11.1. Normative References | |
626 | ||
627 | [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of | |
628 | Operation (GCM)", Submission to NIST. http:// | |
629 | csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ | |
630 | gcm-spec.pdf, January 2004. | |
631 | ||
632 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
633 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
634 | ||
635 | [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher | |
636 | Algorithm and Its Use with IPsec", RFC 3602, September | |
637 | 2003. | |
638 | ||
639 | 11.2. Informative References | |
640 | ||
641 | [CWC] Kohno, T., Viega, J., and D. Whiting, "CWC: A high- | |
642 | performance conventional authenticated encryption mode", | |
643 | Fast Software Encryption. | |
644 | http://eprint.iacr.org/2003/106.pdf, February 2004. | |
645 | ||
646 | [GCMP] McGrew, D. and J. Viega, "The Security and Performance of | |
647 | the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT | |
648 | '04, http://eprint.iacr.org/2004/193, December 2004. | |
649 | ||
650 | [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange | |
651 | (IKE)", RFC 2409, November 1998. | |
652 | ||
653 | [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode | |
654 | (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC | |
655 | 4106, June 2005. | |
656 | ||
657 | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December | |
658 | 2005. | |
659 | ||
660 | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | |
661 | 4303, December 2005. | |
662 | ||
663 | [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC | |
664 | 4306, December 2005. | |
665 | ||
666 | [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM | |
667 | Mode with IPsec Encapsulating Security Payload (ESP)", RFC | |
668 | 4309, December 2005. | |
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | McGrew & Viega Standards Track [Page 12] | |
675 | \f | |
676 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
677 | ||
678 | ||
679 | Authors' Addresses | |
680 | ||
681 | David A. McGrew | |
682 | Cisco Systems, Inc. | |
683 | 510 McCarthy Blvd. | |
684 | Milpitas, CA 95035 | |
685 | US | |
686 | ||
687 | Phone: (408) 525 8651 | |
688 | EMail: mcgrew@cisco.com | |
689 | URI: http://www.mindspring.com/~dmcgrew/dam.htm | |
690 | ||
691 | ||
692 | John Viega | |
693 | McAfee, Inc. | |
694 | 1145 Herndon Parkway, Suite 500 | |
695 | Herndon, VA 20170 | |
696 | ||
697 | EMail: viega@list.org | |
698 | ||
699 | ||
700 | ||
701 | ||
702 | ||
703 | ||
704 | ||
705 | ||
706 | ||
707 | ||
708 | ||
709 | ||
710 | ||
711 | ||
712 | ||
713 | ||
714 | ||
715 | ||
716 | ||
717 | ||
718 | ||
719 | ||
720 | ||
721 | ||
722 | ||
723 | ||
724 | ||
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | McGrew & Viega Standards Track [Page 13] | |
731 | \f | |
732 | RFC 4543 GMAC in IPsec ESP and AH May 2006 | |
733 | ||
734 | ||
735 | Full Copyright Statement | |
736 | ||
737 | Copyright (C) The Internet Society (2006). | |
738 | ||
739 | This document is subject to the rights, licenses and restrictions | |
740 | contained in BCP 78, and except as set forth therein, the authors | |
741 | retain all their rights. | |
742 | ||
743 | This document and the information contained herein are provided on an | |
744 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
745 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
746 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
747 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
748 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
749 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
750 | ||
751 | Intellectual Property | |
752 | ||
753 | The IETF takes no position regarding the validity or scope of any | |
754 | Intellectual Property Rights or other rights that might be claimed to | |
755 | pertain to the implementation or use of the technology described in | |
756 | this document or the extent to which any license under such rights | |
757 | might or might not be available; nor does it represent that it has | |
758 | made any independent effort to identify any such rights. Information | |
759 | on the procedures with respect to rights in RFC documents can be | |
760 | found in BCP 78 and BCP 79. | |
761 | ||
762 | Copies of IPR disclosures made to the IETF Secretariat and any | |
763 | assurances of licenses to be made available, or the result of an | |
764 | attempt made to obtain a general license or permission for the use of | |
765 | such proprietary rights by implementers or users of this | |
766 | specification can be obtained from the IETF on-line IPR repository at | |
767 | http://www.ietf.org/ipr. | |
768 | ||
769 | The IETF invites any interested party to bring to its attention any | |
770 | copyrights, patents or patent applications, or other proprietary | |
771 | rights that may cover technology that may be required to implement | |
772 | this standard. Please address the information to the IETF at | |
773 | ietf-ipr@ietf.org. | |
774 | ||
775 | Acknowledgement | |
776 | ||
777 | Funding for the RFC Editor function is provided by the IETF | |
778 | Administrative Support Activity (IASA). | |
779 | ||
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | McGrew & Viega Standards Track [Page 14] | |
787 | \f |