Subject: [IPsec] Issue #194 - Security Considerations should discuss the threat

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Oct 2010 08:22:47 +0200

Yaron: The security considerations are focused on details of the QCD solution, rather then on the threats we are dealing with. These threats are non-trivial to describe, since an active MITM attacker can easily cause an IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be able to do so. We need to analyze the threats in order to select a secure, but not overly complex solution.

Suggested text would be most welcome.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Oct 2010 10:09:53 +0200

One week, and no replies...

I will leave this issue open unless I get some suggested security considerations text.

The first paragraph in section 10.1 says the following. What else is missing?

   Tokens MUST be hard to guess.  This is critical, because if an
   attacker can guess the token associated with an IKE SA, she can tear
   down the IKE SA and associated tunnels at will.  When the token is
   delivered in the IKE_AUTH exchange, it is encrypted.  When it is sent
   again in an unprotected notification, it is not, but that is the last
   time this token is ever used.

Yoav

On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: David Wierbowski <[email-masked]>
Date: Wed, 20 Oct 2010 08:57:52 -0400

I'm not sure I understand Yaron's concern.  Yaron, can you elaborate how a
MITM attacker can easily cause an IKE SA to be reset?  I would think he
could only do so if he hi-jacked the original  IKE_SA negotiation and is
now impersonating the remote security endpoint.  In that case you have
bigger issues.

Dave Wierbowski

From:       Yoav Nir <[email-masked]>
To:         IPsecme WG <[email-masked]>
Date:       10/20/2010 04:10 AM
Subject:    Re: [IPsec] Issue #194 - Security Considerations should discuss
            the threat
Sent by:    [email-masked]

I will leave this issue open unless I get some suggested security
considerations text.

The first paragraph in section 10.1 says the following. What else is
missing?

Yoav

On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote:

> Yaron: The security considerations are focused on details of the QCD
solution, rather then on the threats we are dealing with. These threats are
non-trivial to describe, since an active MITM attacker can easily cause an
IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be
able to do so. We need to analyze the threats in order to select a secure,
but not overly complex solution.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Oct 2010 15:47:01 +0200

Hi Dave,

an active MITM, i.e. the sys admin at your local Starbucks, needs to 
only drop a few packets of an open IKE SA (a few retransmissions) for 
the peers to decide that they have a problem and attempt to renegotiate 
the SA. This attack is trivial to mount if you're at the right spot.

On the other hand, Sec. 5.2 of the document is designed to prevent 
another kind of DoS attack that eventually does the same thing: resets 
the SA.

So we need to explain why we add a mechanism to prevent one kind of DoS 
attacks even though we have other potential DoS issues. I'm not saying 
this is wrong, I'm saying it needs to be rationalized.

Thanks,
	Yaron

On 10/20/2010 02:57 PM, David Wierbowski wrote:
> From:       Yoav Nir<[email-masked]>
> To:         IPsecme WG<[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Oct 2010 15:58:09 +0200

OK. I did not understand that this was about 5.2 rather than the whole extension.

In that case, does section 10.4 address this?  If not, can you suggest some text?

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Oct 2010 16:21:06 +0200

In fact I was referring to the whole extension. OK, since you're forcing 
my hand...

General

The mechanism must not reduce the security of IKEv2 or IPsec. 
Specifically, an eavesdropper must not learn any non-public information 
about the peers.

DoS Resistance

The proposed mechanism should be secure against attacks by a passive 
MITM (eavesdropper). Such an attacker must not be able to disrupt an 
existing IKE session, either by resetting the session or by introducing 
significant delays.

The mechanism need not be similarly secure against an active MITM, since 
this type of attacker is already able to disrupt IKE sessions.

Thanks,
	Yaron

---

From: David Wierbowski <[email-masked]>
Date: Wed, 20 Oct 2010 11:17:37 -0400

Yaron/Yoav,

Thanks for your answers, but I should have been more specific in my
question.  I was not asking how a MITM could break IKE.  I was asking for
an example of how draft-ietf-ipsecme-failure-detection-01 increases the
risk over what we have today in IKE.  That's what I'm not seeing.

An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA  request)
and forge an informational message back to the requester containing  N
(INVALID_IKE_SPI) and N(QCD_TOKEN).  If he guesses QCD_TOKEN correctly he
can disrupt the IKE_SA and force a negotiation.   So in theory this makes
IKE more prone to a passive MITM, but that's theory.  Given significant
randomness in the token the attack is not feasible.  If there's a flaw in
the RFC that makes tokens easy to guess this would be a valid attack.
True, if we do not mandate the algorithm somebody can implement a token
generation scheme that is easy to guess.

Yaron are you saying that we need to explain the possible attack so one
does not implement a trivial token generation algorithm?  I tend to agree
with Yoav, that we do that in the first paragraph of 10.1.  Even with your
forced hand I'm not sure what you are looking for :>),

Do you know of a way that the draft allows an attacker to disrupt an
existing IKE session or learn of non-public information about the peers?

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

From:       Yaron Sheffer <[email-masked]>
To:         Yoav Nir <[email-masked]>
Cc:         David Wierbowski/Endicott/IBM@IBMUS, IPsecme WG
            <[email-masked]>
Date:       10/20/2010 10:21 AM
Subject:    Re: [IPsec] Issue #194 - Security Considerations should discuss
            the threat

General

DoS Resistance

Thanks,
             Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Oct 2010 22:32:36 +0200

Hi Dave,

if I had known of such an attack, you'd be the first to know :-)

Seriously, I didn't like the approach in Sec. 10, where you start from 
the solution and "nitpick" some of its aspects. I would have preferred a 
top-down approach, where you start with a set of security goals and 
demonstrate (to the best of our collective abilities) that they are 
achieved.

Your approach is certainly legitimate - these are "security 
considerations", not a security analysis. But I think the alternative 
might result in a better analysis and a more secure solution. Let me 
just remind you that the "significant randomness" has only been added in 
the latest version of this draft.

Thanks,
	Yaron

On 10/20/2010 05:17 PM, David Wierbowski wrote:
> From:       Yaron Sheffer<[email-masked]>
> To:         Yoav Nir<[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Oct 2010 12:59:46 +0300

> risk over what we have today in IKE.  That's what I'm not seeing.

If the QCD token generation secret is shared with multiple hosts which
do NOT share the same IKE SA state then there are attacks which are
not possible without QCD.

> generation scheme that is easy to guess.

There has been talks here in the list about cases where we have loose
cluster which do not share same IKE SA state, but which do share QCD
token generation secrets. Such clusters would be vulnerable to this
kind of attacks regardless whether the token generation contains token
takers IP number or not.

The attack simply needs to fake one IKE SA message so that its source
IP is the real source ip of the host attacker wants to attack, send it
to the cluster member which do not have the IKE SA state for that IKE
SA, and then see the QCD reply sent by the cluster member. This reply
now contains the QCD token which can then be used to attack the host.

Actually normally when that packet reaches its final destination the
host will tear down its IKE SA anyways.

So attacker just need to know the IKE SA SPI pair and the IP addresses
of the valid IKE SA on one cluster member and then send any faked IKE
message to another cluster member sharing same QCD token generation
secret, but separate IKE SA database.

The section 10.4 seems to assume that attacker cannot force the load
balancer to send the faked packet to any other cluster member than the
one mapped by the source IP-address of the packet. As the algorithm
how the load balancer really selects the peer where it sends the
packet is not necessarely known by the IPsec implementations, I do not
think we can trust we can include all same information to the token
generation.

For example it could use source port numbers, or destination
IP-address, etc so I think it is quite unsafe to assume anything what
the load balancer might do.

I think it would be safer to forbid situations where the cluster
members share the same QCD token unless they also share the IKE SA
state.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Oct 2010 12:33:22 +0200

On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote:

<snip />

> think we can trust we can include all same information to the token

I agree, although I suspect some of my co-authors might not.

> members share the same QCD token unless they also share the IKE SA

I agree that there is a problem that needs solving here, but I also see some great utility in allowing QCD on such configurations.

In a hot-standby cluster, you can have QCD instead of synchronizing state. When one gateway fails, the other takes over immediately (or in less than one second). This is like a reboot, but instantaneous, and it's easier and cheaper to implement than a real cluster with state synchronization - you only need to make sure that the QCD token secret is the same. In this configuration you don't have a problem, unless there's a way to get responses out of the standby member before it becomes active. 

If you also want to achieve scalability with your cluster, you implement load sharing. There is no state synch, but in case one of the gateways fails, we want the other to be able to use QCD to quickly destroy the existing IKE SAs. Again, if I can get one member to generate a token for an IKE SA owned by another gateway, the attacker wins. I'd say that this requires some very big assumptions for the load balancer anyway (for example, that without a failure, all IKE traffic for a particular SA goes to the same gateway, and even after a failure, old IKE SAs owned by other gateways remain with their respective gateways). We might need some interesting text to describe the requirements there.

I think I will close #194, and open a new one that makes the contentious point clearer.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Oct 2010 14:50:59 +0200

Hi Yoav,

as I mentioned in my mail yesterday, #194 is not just about this 
particular issue.

Thanks,
	Yaron

---

From: Frederic Detienne <[email-masked]>
Date: Mon, 25 Oct 2010 21:01:12 +0200

Hi Tero,

Like I explained earlier, sharing the address-less QCD token is problematic in multiple practical network designs:
- Stateless failover pairs (e.g. VRRP,  HSRP, ..)
- Load Balanced clusters
- Anycast server clusters

In general, QCD address-less token generation is dangerous in all the scenarios where the server owning the state can be bypassed by the attacker and any other server in the cluster, not owning state, can be targeted to receive the "invalid" IKE or ESP packet.

In the current proposal, I agree that the issues raised by address-less token should be more explicit and general. This token method should be explicitly forbidden when either
 - the accessibility to other servers of the clusters can not be restricted
 - or insufficient state is shared across the cluster to avoid sending unwanted INVALID_SPI

This statement is more accurate and less restrictive than having to share the IKE SA DB.

regards,

	fred

On 21 Oct 2010, at 11:59, Tero Kivinen wrote:

[...]

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 26 Oct 2010 12:02:02 +0200

> I agree, although I suspect some of my co-authors might not.

I suppose your statement was for me...

Not only I agree with Tero this can happen but I personally mentioned it a few times already. :-)

