Adding support for AES GMAC (RFC4543).
authorTobias Brunner <tobias@strongswan.org>
Tue, 1 Dec 2009 17:17:37 +0000 (18:17 +0100)
committerTobias Brunner <tobias@strongswan.org>
Fri, 12 Feb 2010 09:57:39 +0000 (10:57 +0100)
15 files changed:
doc/standards/rfc4543.txt [new file with mode: 0644]
src/charon/config/proposal.c
src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
src/charon/sa/keymat.c
src/include/linux/pfkeyv2.h
src/libfreeswan/pfkeyv2.h
src/libstrongswan/crypto/proposal/proposal_keywords.txt
src/pluto/alg_info.c
src/pluto/constants.c
src/pluto/constants.h
src/pluto/crypto.c
src/pluto/ipsec_doi.c
src/pluto/kernel.c
src/pluto/kernel_alg.c
src/pluto/kernel_netlink.c

diff --git a/doc/standards/rfc4543.txt b/doc/standards/rfc4543.txt
new file mode 100644 (file)
index 0000000..5e9668e
--- /dev/null
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          D. McGrew
+Request for Comments: 4543                           Cisco Systems, Inc.
+Category: Standards Track                                       J. Viega
+                                                            McAfee, Inc.
+                                                                May 2006
+
+
+        The Use of Galois Message Authentication Code (GMAC) in
+                            IPsec ESP and AH
+
+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 (2006).
+
+Abstract
+
+   This memo describes the use of the Advanced Encryption Standard (AES)
+   Galois Message Authentication Code (GMAC) as a mechanism to provide
+   data origin authentication, but not confidentiality, within the IPsec
+   Encapsulating Security Payload (ESP) and Authentication Header (AH).
+   GMAC is based on the Galois/Counter Mode (GCM) of operation, and can
+   be efficiently implemented in hardware for speeds of 10 gigabits per
+   second and above, and is also well-suited to software
+   implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 1]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. AES-GMAC ........................................................3
+   3. The Use of AES-GMAC in ESP ......................................3
+      3.1. Initialization Vector ......................................4
+      3.2. Nonce Format ...............................................4
+      3.3. AAD Construction ...........................................5
+      3.4. Integrity Check Value (ICV) ................................6
+      3.5. Differences with AES-GCM-ESP ...............................6
+      3.6. Packet Expansion ...........................................7
+   4. The Use of AES-GMAC in AH .......................................7
+   5. IKE Conventions .................................................8
+      5.1. Phase 1 Identifier .........................................8
+      5.2. Phase 2 Identifier .........................................8
+      5.3. Key Length Attribute .......................................9
+      5.4. Keying Material and Salt Values ............................9
+   6. Test Vectors ....................................................9
+   7. Security Considerations ........................................10
+   8. Design Rationale ...............................................11
+   9. IANA Considerations ............................................11
+   10. Acknowledgements ..............................................11
+   11. References ....................................................12
+      11.1. Normative References .....................................12
+      11.2. Informative References ...................................12
+1.  Introduction
+
+   This document describes the use of AES-GMAC mode (AES-GMAC) as a
+   mechanism for data origin authentication in ESP [RFC4303] and AH
+   [RFC4302].  We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC, respectively.  ENCR_NULL_AUTH_AES_GMAC is a companion
+   to the AES Galois/Counter Mode ESP [RFC4106], which provides
+   authentication as well as confidentiality.  ENCR_NULL_AUTH_AES_GMAC
+   is intended for cases in which confidentiality is not desired.  Like
+   GCM, GMAC is efficient and secure, and is amenable to high-speed
+   implementations in hardware.  ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC are designed so that the incremental cost of
+   implementation, given an implementation is AES-GCM-ESP, is small.
+
+   This document does not cover implementation details of GCM or GMAC.
+   Those details can be found in [GCM], along with test vectors.
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 2]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  AES-GMAC
+
+   GMAC is a block cipher mode of operation providing data origin
+   authentication.  It is defined in terms of the GCM authenticated
+   encryption operation as follows.  The GCM authenticated encryption
+   operation has four inputs: a secret key, an initialization vector
+   (IV), a plaintext, and an input for additional authenticated data
+   (AAD).  It has two outputs, a ciphertext whose length is identical to
+   the plaintext and an authentication tag.  GMAC is the special case of
+   GCM in which the plaintext has a length of zero.  The (zero-length)
+   ciphertext output is ignored, of course, so that the only output of
+   the function is the Authentication Tag.  In the following, we
+   describe how the GMAC IV and AAD are formed from the ESP and AH
+   fields, and how the ESP and AH packets are formed from the
+   Authentication Tag.
+
+   Below we refer to the AES-GMAC IV input as a nonce, in order to
+   distinguish it from the IV fields in the packets.  The same nonce and
+   key combination MUST NOT be used more than once, since reusing a
+   nonce/key combination destroys the security guarantees of AES-GMAC.
+
+   Because of this restriction, it can be difficult to use this mode
+   securely when using statically configured keys.  For the sake of good
+   security, implementations MUST use an automated key management
+   system, such as the Internet Key Exchange (IKE) (either version two
+   [RFC4306] or version one [RFC2409]), to ensure that this requirement
+   is met.
+
+3.  The Use of AES-GMAC in ESP
+
+   The AES-GMAC algorithm for ESP is defined as an ESP "combined mode"
+   algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP
+   integrity algorithm.  It is called ENCR_NULL_AUTH_AES_GMAC to
+   highlight the fact that it performs no encryption and provides no
+   confidentiality.
+
+      Rationale: ESP makes no provision for integrity transforms to
+      place an initialization vector within the Payload field; only
+      encryption transforms are expected to use IVs.  Defining GMAC as
+      an encryption transform avoids this issue, and allows GMAC to
+      benefit from the same pipelining as does GCM.
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 3]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   Like all ESP combined modes, it is registered in IKEv2 as an
+   encryption transform, or "Type 1" transform.  It MUST NOT be used in
+   conjunction with any other ESP encryption transform (within a
+   particular ESP encapsulation).  If confidentiality is desired, then
+   GCM ESP [RFC4106] SHOULD be used instead.
+
+3.1.  Initialization Vector
+
+   With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV)
+   is included in the ESP Payload, at the outset of that field.  The IV
+   MUST be eight octets long.  For a given key, the IV MUST NOT repeat.
+   The most natural way to meet this requirement is to set the IV using
+   a counter, but implementations are free to set the IV field in any
+   way that guarantees uniqueness, such as a linear feedback shift
+   register (LFSR).  Note that the sender can use any IV generation
+   method that meets the uniqueness requirement without coordinating
+   with the receiver.
+
+3.2.  Nonce Format
+
+   The nonce passed to the AES-GMAC authentication algorithm has the
+   following layout:
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Salt                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Initialization Vector                     |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 1: Nonce Format
+
+   The components of the nonce are as follows:
+
+   Salt
+      The salt field is a four-octet value that is assigned at the
+      beginning of the security association, and then remains constant
+      for the life of the security association.  The salt SHOULD be
+      unpredictable (i.e., chosen at random) before it is selected, but
+      need not be secret.  We describe how to set the salt for a
+      Security Association established via the Internet Key Exchange in
+      Section 5.4.
+
+   Initialization Vector
+      The IV field is described in Section 3.1.
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 4]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+3.3.  AAD Construction
+
+   Data integrity and data origin authentication are provided for the
+   SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad
+   Length, and Next Header fields.  This is done by including those
+   fields in the AES-GMAC Additional Authenticated Data (AAD) field.
+   Two formats of the AAD are defined: one for 32-bit sequence numbers,
+   and one for 64-bit extended sequence numbers.  The format with 32-bit
+   sequence numbers is shown in Figure 2, and the format with 64-bit
+   extended sequence numbers is shown in Figure 3.
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               SPI                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     32-bit Sequence Number                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                Authenticated Payload (variable)               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Padding (0-255 bytes)                      |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |  Pad Length   | Next Header   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 2: AAD Format with 32-bit Sequence Number
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               SPI                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 64-bit Extended Sequence Number               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                Authenticated Payload (variable)               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Padding (0-255 bytes)                      |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |  Pad Length   | Next Header   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 3: AAD Format with 64-bit Extended Sequence Number
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 5]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   The use of 32-bit sequence numbers vs. 64-bit extended sequence
+   numbers is determined by the security association (SA) management
+   protocol that is used to create the SA.  For IKEv2 [RFC4306] this is
+   negotiated via Transform Type 5, and the default for ESP is to use
+   64-bit extended sequence numbers in the absence of negotiation (e.g.,
+   see Section 2.2.1 of [RFC4303]).
+
+3.4.  Integrity Check Value (ICV)
+
+   The ICV consists solely of the AES-GMAC Authentication Tag.  The
+   Authentication Tag MUST NOT be truncated, so the length of the ICV is
+   16 octets.
+
+3.5.  Differences with AES-GCM-ESP
+
+   In this section, we highlight the differences between this
+   specification and AES-GCM-ESP [RFC4106].  The essential difference is
+   that in this document, the AAD consists of the SPI, Sequence Number,
+   and ESP Payload, and the AES-GCM plaintext is zero-length, while in
+   AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number,
+   and the AES-GCM plaintext consists of the ESP Payload.  These
+   differences are illustrated in Figure 4.  This figure shows the case
+   in which the Extended Sequence Number option is not used.  When that
+   option is exercised, the Sequence Number field in the figure would be
+   replaced with the Extended Sequence Number.
+
+   Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM-
+   ESP with encryption "turned off".  However, the ICV computations
+   performed in both cases are similar because of the structure of the
+   GHASH function [GCM].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 6]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+                     +-> +-----------------------+ <-+
+      AES-GCM-ESP    |   |          SPI          |   |
+          AAD -------+   +-----------------------+   |
+                     |   |    Sequence Number    |   |
+                     +-> +-----------------------+   |
+                         |    Authentication     |   |
+                         |          IV           |   |
+                  +->+-> +-----------------------+   +
+      AES-GCM-ESP |      |                       |   |
+       Plaintext -+      ~       ESP Payload     ~   |
+                  |      |                       |   |
+                  |      +-----------+-----+-----+   |
+                  |      | Padding   |  PL | NH  |   |
+                  +----> +-----------+-----+-----+ <-+
+                                                     |
+                       ENCR_NULL_AUTH_AES_GMAC AAD --+
+
+   Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP
+
+3.6.  Packet Expansion
+
+   The IV adds an additional eight octets to the packet and the ICV adds
+   an additional 16 octets.  These are the only sources of packet
+   expansion, other than the 10-13 bytes taken up by the ESP SPI,
+   Sequence Number, Padding, Pad Length, and Next Header fields (if the
+   minimal amount of padding is used).
+
+4.  The Use of AES-GMAC in AH
+
+   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
+   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
+   AH case, the Authentication Data field contains both an input to the
+   authentication algorithm (the IV) and the output of the
+   authentication algorithm (the tag).  No padding is required in the
+   Authentication Data field, because its length is a multiple of 64
+   bits.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 7]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Initialization Vector (IV)                 |
+   |                            (8 octets)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |             Integrity Check Value (ICV) (16 octets)           |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 5: The AUTH_AES_GMAC Authentication Data Format
+
+   The IV is as described in Section 3.1.  The Integrity Check Value
+   (ICV) is as described in Section 3.4.
+
+   The GMAC Nonce input is formed as described in Section 3.2.  The GMAC
+   AAD input consists of the authenticated data as defined in Section
+   3.1 of [RFC4302].  These values are provided as to that algorithm,
+   along with the secret key, and the resulting authentication tag given
+   as output is used to form the ICV.
+
+5.  IKE Conventions
+
+   This section describes the conventions used to generate keying
+   material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one
+   [RFC2409] and two [RFC4306].
+
+5.1.  Phase 1 Identifier
+
+   This document does not specify the conventions for using AES-GMAC for
+   IKE Phase 1 negotiations.  For AES-GMAC to be used in this manner, a
+   separate specification would be needed, and an Encryption Algorithm
+   Identifier would need to be assigned.  Implementations SHOULD use an
+   IKE Phase 1 cipher that is at least as strong as AES-GMAC.  The use
+   of AES-CBC [RFC3602] with the same AES key size as used by
+   ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED.
+
+5.2.  Phase 2 Identifier
+
+   For IKE Phase 2 negotiations, IANA has assigned identifiers as
+   described in Section 9.
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 8]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+5.3.  Key Length Attribute
+
+   AES-GMAC can be used with any of the three AES key lengths.  The way
+   that the key length is indicated is different for AH and ESP.
+
+   For AH, each key length has its own separate integrity transform
+   identifier and algorithm name (Section 9).  The IKE Key Length
+   attribute MUST NOT be used with these identifiers.  This transform
+   MUST NOT be used with ESP.
+
+   For ESP, there is a single encryption transform identifier (which
+   represents the combined transform) (Section 9).  The IKE Key Length
+   attribute MUST be used with each use of this identifier to indicate
+   the key length.  The Key Length attribute MUST have a value of 128,
+   192, or 256.
+
+5.4.  Keying Material and Salt Values
+
+   IKE makes use of a pseudo-random function (PRF) to derive keying
+   material.  The PRF is used iteratively to derive keying material of
+   arbitrary size, called KEYMAT.  Keying material is extracted from the
+   output string without regard to boundaries.
+
+   The size of the KEYMAT for the ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC MUST be four octets longer than is needed for the
+   associated AES key.  The keying material is used as follows:
+
+   ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC
+      The KEYMAT requested for each AES-GMAC key is 20 octets.  The
+      first 16 octets are the 128-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+   ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC
+      The KEYMAT requested for each AES-GMAC key is 28 octets.  The
+      first 24 octets are the 192-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+   ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC
+      The KEYMAT requested for each AES-GMAC key is 36 octets.  The
+      first 32 octets are the 256-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+6.  Test Vectors
+
+   Appendix B of [GCM] provides test vectors that will assist
+   implementers with AES-GMAC.
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 9]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+7.  Security Considerations
+
+   Since the authentication coverage is different between AES-GCM-ESP
+   and this specification (see Figure 4), it is worth pointing out that
+   both specifications are secure.  In ENCR_NULL_AUTH_AES_GMAC, the IV
+   is not included in either the plaintext or the additional
+   authenticated data.  This does not adversely affect security, because
+   the IV field only provides an input to the GMAC IV, which is not
+   required to be authenticated (see [GCM]).  In AUTH_AES_GMAC, the IV
+   is included in the additional authenticated data.  This fact has no
+   adverse effect on security; it follows from the property that GMAC is
+   secure even against attacks in which the adversary can manipulate
+   both the IV and the message.  Even an adversary with these powerful
+   capabilities cannot forge an authentication tag for any message
+   (other than one that was submitted to the chosen-message oracle).
+   Since such an adversary could easily choose messages that contain the
+   IVs with which they correspond, there are no security problems with
+   the inclusion of the IV in the AAD.
+
+   GMAC is provably secure against adversaries that can adaptively
+   choose plaintexts, ICVs and the AAD field, under standard
+   cryptographic assumptions (roughly, that the output of the underlying
+   cipher under a randomly chosen key is indistinguishable from a
+   randomly selected output).  Essentially, this means that, if used
+   within its intended parameters, a break of GMAC implies a break of
+   the underlying block cipher.  The proof of security is available in
+   [GCMP].
+
+   The most important security consideration is that the IV never
+   repeats for a given key.  In part, this is handled by disallowing the
+   use of AES-GMAC when using statically configured keys, as discussed
+   in Section 2.
+
+   When IKE is used to establish fresh keys between two peer entities,
+   separate keys are established for the two traffic flows.  If a
+   different mechanism is used to establish fresh keys, one that
+   establishes only a single key to protect packets, then there is a
+   high probability that the peers will select the same IV values for
+   some packets.  Thus, to avoid counter block collisions, ESP or AH
+   implementations that permit use of the same key for protecting
+   packets with the same peer MUST ensure that the two peers assign
+   different salt values to the security association (SA).
+
+   The other consideration is that, as with any block cipher mode of
+   operation, the security of all data protected under a given security
+   association decreases slightly with each message.
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 10]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   To protect against this problem, implementations MUST generate a
+   fresh key before processing 2^64 blocks of data with a given key.
+   Note that it is impossible to reach this limit when using 32-bit
+   Sequence Numbers.
+
+   Note that, for each message, GMAC calls the block cipher only once.
+
+8.  Design Rationale
+
+   This specification was designed to be as similar to AES-GCM-ESP
+   [RFC4106] as possible.  We re-use the design and implementation
+   experience from that specification.  We include all three AES key
+   sizes since AES-GCM-ESP supports all of those sizes, and the larger
+   key sizes provide future users with more high-security options.
+
+9.  IANA Considerations
+
+   IANA has assigned the following IKEv2 parameters.  For the use of AES
+   GMAC in AH, the following integrity (type 3) transform identifiers
+   have been assigned:
+
+       "9" for AUTH_AES_128_GMAC
+
+      "10" for AUTH_AES_192_GMAC
+
+      "11" for AUTH_AES_256_GMAC
+
+   For the use of AES-GMAC in ESP, the following encryption (type 1)
+   transform identifier has been assigned:
+
+      "21" for ENCR_NULL_AUTH_AES_GMAC
+
+10.  Acknowledgements
+
+   Our discussions with Fabio Maino and David Black significantly
+   improved this specification, and Tero Kivinen provided us with useful
+   comments.  Steve Kent provided guidance on ESP interactions.  This
+   work is closely modeled after AES-GCM, which itself is closely
+   modeled after Russ Housley's AES-CCM transform [RFC4309].
+   Additionally, the GCM mode of operation was originally conceived as
+   an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi
+   Kohno participated.  We express our thanks to Fabio, David, Tero,
+   Steve, Russ, Doug, and Yoshi.
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 11]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+11.  References
+
+11.1.  Normative References
+
+   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
+              Operation (GCM)", Submission to NIST. http://
+              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
+              gcm-spec.pdf, January 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
+              Algorithm and Its Use with IPsec", RFC 3602, September
+              2003.
+
+11.2.  Informative References
+
+   [CWC]      Kohno, T., Viega, J., and D. Whiting, "CWC: A high-
+              performance conventional authenticated encryption mode",
+              Fast Software Encryption.
+              http://eprint.iacr.org/2003/106.pdf, February 2004.
+
+   [GCMP]     McGrew, D. and J. Viega, "The Security and Performance of
+              the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT
+              '04, http://eprint.iacr.org/2004/193, December 2004.
+
+   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
+              4106, June 2005.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
+              2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+              4303, December 2005.
+
+   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+              4306, December 2005.
+
+   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
+              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
+              4309, December 2005.
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 12]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Authors' Addresses
+
+   David A. McGrew
+   Cisco Systems, Inc.
+   510 McCarthy Blvd.
+   Milpitas, CA  95035
+   US
+
+   Phone: (408) 525 8651
+   EMail: mcgrew@cisco.com
+   URI:   http://www.mindspring.com/~dmcgrew/dam.htm
+
+
+   John Viega
+   McAfee, Inc.
+   1145 Herndon Parkway, Suite 500
+   Herndon, VA 20170
+
+   EMail: viega@list.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 13]
+\f
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 14]
+\f
index 6b3500b..f2a34f2 100644 (file)
@@ -269,6 +269,7 @@ static bool is_authenticated_encryption(u_int16_t alg)
                case ENCR_CAMELLIA_CCM_ICV8:
                case ENCR_CAMELLIA_CCM_ICV12:
                case ENCR_CAMELLIA_CCM_ICV16:
+               case ENCR_NULL_AUTH_AES_GMAC:
                        return TRUE;
        }
        return FALSE;
index 850876b..fa1d041 100644 (file)
@@ -181,7 +181,7 @@ static kernel_algorithm_t encryption_algs[] = {
        {ENCR_AES_GCM_ICV8,                     "rfc4106(gcm(aes))"     },
        {ENCR_AES_GCM_ICV12,            "rfc4106(gcm(aes))"     },
        {ENCR_AES_GCM_ICV16,            "rfc4106(gcm(aes))"     },
-/*     {ENCR_NULL_AUTH_AES_GMAC,       "***"                           }, */
+       {ENCR_NULL_AUTH_AES_GMAC,       "rfc4543(gcm(aes))"     },
        {ENCR_CAMELLIA_CBC,                     "cbc(camellia)"         },
 /*     {ENCR_CAMELLIA_CTR,                     "***"                           }, */
 /*     {ENCR_CAMELLIA_CCM_ICV8,        "***"                           }, */
@@ -1007,6 +1007,7 @@ static status_t add_sa(private_kernel_netlink_ipsec_t *this,
                        break;
                case ENCR_AES_CCM_ICV16:
                case ENCR_AES_GCM_ICV16:
+               case ENCR_NULL_AUTH_AES_GMAC:
                case ENCR_CAMELLIA_CCM_ICV16:
                        icv_size += 32;
                        /* FALL */
index e496263..837cbe4 100644 (file)
@@ -99,8 +99,8 @@ struct keylen_entry_t {
  * Keylen for encryption algos
  */
 keylen_entry_t keylen_enc[] = {
-       {ENCR_DES,                                       64},
-       {ENCR_3DES,                             192},
+       {ENCR_DES,                                       64},
+       {ENCR_3DES,                                     192},
        {END_OF_LIST,                             0}
 };
 
@@ -108,7 +108,7 @@ keylen_entry_t keylen_enc[] = {
  * Keylen for integrity algos
  */
 keylen_entry_t keylen_int[] = {
-       {AUTH_HMAC_MD5_96,                      128},
+       {AUTH_HMAC_MD5_96,                      128},
        {AUTH_HMAC_SHA1_96,                     160},
        {AUTH_HMAC_SHA2_256_96,         256},
        {AUTH_HMAC_SHA2_256_128,        256},
@@ -414,7 +414,7 @@ static bool derive_child_keys(private_keymat_t *this,
                /* to bytes */
                enc_size /= 8;
 
-               /* CCM/GCM/CTR needs additional bytes */
+               /* CCM/GCM/CTR/GMAC needs additional bytes */
                switch (enc_alg)
                {
                        case ENCR_AES_CCM_ICV8:
@@ -429,6 +429,7 @@ static bool derive_child_keys(private_keymat_t *this,
                        case ENCR_AES_GCM_ICV12:
                        case ENCR_AES_GCM_ICV16:
                        case ENCR_AES_CTR:
+                       case ENCR_NULL_AUTH_AES_GMAC:
                                enc_size += 4;
                                break;
                        default:
index b4b0712..7379d1a 100644 (file)
@@ -315,6 +315,7 @@ struct sadb_x_kmaddress {
 #define SADB_X_EALG_AES_GCM_ICV12      19
 #define SADB_X_EALG_AES_GCM_ICV16      20
 #define SADB_X_EALG_CAMELLIACBC                22
+#define SADB_X_EALG_NULL_AES_GMAC      23
 #define SADB_EALG_MAX                   253 /* last EALG */
 /* private allocations should use 249-255 (RFC2407) */
 #define SADB_X_EALG_SERPENTCBC  252     /* draft-ietf-ipsec-ciph-aes-cbc-00 */
index 685db12..725997e 100644 (file)
@@ -337,6 +337,7 @@ struct sadb_protocol {
 #define SADB_X_EALG_AES_GCM_ICV12      19
 #define SADB_X_EALG_AES_GCM_ICV16      20
 #define SADB_X_EALG_CAMELLIACBC                22
+#define SADB_X_EALG_NULL_AES_GMAC      23
 #define SADB_EALG_MAX                  253 /* last EALG */
 /* private allocations should use 249-255 (RFC2407) */
 #define SADB_X_EALG_SERPENTCBC  252     /* draft-ietf-ipsec-ciph-aes-cbc-00 */
index 139d689..0997c93 100644 (file)
@@ -29,92 +29,95 @@ struct proposal_token {
     u_int16_t         keysize;
 };
 %%
-null,             ENCRYPTION_ALGORITHM, ENCR_NULL,                0
-des,              ENCRYPTION_ALGORITHM, ENCR_DES,                 0
-3des,             ENCRYPTION_ALGORITHM, ENCR_3DES,                0
-aes,              ENCRYPTION_ALGORITHM, ENCR_AES_CBC,           128
-aes128,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,           128
-aes192,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,           192
-aes256,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,           256
-aes128ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,           128
-aes192ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,           192
-aes256ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,           256
-aes128ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      128
-aes128ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      128
-aes128ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     128
-aes128ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     128
-aes128ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     128
-aes128ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     128
-aes192ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      192
-aes192ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      192
-aes192ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     192
-aes192ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     192
-aes192ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     192
-aes192ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     192
-aes256ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      256
-aes256ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,      256
-aes256ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     256
-aes256ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,     256
-aes256ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     256
-aes256ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,     256
-aes128gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      128
-aes128gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      128
-aes128gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     128
-aes128gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     128
-aes128gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     128
-aes128gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     128
-aes192gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      192
-aes192gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      192
-aes192gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     192
-aes192gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     192
-aes192gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     192
-aes192gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     192
-aes256gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      256
-aes256gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,      256
-aes256gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     256
-aes256gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,     256
-aes256gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     256
-aes256gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,     256
-blowfish,         ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,          128
-blowfish128,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,          128
-blowfish192,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,          192
-blowfish256,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,          256
-camellia,         ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,      128
-camellia128,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,      128
-camellia192,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,      192
-camellia256,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,      256
-cast128,          ENCRYPTION_ALGORITHM, ENCR_CAST,              128
-serpent,          ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,       128
-serpent128,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,       128
-serpent192,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,       192
-serpent256,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,       256
-twofish,          ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,       128
-twofish128,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,       128
-twofish192,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,       192
-twofish256,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,       256
-sha,              INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA1_96,        0
-sha1,             INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA1_96,        0
-sha256,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_128,   0
-sha2_256,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_128,   0
-sha256_96,        INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_96,    0
-sha2_256_96,      INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_96,    0
-sha384,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_384_192,   0
-sha2_384,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_384_192,   0
-sha512,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_512_256,   0
-sha2_512,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_512_256,   0
-md5,              INTEGRITY_ALGORITHM,  AUTH_HMAC_MD5_96,         0
-aesxcbc,          INTEGRITY_ALGORITHM,  AUTH_AES_XCBC_96,         0
-modpnull,         DIFFIE_HELLMAN_GROUP, MODP_NULL,                0
-modp768,          DIFFIE_HELLMAN_GROUP, MODP_768_BIT,             0
-modp1024,         DIFFIE_HELLMAN_GROUP, MODP_1024_BIT,            0
-modp1536,         DIFFIE_HELLMAN_GROUP, MODP_1536_BIT,            0
-modp2048,         DIFFIE_HELLMAN_GROUP, MODP_2048_BIT,            0
-modp3072,         DIFFIE_HELLMAN_GROUP, MODP_3072_BIT,            0
-modp4096,         DIFFIE_HELLMAN_GROUP, MODP_4096_BIT,            0
-modp6144,         DIFFIE_HELLMAN_GROUP, MODP_6144_BIT,            0
-modp8192,         DIFFIE_HELLMAN_GROUP, MODP_8192_BIT,            0
-ecp192,           DIFFIE_HELLMAN_GROUP, ECP_192_BIT,              0
-ecp224,           DIFFIE_HELLMAN_GROUP, ECP_224_BIT,              0
-ecp256,           DIFFIE_HELLMAN_GROUP, ECP_256_BIT,              0
-ecp384,           DIFFIE_HELLMAN_GROUP, ECP_384_BIT,              0
-ecp521,           DIFFIE_HELLMAN_GROUP, ECP_521_BIT,              0
+null,             ENCRYPTION_ALGORITHM, ENCR_NULL,                 0
+des,              ENCRYPTION_ALGORITHM, ENCR_DES,                  0
+3des,             ENCRYPTION_ALGORITHM, ENCR_3DES,                 0
+aes,              ENCRYPTION_ALGORITHM, ENCR_AES_CBC,            128
+aes128,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,            128
+aes192,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,            192
+aes256,           ENCRYPTION_ALGORITHM, ENCR_AES_CBC,            256
+aes128ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,            128
+aes192ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,            192
+aes256ctr,        ENCRYPTION_ALGORITHM, ENCR_AES_CTR,            256
+aes128ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       128
+aes128ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       128
+aes128ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      128
+aes128ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      128
+aes128ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      128
+aes128ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      128
+aes192ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       192
+aes192ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       192
+aes192ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      192
+aes192ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      192
+aes192ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      192
+aes192ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      192
+aes256ccm8,       ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       256
+aes256ccm64,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV8,       256
+aes256ccm12,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      256
+aes256ccm96,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV12,      256
+aes256ccm16,      ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      256
+aes256ccm128,     ENCRYPTION_ALGORITHM, ENCR_AES_CCM_ICV16,      256
+aes128gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       128
+aes128gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       128
+aes128gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      128
+aes128gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      128
+aes128gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      128
+aes128gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      128
+aes192gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       192
+aes192gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       192
+aes192gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      192
+aes192gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      192
+aes192gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      192
+aes192gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      192
+aes256gcm8,       ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       256
+aes256gcm64,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV8,       256
+aes256gcm12,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      256
+aes256gcm96,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV12,      256
+aes256gcm16,      ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      256
+aes256gcm128,     ENCRYPTION_ALGORITHM, ENCR_AES_GCM_ICV16,      256
+aes128gmac,       ENCRYPTION_ALGORITHM, ENCR_NULL_AUTH_AES_GMAC, 128
+aes192gmac,       ENCRYPTION_ALGORITHM, ENCR_NULL_AUTH_AES_GMAC, 192
+aes256gmac,       ENCRYPTION_ALGORITHM, ENCR_NULL_AUTH_AES_GMAC, 256
+blowfish,         ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,           128
+blowfish128,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,           128
+blowfish192,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,           192
+blowfish256,      ENCRYPTION_ALGORITHM, ENCR_BLOWFISH,           256
+camellia,         ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,       128
+camellia128,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,       128
+camellia192,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,       192
+camellia256,      ENCRYPTION_ALGORITHM, ENCR_CAMELLIA_CBC,       256
+cast128,          ENCRYPTION_ALGORITHM, ENCR_CAST,               128
+serpent,          ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,        128
+serpent128,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,        128
+serpent192,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,        192
+serpent256,       ENCRYPTION_ALGORITHM, ENCR_SERPENT_CBC,        256
+twofish,          ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,        128
+twofish128,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,        128
+twofish192,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,        192
+twofish256,       ENCRYPTION_ALGORITHM, ENCR_TWOFISH_CBC,        256
+sha,              INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA1_96,         0
+sha1,             INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA1_96,         0
+sha256,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_128,    0
+sha2_256,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_128,    0
+sha256_96,        INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_96,     0
+sha2_256_96,      INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_256_96,     0
+sha384,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_384_192,    0
+sha2_384,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_384_192,    0
+sha512,           INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_512_256,    0
+sha2_512,         INTEGRITY_ALGORITHM,  AUTH_HMAC_SHA2_512_256,    0
+md5,              INTEGRITY_ALGORITHM,  AUTH_HMAC_MD5_96,          0
+aesxcbc,          INTEGRITY_ALGORITHM,  AUTH_AES_XCBC_96,          0
+modpnull,         DIFFIE_HELLMAN_GROUP, MODP_NULL,                 0
+modp768,          DIFFIE_HELLMAN_GROUP, MODP_768_BIT,              0
+modp1024,         DIFFIE_HELLMAN_GROUP, MODP_1024_BIT,             0
+modp1536,         DIFFIE_HELLMAN_GROUP, MODP_1536_BIT,             0
+modp2048,         DIFFIE_HELLMAN_GROUP, MODP_2048_BIT,             0
+modp3072,         DIFFIE_HELLMAN_GROUP, MODP_3072_BIT,             0
+modp4096,         DIFFIE_HELLMAN_GROUP, MODP_4096_BIT,             0
+modp6144,         DIFFIE_HELLMAN_GROUP, MODP_6144_BIT,             0
+modp8192,         DIFFIE_HELLMAN_GROUP, MODP_8192_BIT,             0
+ecp192,           DIFFIE_HELLMAN_GROUP, ECP_192_BIT,               0
+ecp224,           DIFFIE_HELLMAN_GROUP, ECP_224_BIT,               0
+ecp256,           DIFFIE_HELLMAN_GROUP, ECP_256_BIT,               0
+ecp384,           DIFFIE_HELLMAN_GROUP, ECP_384_BIT,               0
+ecp521,           DIFFIE_HELLMAN_GROUP, ECP_521_BIT,               0
index edecf14..32fd46e 100644 (file)
@@ -139,6 +139,7 @@ static bool is_authenticated_encryption(int ealg_id)
                case ESP_AES_GCM_8:
                case ESP_AES_GCM_12:
                case ESP_AES_GCM_16:
+               case ESP_AES_GMAC:
                        return TRUE;
        }
        return FALSE;
@@ -474,7 +475,7 @@ struct alg_info_ike *alg_info_ike_create_from_str(char *alg_str)
 
        if (alg_info_parse_str((struct alg_info *)alg_info_ike, alg_str) == SUCCESS)
        {
-               alg_info_ike->ref_cnt = 1;      
+               alg_info_ike->ref_cnt = 1;
                return alg_info_ike;
        }
        else
index 6f991fd..7823abe 100644 (file)
@@ -392,7 +392,8 @@ static const char *const esp_transform_name[] = {
        "AES_GCM_12",
        "AES_GCM_16",
        "SEED_CBC",
-       "CAMELLIA_CBC"
+       "CAMELLIA_CBC",
+       "AES_GMAC"
 };
 
 static const char *const esp_transform_name_high[] = {
index 8c574eb..e9567c0 100644 (file)
@@ -125,10 +125,10 @@ extern const char sparse_end[];
 #define MAX_DIGEST_LEN          HASH_SIZE_SHA512
 
 /* RFC 2404 "HMAC-SHA-1-96" section 3 */
-#define HMAC_SHA1_KEY_LEN              HASH_SIZE_SHA1
+#define HMAC_SHA1_KEY_LEN       HASH_SIZE_SHA1
 
 /* RFC 2403 "HMAC-MD5-96" section 3 */
-#define HMAC_MD5_KEY_LEN               HASH_SIZE_MD5
+#define HMAC_MD5_KEY_LEN        HASH_SIZE_MD5
 
 #define IKE_UDP_PORT    500
 
@@ -150,7 +150,7 @@ enum ipsec_authentication_algo {
        AH_AES_128_GMAC = 11,
        AH_AES_192_GMAC = 12,
        AH_AES_256_GMAC = 13,
-       AH_SHA2_256_96  = 252  
+       AH_SHA2_256_96  = 252
 };
 
 extern enum_names ah_transform_names;
@@ -184,6 +184,7 @@ enum ipsec_cipher_algo {
        ESP_AES_GCM_16    = 20,
        ESP_SEED_CBC      = 21,
        ESP_CAMELLIA      = 22,
+       ESP_AES_GMAC      = 23,
        ESP_SERPENT       = 252,
        ESP_TWOFISH       = 253
 };
index 2113cec..fb0cff7 100644 (file)
@@ -580,9 +580,11 @@ int esp_from_encryption_algorithm(encryption_algorithm_t alg)
                        return ESP_AES_GCM_16;
                case ENCR_CAMELLIA_CBC:
                        return ESP_CAMELLIA;
+               case ENCR_NULL_AUTH_AES_GMAC:
+                       return ESP_AES_GMAC;
                case ENCR_SERPENT_CBC:
                        return ESP_SERPENT;
-       case ENCR_TWOFISH_CBC:
+               case ENCR_TWOFISH_CBC:
                        return ESP_TWOFISH;
                default:
                        return 0;
index 1f8917d..797ac6d 100644 (file)
@@ -2753,6 +2753,7 @@ static void compute_proto_keymat(struct state *st, u_int8_t protoid,
                                case ESP_AES_GCM_12:
                                case ESP_AES_GCM_16:
                                case ESP_AES_CTR:
+                               case ESP_AES_GMAC:
                                        needed_len += 4;
                                        break;
                                default:
@@ -3620,7 +3621,7 @@ stf_status main_inR2_outI3(struct msg_digest *md)
        if (send_cert)
        {
                bool success;
-               chunk_t cert_encoding;  
+               chunk_t cert_encoding;
                pb_stream cert_pbs;
 
                struct isakmp_cert cert_hd;
@@ -3634,7 +3635,7 @@ stf_status main_inR2_outI3(struct msg_digest *md)
                cert_encoding = mycert->cert->get_encoding(mycert->cert);
                success = out_chunk(cert_encoding, &cert_pbs, "CERT");
                free(cert_encoding.ptr);
-               if (!success)   
+               if (!success)
                {
                        return STF_INTERNAL_ERROR;
                }
@@ -4076,7 +4077,7 @@ main_inI3_outR3_tail(struct msg_digest *md
                success = out_chunk(cert_encoding, &cert_pbs, "CERT");
                free(cert_encoding.ptr);
                if (!success)
-               {       
+               {
                        return STF_INTERNAL_ERROR;
                }
                close_output_pbs(&cert_pbs);
index fe4655d..ee22fb5 100644 (file)
@@ -1993,6 +1993,7 @@ static bool setup_half_ipsec_sa(struct state *st, bool inbound)
                        case ESP_AES_GCM_12:
                        case ESP_AES_GCM_16:
                        case ESP_AES_CTR:
+                       case ESP_AES_GMAC:
                                key_len += 4;
                                break;
                        default:
index bf67315..7c2855e 100644 (file)
@@ -395,6 +395,10 @@ void kernel_alg_register_pfkey(const struct sadb_msg *msg_buf, int buflen)
                                                kernel_alg_add(satype, supp_exttype, &alg);
                                        }
                                }
+
+                               /* also register AES_GMAC */
+                               alg.sadb_alg_id = SADB_X_EALG_NULL_AES_GMAC;
+                               kernel_alg_add(satype, supp_exttype, &alg);
                        }
                        /* if SHA2_256 is registered then also register SHA2_256_96 */
                        if (satype == SADB_SATYPE_ESP &&
index 289714b..75d0c98 100644 (file)
@@ -112,6 +112,7 @@ static sparse_names ealg_list = {
        { SADB_X_EALG_AES_GCM_ICV8,  "rfc4106(gcm(aes))" },
        { SADB_X_EALG_AES_GCM_ICV12, "rfc4106(gcm(aes))" },
        { SADB_X_EALG_AES_GCM_ICV16, "rfc4106(gcm(aes))" },
+       { SADB_X_EALG_NULL_AES_GMAC, "rfc4543(gcm(aes))" },
        { SADB_X_EALG_CAMELLIACBC,   "cbc(camellia)" },
        { SADB_X_EALG_SERPENTCBC,    "serpent" },
        { SADB_X_EALG_TWOFISHCBC,    "twofish" },
@@ -687,6 +688,7 @@ static bool netlink_add_sa(const struct kernel_sa *sa, bool replace)
                        break;
                case SADB_X_EALG_AES_CCM_ICV16:
                case SADB_X_EALG_AES_GCM_ICV16:
+               case SADB_X_EALG_NULL_AES_GMAC:
                        icv_size += 32;
                        /* FALL */
                case SADB_X_EALG_AES_CCM_ICV12: