Hello Scott, Thank you for your time. To give you a background, I am implementing a conformance tool which exercises GCM/GMAC using ESP/AH for IKev1, running against Strongswan. Based on your inputs, I have been able to successfully negotiate ikev1 & send ESP/GCM packets using IKEv1 to Strongswan.
Now I am onto AH GMAC, I have few more clarification based on your reply now. [scott] "For AH GMAC, the IV is part of a mutable section, so either order would work." 1.) Since you have mentioned IV as mutable, it should be ideally be zeroed before being sent. But in the first place should I be including the IV in the AAD input or actual payload for AH? I am clear on the ESP GMAC part. 2.) IV should be prepended to ICV tag manually before being sent over the wire & I wouldn't expect the algorithm to do this step. 3.) The GMAC receiver inspects the IV & feeds it to the algorithm to compute the ICV. [scott] "A general purpose GCM (the cryptographical algorithm) implementation should be able to perform the computations for the ESP GCM, ESP GMAC and AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertext inputs would differ." I am using the Libtomcrypt library which implements the GCM, I am customizing the same for GMAC & I hope it works!!! Rgds, Vinod -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluh...@cisco.com] Sent: Wednesday, April 06, 2011 8:33 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC From: Vinod Sasi [mailto:vs...@ixiacom.com] Sent: Wednesday, April 06, 2011 2:43 AM To: Scott Fluhrer (sfluhrer); ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Hello Scott, Many thanks for your reply; this is helping me to a great extent. Few more clarifications from your reply.. 1.) RFC 4106 talks about Nonce = IV + Salt (last 4 bytes of keying material derived during SA creation). But where do we actually use it in the context of ESP & AH? I derive the 8-byte IV, feed those 8-bytes as input to the GCM Algorithm, take the cipher out & prepend it with the same 8-byte IV before sending it out on the wire. You feed the 12 byte nonce as input to the GCM algorithm, not the 8 byte IV. 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. a. Plain_text=Zero for both By zero, I assume you mean the empty string. b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302 c. 8-byte IV is fed to GMAC algorithm for ESP & AH. 12 byte nonce. d. Before being sent over the wire, for ESP the IV is prepended with the actually payload (IP/TCP/UDP). For AH the IV is prepended with the ICV tag. Actually, for ESP GMAC, this step needs to happen before (b), because the IV is included in the AAD (the region being authenticated). For AH GMAC, the IV is part of a mutable section, so either order would work. e. Both have fixed ICV lengths Yes, that is correct. Now, the ESP-GCM transform does have variable ICV lengths (8, 12, 16 octets); I'd strongly advise everyone to use the 16 octet length; there are known security problems if you truncate the ICV. 3.) Between GCM & GMAC algorithm, only difference being for GMAC the plain_text=zero. No, another difference is that the AAD are constructed differently. So technically a GCM Algorithm code will act as GMAC is my actually payload length provided as input is zero. A general purpose GCM (the cryptographical algorithm) implementation should be able to perform the computations for the ESP GCM, ESP GMAC and AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertext inputs would differ. Thanks in advance, Vinod -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluh...@cisco.com] Sent: Tuesday, April 05, 2011 9:30 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Importance: Low From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Vinod Sasi Sent: Tuesday, April 05, 2011 10:18 AM To: 'ipsec@ietf.org' Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC Hello, I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process of implementing this RFC for IKEv1 module for my customer. There is a long pending clarification, Appreciate your help on establishing clarity. 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? I'd use the more detailed descriptions in RFC 4303 and 4302; they define exactly what fields are included in the integrity check and (for AH) which fields are considered 'mutable' (and are implicitly replaced by zeros for the purposes of doing the integrity check). 2. What is the IV mode for GCM & GMAC? How to establish IV synchronization between the sender & receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I follow the same for GCM/GMAC? It's explained in RFC 4106; the encryptor picks an 8 byte IV, and includes it in the packet; the decryptor extracts this 8 byte IV from the packet. Note that the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 bytes come from the keying material ("salt"). Also, important note (RFC 4106 mentions it; it's important enough for me to reiterate it); it's critical that you never generate two packets with the same IV (for the same GCM/GMAC key). GCM IVs are not the same as CBC-mode IVs. With CBC mode, what's important is that the IV be unpredictable (and so, say, using a random number generator to pick CBC-mode IVs is a good solution). With GCM, it doesn't matter in the slightest if the IV is unpredictable; what's important is that they never repeat. Randomly picking GCM mode IVs will mean that you'll likely to get a repeat after a few billion packets; that'd be bad. Instead, one good way of picking the IVs is to use a counter (you could even reuse the IPSec sequence number if your implementation makes that convenient). Some other subtle points: - ESP GMAC is technically a 'combined mode'; what this means is that, as far as IPSec is concerned, it's both an encryption algorithm and an authentication algorithm. It doesn't actually provide confidentiality, but it is considered an encryption algorithm in the same way that ESP NULL is. One implication of that is that it can't be used with, say, ESP AES CBC (just like you can't use both ESP AES CBC and ESP NULL in the same SA). If you want both confidentially and integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption algorithm. - AH GMAC and IPv6 has a glitch which I don't think are mentioned explicitly in the RFCs; AH is an 'extension header' within IPv6, and the IPv6 RFC (2460, see section 4) must be a multiple of 8 octets in length. However, a straight-forward implementation of the AH header with RFC 4543 would yield a 28 octet header (12 octets for the next header/payload length/SPI/seqno, and 16 octets for the ICV value); 28 is not a multiple of 8. What you need to do (if you're serious about following the IPv6 RFC) is include an additional 4 octets after the ICV if you're using IPv6. I'd make those 4 octets all zeros; that way, you don't have to worry whether the other side considers them mutable or not. Thanks in advance, Vinod
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