I am also claiming that it happens not just with SLB -- it can happen with HSRP and various other network designs.

In order to secure QCD, the token has to include all the fields that can be used for routing a packet to any given server:

 - source/destinatition IP
 - protocol (UDP / ESP)
 - source/destination ports if applicable

This is of course on top of the SPI and the QCD Secret.

In doing so, we impose additional constraints on QCD's security and scope but this is necessary to ensure QCD is a secure protocol.

So we are now facing three main options
 1- keep using 5.1 token generation and mention that it is dangerous in specific situations

 2- restrict the token generation method to 5.2 and expand 5.2 to using port and protocol as well (all routable fields) which actually restricts QCD out of Mobike. Warnings still apply for specific cases.

 3- expand QCD to send a liveness check with a short answer delay. In this scenario, if the server still has the IKE SA, it will respond to the liveness check -- which will prove that the clear-text INV_SPI should not have been sent in the first place. This must hint the client to NOT tear down or rekey the SA's, which protects against the attack.

With point 3, the protocol does not need the token and the persistent key anymore and the proposal effectively becomes  SIR which itself is immune to the attacks and works with Mobike.

regards,

	fred

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Oct 2010 14:12:37 +0300

Frederic Detienne writes:
> Like I explained earlier, sharing the address-less QCD token is
> problematic in multiple practical network designs: 

I do not think having address inside the QCD calculations help at all,
as the attacker can easily fake that address (it is source address of
the IKE SA packet triggering QCD).

Adding source address to the QCD token hash only helps if you can
guarantee that the load balancer forwarding packets to multiple
cluster members does it based on the source address and there is no
way to get packet past the load balancer without this demuxing. 

> In general, QCD address-less token generation is dangerous in all
> the scenarios where the server owning the state can be bypassed by
> the attacker and any other server in the cluster, not owning state,
> can be targeted to receive the "invalid" IKE or ESP packet.

I would remove the "address-less" there. QCD is dangerous in those
situations regardless whether address is there or not. 

> In the current proposal, I agree that the issues raised by
> address-less token should be more explicit and general. This token
> method should be explicitly forbidden when either

You misunderstood me. I am not proposing forbidding or adding text for
the address-less token. It is secure and works fine on those
environments where QCD can be used, i.e. where the QCD token
generation secret is not shared with other members.

I am opposed of including cookies with IP addresses, as I do not think
that solves any problem, as it puts way too much implicit assumptions
how the load balancer work. I think that section 5.2 is dangeours and
should be removed, and we should forbid sharing QCD token generation
secret in all cases where the IKE SA databases are not shared too.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Oct 2010 14:17:41 +0300

Frederic Detienne writes:
> In order to secure QCD, the token has to include all the fields that
> can be used for routing a packet to any given server: 
> 

But the problem is that the IPsec implementation does not have way to
know what fields is used. Some future load balancer might use
something else in addition to those you listed there and if that
happens we immediately open the QCD protocol for attacks.

> In doing so, we impose additional constraints on QCD's security and
> scope but this is necessary to ensure QCD is a secure protocol. 
> 

5.1 token generation is not dangerous, unless you share QCD token
generation secrets.

Both 5.1 and 5.2 token generations are dangerous if you share QCD
token generation secrets unless you know exactly how your load
balancer demuxes the IKE packets, and include all information used for
this demuxing to your QCD token and make sure load balancer cannot
pass packets to any members directly (i.e. bypassing the demuxing). 
-- 
[email-masked]