Add compile option to disable internal handling of fatal signals
[strongswan.git] / doc / standards / rfc4543.txt
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