Subject: [IPsec] [Fwd: New Version Notification for draft-detienne-ikev2-recovery-00]

From: Pratima Sethi <[email-masked]>
Date: Mon, 23 Jun 2008 11:18:58 +0530

We have posted a new draft that proposes a new mechanism for secure 
recovery of IKE and IPsec SAs, after a failure.
Please review the draft and send us your comments.

thaks,
- prati

=============================================================================
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Safe IKE Recovery
	Author(s)       : F. Detienne, P. Sethi
	Filename        : draft-detienne-ikev2-recovery-00.txt
	Pages           : 19
	Date            : 2008-06-20

The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
limitation of not having a means to quickly recover from a stale
state known as dangling Security Associations (SA's) where one side
has SA's that the corresponding party does not have anymore.

This Draft proposes to address the limitation by offering an
immediate, DoS-free recovery mechanism for IKE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.txt>

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Jun 2008 13:35:14 +0300

Hi Prati

I've read your draft.  As I see it, it is supposed to solve the same  
problem as my http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-00.txt 
  . Both solve the case of a mismatched state between peers, where one  
has a live SA while the other has lost the SA (for example, due to a  
crash)

Your draft solves the problem by an unprotected query-response  
protocol on top of IKE, typically like this:

Alice                                    Bob
        HDR*(A,B)....
   <----------------------------------------

      HDR(A,B) N(INVALID-IKE_SA)
   ----------------------------------------->

      HDR(A,B) N(CHECK-SPI Query) N(Cookie)
   <-----------------------------------------

      HDR(A,B) N(CHECK-SPI Nack) N(Cookie)
   ----------------------------------------->

I'm not sure I understand what the security benefit of the CHECK-SPI  
notification. The INVALID-IKE-SA already indicates that Alice does not  
have the IKE SA. It is true that the packet could be spoofed, but in  
the absence of any protection, the same could be said for the packet  
carrying the CHECK-SPI NACK notification.

On Jun 23, 2008, at 8:48 AM, Pratima Sethi wrote:

> = 
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> <ftp://ftp.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.txt 
> >
>
>
>
> Scanned by Check Point Total Security Gateway.
>

---

From: Frederic Detienne <[email-masked]>
Date: Mon, 23 Jun 2008 14:09:02 +0200

Hi Yoav,

One of the intended features of the SIR protocol is statelessness. SIR
is stateless during the exchange and across reboots.

The unauthenticated INVALID_SPI message can be spoofed. The CHECK_SPI
test is a stateless anti-spoof, liveness, peer validation test by virtue
of a QUERY/RESPONSE test.

CHECK_SPI(QUERY) carries an N(Cookie) that is reflected in
CHECK_SPI(NACK/ACK). Thanks to the strong cryptographic properties of
N(COOKIE), remote-spoofing CHECK_SPI(NACK/ACK) is hard.

This is the ground on which IKEv2 is built and we placed our protocol at
the same level of protection.

Finally, SIR can be implemented on existing small hardware or large
clusters without changing hardware requirements.

regards,

	fred

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jun 2008 10:14:56 +0300

Hi Frederic,

Comments inline

> is stateless during the exchange and across reboots.

SIR is a protocol for validation of a specific IKE SA. The peer that  
performs this validation has a live IKE SA, so I don't believe it can  
be called stateless. It is possible to perform the CHECK_SPI query  
itself in a stateless manner, but seeing as you already hold an IKE SA  
with all its associated keys and information, I don't see what that  
buys you. Specifically, the number of CHECK_SPI queries is limited by  
the number of active IKE SAs, so I don't see why statelessness is an  
advantage here.

> of a QUERY/RESPONSE test.

Stateless cookies only provide a protection against a flood of initial  
packets with spoofed origins, such as SYN-flood attacks or multiple  
INITIAL exchange packets. They protect the responder against a  
malicious initiator. This is not the case here.

> N(COOKIE), remote-spoofing CHECK_SPI(NACK/ACK) is hard.

The cryptographic properties of N(COOKIE) make it hard to guess in  
advance what it is going to be. However, since Peer Y sends that  
cookie in the clear, an eavesdropping attacker should have no problem  
in seeing the cookie and creating a valid CHECK_SPI(NACK)

> the same level of protection.

Again, stateless cookies serve a different purpose in IKEv2. They  
prevent DoS attacks by limiting the amount of D-H calculations you can  
force a server to do. Here we're protecting against the forced  
deletion of an existing IKE SA. These are two very different problems.

> clusters without changing hardware requirements.

I agree that this is an advantage of SIR

> 	fred

Yoav

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 24 Jun 2008 10:01:43 +0200

Hi Yoav,

I may be missing something but let's partition the situation in two
cases:

1) the attacker IS NOT in the middle
------------------------------------
Can you explain how you remote-spoof a valid CHECK_SPI(NACK)|N(COOKIE)
and force deletion ?

2) the attacker IS in the middle (eavesdropping or injecting)
-------------------------------------------------------------
The attacker can just swamp one of the IKE peers with offers and force
many DH computations. Regardless of SIR.

As for the statelessness, SIR does not consume _additional_ state when
the procedure is triggered. The process is self-sustained and does not
require storage for longer than the processing of a packet. No timers,
no retransmissions... This is as little consumptions as we could
imagine.

regards,

	fred

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jun 2008 11:33:37 +0300

Hi Fred,

I think the first case is not interesting, because if the attacker  
can't see our packets, what's the point of encrypting them with  
IPsec.  So we need to assume at least eavesdropping.

There are ways to protect a server against being swamped with offers.  
The stateless cookie forces returnable addresses, and that allows us  
to rate-limit requests by peer. It's not like all hope is lost the  
moment an attacker can eavesdrop and send spoofed packets. Regular IKE  
and IPsec can continue with no problem. SIR allows the attacker, by  
spoofing one INVALID_SPI packet and one CHECK_SPI(NACK) packet, to  
force the gateway to delete an IKE SA.

I agree that the CHECK_SPI protocol does not require additional state,  
but considering that the number of active CHECK_SPI exchanges is  
limited by the number of active IKE SAs, I'm not sure that's an  
important advantage.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jun 2008 12:27:06 +0300

Hi Pasi, all.

There was a lot of traffic on this mailing list lately about the  
possible formation of an IPsec extensions and maintenance working group.

However, I've just looked at the agenda for Dublin ( https://datatracker.ietf.org/meeting/72/agenda.html 
  ) and the active BoFs page ( http://www3.tools.ietf.org/bof/trac/ 
wiki ). Neither shows anything related to IPsec.

What gives?  Is there going to be a meeting in Dublin?

Yoav

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 24 Jun 2008 16:18:05 +0200

Hi Yoav,

Reading through, I think we need to expose a little more of our
rationale.

The verification exchange (CHECK_SPI) _could_ have been embedded into an
IKE negotiation. It is nonetheless necessary for the security of the
protocol.

By separating the CHECK_SPI exchange from the IKE negotiation, we think
the protocol is clearer to understand but also more modular. For
instance, it allows using IKE Resumption or any further extension.

Answers inline.

> IPsec.  So we need to assume at least eavesdropping.

Because there are several types of attackers: those who want your data
and those who want to prevent you from conducting business. You need
encryption against the former and (remote) DoS protection against the
latter.

Remote DoS are common enough to be taken care of.

But SIR is safe here anyway so let's ignore this case for now. :)

> and IPsec can continue with no problem.

If your attacker (MitM) is close to the gateway and can snoop and spoof,
he will appear as having returnable addresses. In fact, the attacker can
spoof the entire "cone" of addresses in front of which he is located.

Again, let's anyway take your assumption that IKE and IPsec can continue
despite throttled keying.

>  SIR allows the attacker, by  

This is where dampening comes into play. I admit SIR draft lacks clarity
about handling man-in-the-middle. We will emphasize this.

>From the previous mail, we are in a situation assuming the attacker is
can eavesdrop (snoop) and inject (spoof).

Let's partition the situation (2 cases):

1) the attacker CAN block packets
---------------------------------
In clear: the attacker can spoof and snoop and can discard packets in
transit.

Then the attacker can just drop all ESP/IKE packets. Let's just be done
with that :)

2) the attacker CAN NOT block packets
-------------------------------------

2.1) Possible line of defense
.............................
An INVALID_SPI can be spoofed by the attacker (allegedly from Alice),
forcing a CHECK_SPI(QUERY) from Bob. The attacker spoofs back
CHECK_SPI(NACK). Since the attacker can not block packets, the
INVALID_SPI will also reach Alice, who will reply with CHECK_SPI(ACK).

Bob receives CHECK_SPI(NACK) first but if he waits for a few msec before
creating a new SA, he will receive BOTH a CHECK_SPI(ACK) and a
CHECK_SPI(NACK). Which is dubious. The SIR process should then stop and
log an error... saving the SA.

The process is illustrated below:

   Alice             Mallet                 Bob
                         Inv SPI
                         ------------------>

                            CHECK_SPI(QUERY)
      <-------------------------------------

                         CHECK_SPI(NACK)
                         ------------------> Should rekey but wait
                                             a few msec

      CHECK_SPI(ACK)
      -------------------------------------> Hint of attack => no rekey

We felt this mechanism was redundant and has been removed from our
draft. We could develop it if necessary.

2.2) Second line of defense
...........................
If the attack makes it through nonetheless, the SA is going to remain
dampened for a configurable amount of time. I.e. SIR forbids that we
make a subsequent recovery in that "safe" time so there is no way to
force repetitive rekeys. All the attacker gains is a single "bump" in
the control plane.

2.3) Ultimately
...............
Most importantly, it is only at the end of the rekey that the old SA's
should be discarded. Which means that a data plane (CHILD_SA's) is
available all the way through and we should not have lost data packets.

So if Bob can cope with IKE throttled flooding while still processing
data traffic, then 2.2 and 2.3 can deal with the even-more-throttled
"undue recovery" case by the MitM. All this without interruption.

> limited by the number of active IKE SAs, I'm not sure that's an  

This is true in some cases but not all devices are high end with loads
of CPU and memory. Some high end devices also happen to be fairly busy. 

We could save resource so we did it. Anyway, the cookie can be anything
(like a good random number) and the implementation could decide to keep
state without breaking the protocol if you like it to.

regards,

    fred

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 24 Jun 2008 09:46:04 -0700

Pasi, All, 

An updated draft on IPsec ESP traffic visibility is now available. This
is to support the IPsec traffic visibility deliverable in the proposed
IP Security Maintenance and Extensions (ipsecme) charter. 

http://tools.ietf.org/html/draft-grewal-ipsec-traffic-visibility-01

Look forward to your feedback.

Thanks, 
- Ken

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 10:37:25 +0300

It's not a BOF, and the WG hasn't been approved yet (the
charter text was sent to ietf-announce for public review
yesterday, so the earliest possibility for approval is 
the IESG telechat on July 3rd). 

If it gets approved in time (where "in time" partly 
depends on goodwill from the secretariat :-), it will
meet in Dublin.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Yoav Nir [mailto:[email-masked]] 
> Sent: 24 June, 2008 12:27
> To: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: IPsec in Dublin?
> 
> Hi Pasi, all.
> 
> However, I've just looked at the agenda for Dublin ( 
> https://datatracker.ietf.org/meeting/72/agenda.html

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 28 Jun 2008 12:53:51 +0300

> Reading through, I think we need to expose a little more of our

I have not read the draft (yet), but from your discussion it seems
that the real solution to the problem is to use birth certificates,
not adding more round trips to get more protection (from
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-rationale-00 section
3.1 changes we considered and rejected):

----------------------------------------------------------------------
   - adding in Bill Sommerfeld's "birth certificate" idea. In this idea
   Bob keeps a number in nonvolatile memory that increments each time
   the node restarts. When Bob restarts, he signs a "birth certificate"
   stating what the value of that counter is. This birth certificate is
   transmitted as a payload in message 4. Alice keeps this value. If Bob
   ever receives an ESP packet that doesn't decrypt properly or with an
   unknown SPI, he responds to that packet with his birth certificate.
   If the recipient has an SA for Bob with an older birth certificate,
   this lets them know Bob has restarted and forgotten state for that
   SA. We decided not to add that to this version of the draft, although
   we think it is a good idea, until it's been written up in a separate
   draft and there has been an opportunity for people to understand it
   and give feedback.
----------------------------------------------------------------------

The counter could of course be also the timestamp, as that is already
available for systems which are using certificates. I.e. instead of
sending non-authenticated invalid IKE SA notify, Bob would send his
birth certificate, so Alice can see whether Bob has rebooted or not,
and as the certificate is signed with Bobs key it means Alice can
trust that information. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec