[IPsec] Issue #194 - Security Considerations should discuss the threat
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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: > 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 > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
Sent by:ipsec-boun...@ietf.org
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:
> 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
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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 On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > 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: >> 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 >> To: IPsecme WG >> Date: 10/20/2010 04:10 AM >> Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss >> the threat >> Sent by:ipsec-boun...@ietf.org >> >> >> >> 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: >> >>> 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 >>> ___ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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 On 10/20/2010 03:58 PM, Yoav Nir wrote: 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 On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: 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: 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 To: IPsecme WG Date: 10/20/2010 04:10 AM Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss the threat Sent by:ipsec-boun...@ietf.org 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: 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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: 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 To: IPsecme WG Date: 10/20/2010 04:10 AM Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat Sent by:ipsec-boun...@ietf.org 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: 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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 To: Yoav Nir Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG Date: 10/20/2010 10:21 AM Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat 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 On 10/20/2010 03:58 PM, Yoav Nir wrote: > 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 > > On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > >> 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: >>> 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 >>> To: IPsecme WG >>> Date: 10/20/2010 04:10 AM >>> Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss >>> the threat >>> Sent by:ipsec-boun...@ietf.org >>> >>> >>> >>> 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 e
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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:
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
To: Yoav Nir
Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG
Date: 10/20/2010 10:21 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
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
On 10/20/2010 03:58 PM, Yoav Nir wrote:
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
On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote:
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:
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
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should
discuss
the threat
Sent by:ipsec-boun...@ietf.org
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
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
David Wierbowski writes: > 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. 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. > 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. 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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: > 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. I agree, although I suspect some of my co-authors might not. > 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. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
Hi Yoav, as I mentioned in my mail yesterday, #194 is not just about this particular issue. Thanks, Yaron On 10/21/2010 12:33 PM, Yoav Nir wrote: On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: 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. I agree, although I suspect some of my co-authors might not. 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. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
On 21 Oct 2010, at 12:33, Yoav Nir wrote: > > On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: > > > >> 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. > > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #194 - Security Considerations should discuss the threat
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: > > - source/destinatition IP > - protocol (UDP / ESP) > - source/destination ports if applicable 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. > > 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 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). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
