Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC

From: Vinod Sasi <[email-masked]>
Date: Tue, 5 Apr 2011 07:17:58 -0700

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?
 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?

Thanks in advance,
Vinod

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 5 Apr 2011 09:00:11 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vinod Sasi
Sent: Tuesday, April 05, 2011 10:18 AM
To: [email-masked]'
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

---

From: Vinod Sasi <[email-masked]>
Date: Tue, 5 Apr 2011 23:43:11 -0700

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:[email-masked]]
Sent: Tuesday, April 05, 2011 9:30 PM
To: Vinod Sasi; [email-masked]
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC
Importance: Low

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vinod Sasi
Sent: Tuesday, April 05, 2011 10:18 AM
To: [email-masked]'
Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC

Hello,

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).

-      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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 6 Apr 2011 08:02:52 -0700

From: Vinod Sasi [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 2:43 AM
To: Scott Fluhrer (sfluhrer); [email-masked]
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC

Hello Scott,

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.

By zero, I assume you mean the empty string.

b.       AAD constructed accordingly for ESP & AH outlined in RFC 4303 &
4302

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.

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:[email-masked]] 
Sent: Tuesday, April 05, 2011 9:30 PM
To: Vinod Sasi; [email-masked]
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC
Importance: Low

Hello,

 

 

-      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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Apr 2011 14:44:29 +0300

> Many thanks for your reply; this is helping me to a great extent. 

In the RFC6071 we do note that those combined mode ciphers are not
feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to
implement them using IKEv1, as there might be quite a lot of
interoperability issues, especially as the documentation how to use
them in IKEv1 is non-existing and different implementations might use
different interpretation how some document text should be applied in
this context.

The text in the RFC6071 (IPsec Roadmap) says:

----------------------------------------------------------------------
5.4.  Combined Mode Algorithms

   IKEv1 and ESP-v2 use separate algorithms to provide encryption and
   integrity protection, and IKEv1 can negotiate different combinations
   of algorithms for different SAs.  In ESP-v3, a new class of
   algorithms was introduced, in which a single algorithm can provide
   both encryption and integrity protection.  [RFC5996] describes how
   IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
   SAs.  [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
   negotiate and use combined mode algorithms for its own traffic.  When
   properly designed, these algorithms can provide increased efficiency
   in both implementation and execution.

   Although ESP-v2 did not originally include combined mode algorithms,
   some IKEv1 implementations have added the capability to negotiate
   combined mode algorithms for use in IPsec SAs; these implementations
   do not include the capability to use combined mode algorithms to
   protect IKE SAs.  IANA numbers for combined mode algorithms have been
   added to the IKEv1 registry.
...
5.4.2.  RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
        Encapsulating Security Payload (ESP) (S, June 2005)
...
   Requirement levels for AES-GCM:

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A
     ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.
----------------------------------------------------------------------

So unless this feature is really needed for some internal use case, I
would recommend using IKEv2 instead.

Do not expect this feature to be interoperable with other IPsec
implementations unless you specifically test it. 

> 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.

RFC4303 explains how you use combined mode ciphers in the ESPv3. You
cannot use combined mode ciphers in the RFC2406 implementations. 

> 2.)     Between ESP GMAC & AH GMAC. Please confirm my understanding.

You mean RFC4543?

> b.       AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302

The AAD is constructed as specified in RFC4543 section 3.3

> c.       8-byte IV is fed to GMAC algorithm for ESP & AH.

Yes.

> 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.

In the ESP the IV is stored in the IV field of the RFC 4303 section 2.

In the AH the IV is part of the ICV field of the RFC4302 section 2 and
the construction of the ICV field is specified in the RFC4543 section
4. 

> e. Both have fixed ICV lengths

No. RFC4106 has 3 different ICV lengths. RFC4543 has only one. 

>  plain_text=zero. So technically a GCM Algorithm code will act as
>  GMAC is my actually payload length provided as input is zero.

RFC4543 says section 3.5 says:

----------------------------------------------------------------------
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].
...
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 09:45:23 -0400

>    added to the IKEv1 registry.

It's more than a decision to not include that capability - IKEv1 exchanges
cannot be protected with combined mode algorithms without significant
incompatible change to IKEv1, as explained in Section 1 of RFC 5282:

   Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is
   based on the Internet Security Association and Key Management
   Protocol (ISAKMP) [RFC2408].  The E (Encryption) bit in the ISAKMP
   header specifies that all payloads following the header are
   encrypted, but any data integrity verification of those payloads is
   handled by a separate Hash Payload or Signature Payload (see Sections
   3.1, 3.11, and 3.12 of [RFC2408]).  This separation of encryption
   from data integrity protection prevents the use of authenticated
   encryption with IKEv1, thus limiting initial specifications of AES
   combined mode usage for IPsec to the Encapsulating Security Payload
   (ESP) [RFC2406].

OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in
a fashion that allowed their use with ESP (RFC 2406) to be negotiated by
IKEv1 (and also for AH in the case of GMAC).

I would strongly object to removal of the IANA registry entries that
support this usage, although I agree that everyone should be using
IKEv2 in preference to IKEv1.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Wednesday, April 06, 2011 7:44 AM
> To: Vinod Sasi
> Cc: [email-masked]; 'Scott Fluhrer (sfluhrer)'
> Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC
> 
> Vinod Sasi writes:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 Apr 2011 16:01:37 +0300

> incompatible change to IKEv1, as explained in Section 1 of RFC 5282:

That is clear, I do not think anybody even dreams using combined mode
ciphers on IKEv1. 

> IKEv1 (and also for AH in the case of GMAC).

The problem is that combined mode ciphers are not possible to be used
with RFC2406, as that does not support combined mode ciphers. To
support combined mode ciphers RFC4303 is needed.

Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302
for ESP and AH, so they seem to already require ESPv3.

> IKEv2 in preference to IKEv1.

I am very worried when people start implementing those ciphers to
IKEv1, as there is no way to know which features of the RFC4303 they
decide to include too. I agree that completely removing them is not
the way we want to go forward, but I would want to strongly recommend
people not to add implementation for them when using IKEv1, and based
on the text in the RFC6071 I think working group agreed on that too.

I would like that recommendation to be reflected also in the IANA
page, so implementors who just pick numbers from there would get
warning that implementing those ciphers might not lead as good
interoperability as they would expect compared when using IKEv2. You
have to remember that quite of lot of implementors will simply go to
the IANA page, pick the algorithms from there, quickly check out the
RFCs listed there and then implement the algorithms. Many of them do
not start looking other RFCs related to the problems, and quite many
of them have never heard about RFC errata etc...
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 11 Apr 2011 10:08:42 -0400

Hi Tero,

> on the text in the RFC6071 I think working group agreed on that too.

OTOH, I believe that combined-mode ciphers work fine with RFC 2406, provided
that some care is taken in the SA negotiation - the combined mode cipher is
negotiated as the encryption transform without an additional authentication
transform, and the combined mode cipher generates the ESP authentication data.

At least RFC 4106 (GCM) is clear on how to do this.

> for ESP and AH, so they seem to already require ESPv3.

Not exactly - like RFC 4106 (GCM), RFC 4309 (CCM) is also written in a
fashion that works with both versions of ESP (same encapsulation as RFC
4106, but the text doesn't contain as much explanation of the details).
OTOH, use of RFC 4543 (GMAC) with IKEv1 is peculiar, as that results in
an authentication transform masquerading as an IKEv1 encryption transform,
although RFC 4543 does cite RFC 2409 (IKEv1) as usable for keying.

> of them have never heard about RFC errata etc...

My objection was to the suggestion that the IANA registry entries be
removed - I have no problem discouraging use of IKEv1 in favor of
IKEv2 here and in general.

Thanks,
--David

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, April 11, 2011 9:02 AM
> To: Black, David
> Cc: [email-masked]

---

From: Vinod Sasi <[email-masked]>
Date: Wed, 13 Apr 2011 20:57:06 -0700

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:[email-masked]]
Sent: Wednesday, April 06, 2011 8:33 PM
To: Vinod Sasi; [email-masked]
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC

Hello Scott,

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.

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:[email-masked]]
Sent: Tuesday, April 05, 2011 9:30 PM
To: Vinod Sasi; [email-masked]
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC
Importance: Low

Hello,

Thanks in advance,
Vinod

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Wed, 27 Apr 2011 17:34:41 +0530

Hi, 

I have 2 doubts regarding IKEv2,

1) If in IKE_AUTH request message initiator sends a ID_R
payload(optional) specifying a particular peer identity, and the
responder
sends some different identity in the ID_R payload, what should be the
behavior? Should we send a AUTHENTICATION failure message, 
or except this new identity of the peer and mark the SA established, if
the other things are fine.

2) If we were to send a AUTHENTICATION failure, then this should be sent
as a INFORMATIONAL exchange message (as the message received 
is a response and not request). What should be the message Id used?

Regards, 
Prashant

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 27 Apr 2011 08:23:51 -0400

Hi Prashant.

> the other things are fine.

This is an implementation decision. In general, you should not
automatically reject the negotiation because the optional IDr is intended
only as a hint. Instead, you should (1) check whether your peer
authorization database (PAD) allows you to converse with the new identity
at the given IP address and to protect the given traffic, and (2) be sure
to verify that any earlier decisions, such as the use of a particular
pre-shared key or the choice of IKE SA cryptographic algorithms, are still
correct given that you are talking to a different identity than you first
suspected.

> is a response and not request). What should be the message Id used?

Yes, if you were to determine that the peer identity is not permitted by
your PAD, then you would initiate a new informational exchange on the IKE
SA. Since the IKE_AUTH exchange has a message id of 1, this exchange would
have a message id of 2. My own preference would be to send both an
AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for
maximum clarity. But I think that sending only AUTHENTICATION_FAILED is
sufficient and would be the preference of others on this list.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	"Prashant Batra (prbatra)" <[email-masked]>
To:	<[email-masked]>
Date:	04/27/2011 08:06 AM
Subject:	[IPsec] Query regarding IKE_SA_AUTH response
Sent by:	[email-masked]

Hi,

Regards,
Prashant

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Wed, 27 Apr 2011 19:09:40 +0530

Thanks Scott,

 I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD,
so as to ensure that the peer deletes the ipsec tunnel from the SADB (as
it would have already added the tunnel in SADB, after sending the
AUTH_RESPONSE).

But, to second you, most implementations would delete the same on
receiving AUTHENTICATION FAILED alone.

Regards, 

Prashant

From: Scott C Moonen [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2011 5:54 PM
To: Prashant Batra (prbatra)
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response

Hi Prashant.

This is an implementation decision. In general, you should not
automatically reject the negotiation because the optional IDr is
intended only as a hint. Instead, you should (1) check whether your peer
authorization database (PAD) allows you to converse with the new
identity at the given IP address and to protect the given traffic, and
(2) be sure to verify that any earlier decisions, such as the use of a
particular pre-shared key or the choice of IKE SA cryptographic
algorithms, are still correct given that you are talking to a different
identity than you first suspected.

Yes, if you were to determine that the peer identity is not permitted by
your PAD, then you would initiate a new informational exchange on the
IKE SA. Since the IKE_AUTH exchange has a message id of 1, this exchange
would have a message id of 2. My own preference would be to send both an
AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for
maximum clarity. But I think that sending only AUTHENTICATION_FAILED is
sufficient and would be the preference of others on this list.

 "Prashant Batra (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2
doubts regarding IKEv2,

________________________________

Hi, 

Regards, 
Prashant

---

From: Raj Singh <[email-masked]>
Date: Thu, 28 Apr 2011 09:52:25 +0530

Hi Prashant,

As per RFC 5996, Initiator sending AUTHENTICATION_FAILED would be sufficient
in case of peer's authentication failure:

Sec. 2.21.2 Error Handling in IKE_AUTH

...

If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually with no other
payloads.  This is an exception for the general rule of not starting
new exchanges based on errors in responses.

...

In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a Delete payload.

...

Regards,
Raj

On Wed, Apr 27, 2011 at 7:09 PM, Prashant Batra (prbatra) <[email-masked]
> wrote:

>  Thanks Scott,
>
>
>
>  I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so
> as to ensure that the peer deletes the ipsec tunnel from the SADB (as it
> would have already added the tunnel in SADB, after sending the
> AUTH_RESPONSE).
>
> But, to second you, most implementations would delete the same on receiving
> AUTHENTICATION FAILED alone.
>
>
>
> Regards,
>
> Prashant
>
>
>
>
>
> *From:* Scott C Moonen [mailto:[email-masked]]
> *Sent:* Wednesday, April 27, 2011 5:54 PM
> *To:* Prashant Batra (prbatra)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [IPsec] Query regarding IKE_SA_AUTH response
>
>
>
> Hi Prashant.
>
> authorization database (PAD) allows you to converse with the new identity at
> the given IP address and to protect the given traffic, and (2) be sure to
> verify that any earlier decisions, such as the use of a particular
> [image: Inactive hide details for "Prashant Batra (prbatra)" ---04/27/2011
> 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,]"Prashant Batra
> (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,
>
>  ------------------------------
>
>
>
>
> Hi,
>