From 71baf5a8f0f80fa3d2a03cfb597b6babe33394dd Mon Sep 17 00:00:00 2001 From: Tobias Brunner Date: Tue, 1 Dec 2009 18:17:37 +0100 Subject: [PATCH] Adding support for AES GMAC (RFC4543). --- doc/standards/rfc4543.txt | 787 ++++++++++++++++++ src/charon/config/proposal.c | 1 + .../kernel_netlink/kernel_netlink_ipsec.c | 3 +- src/charon/sa/keymat.c | 9 +- src/include/linux/pfkeyv2.h | 1 + src/libfreeswan/pfkeyv2.h | 1 + .../crypto/proposal/proposal_keywords.txt | 181 ++-- src/pluto/alg_info.c | 3 +- src/pluto/constants.c | 3 +- src/pluto/constants.h | 7 +- src/pluto/crypto.c | 4 +- src/pluto/ipsec_doi.c | 7 +- src/pluto/kernel.c | 1 + src/pluto/kernel_alg.c | 4 + src/pluto/kernel_netlink.c | 2 + 15 files changed, 911 insertions(+), 103 deletions(-) create mode 100644 doc/standards/rfc4543.txt diff --git a/doc/standards/rfc4543.txt b/doc/standards/rfc4543.txt new file mode 100644 index 000000000..5e9668eb8 --- /dev/null +++ b/doc/standards/rfc4543.txt @@ -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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + diff --git a/src/charon/config/proposal.c b/src/charon/config/proposal.c index 6b3500b6e..f2a34f20e 100644 --- a/src/charon/config/proposal.c +++ b/src/charon/config/proposal.c @@ -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; diff --git a/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c b/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c index 850876b9d..fa1d041fb 100644 --- a/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c +++ b/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c @@ -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 */ diff --git a/src/charon/sa/keymat.c b/src/charon/sa/keymat.c index e49626354..837cbe428 100644 --- a/src/charon/sa/keymat.c +++ b/src/charon/sa/keymat.c @@ -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: diff --git a/src/include/linux/pfkeyv2.h b/src/include/linux/pfkeyv2.h index b4b0712a4..7379d1a94 100644 --- a/src/include/linux/pfkeyv2.h +++ b/src/include/linux/pfkeyv2.h @@ -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 */ diff --git a/src/libfreeswan/pfkeyv2.h b/src/libfreeswan/pfkeyv2.h index 685db1273..725997ebc 100644 --- a/src/libfreeswan/pfkeyv2.h +++ b/src/libfreeswan/pfkeyv2.h @@ -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 */ diff --git a/src/libstrongswan/crypto/proposal/proposal_keywords.txt b/src/libstrongswan/crypto/proposal/proposal_keywords.txt index 139d689ca..0997c9316 100644 --- a/src/libstrongswan/crypto/proposal/proposal_keywords.txt +++ b/src/libstrongswan/crypto/proposal/proposal_keywords.txt @@ -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 diff --git a/src/pluto/alg_info.c b/src/pluto/alg_info.c index edecf14c6..32fd46ef4 100644 --- a/src/pluto/alg_info.c +++ b/src/pluto/alg_info.c @@ -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 diff --git a/src/pluto/constants.c b/src/pluto/constants.c index 6f991fd69..7823abe93 100644 --- a/src/pluto/constants.c +++ b/src/pluto/constants.c @@ -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[] = { diff --git a/src/pluto/constants.h b/src/pluto/constants.h index 8c574ebc5..e9567c07a 100644 --- a/src/pluto/constants.h +++ b/src/pluto/constants.h @@ -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 }; diff --git a/src/pluto/crypto.c b/src/pluto/crypto.c index 2113cecbc..fb0cff7b4 100644 --- a/src/pluto/crypto.c +++ b/src/pluto/crypto.c @@ -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; diff --git a/src/pluto/ipsec_doi.c b/src/pluto/ipsec_doi.c index 1f8917d79..797ac6d01 100644 --- a/src/pluto/ipsec_doi.c +++ b/src/pluto/ipsec_doi.c @@ -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); diff --git a/src/pluto/kernel.c b/src/pluto/kernel.c index fe4655d3f..ee22fb55e 100644 --- a/src/pluto/kernel.c +++ b/src/pluto/kernel.c @@ -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: diff --git a/src/pluto/kernel_alg.c b/src/pluto/kernel_alg.c index bf67315e6..7c2855edc 100644 --- a/src/pluto/kernel_alg.c +++ b/src/pluto/kernel_alg.c @@ -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 && diff --git a/src/pluto/kernel_netlink.c b/src/pluto/kernel_netlink.c index 289714b50..75d0c98d3 100644 --- a/src/pluto/kernel_netlink.c +++ b/src/pluto/kernel_netlink.c @@ -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: