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. 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. a. Plain_text=Zero for both b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302 c. 8-byte IV is fed to GMAC algorithm for ESP & AH. 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. e. Both have fixed ICV lengths 3.) Between GCM & GMAC algorithm, only difference being for GMAC the plain_text=zero. So technically a GCM Algorithm code will act as GMAC is my actually payload length provided as input is zero. 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
