I think it is fine to not mandate a particular method of token generation.
I think it is sufficient to provide two recommendations with an applicable
explanation of pros and cons. I do not think this will lead implementers
to make security-critical design mistakes. Most implementers can read an
RFC and understand the issues. When in doubt they post a question here.
Dave Wierbowski
From: Yoav Nir <y...@checkpoint.com>
To: IPsecme WG <ipsec@ietf.org>
Date: 10/20/2010 04:10 AM
Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue
193
Sent by: ipsec-boun...@ietf.org
Hi all
I have started this thread about this issue a week ago, and so far the only
responses we have had are from Yaron and Frederic. I would like to hear
some more, because this issue is very central.
Here's a summary of my take on this issue.
The draft does not mandate any particular method of token generation (in
this, we follow the example of the stateless cookie in RFC 5996). It does,
however, suggest two such methods, both of which are somewhat similar to
the cookie generation method suggested in RFC 5996:
1. The method in section 5.1 involves hashing a secret with the IKE SPIs
2. The method in section 5.2 involves hashing a secret with the IKE SPIs
and the token taker's IP address.
The big disadvantage of the method in 5.2 is that whenever the token
taker's IP address changes (as is common for roaming clients) the Token has
to be replaced. The advantage is that in a certain configuration (details
below) it prevents a token discovery attack. This attack involves tricking
one gateway to send a clear QCD token for an IKE SA owned by another
gateway. If a cluster is located behind a load balancer, at attacker can
attempt to send fake IKE messages from various IP addresses, until those
requests reach the "wrong" gateway, which will generate a QCD token that
can be used to cause the original token taker to disconnect.
Details of this scenario: For this attack to take place, we need all of the
following:
- A group of gateways, all sharing the same QCD token secret.
- A disjoint IKE SA database, meaning that IKE SAs are not synchronized.
One member in this cluster cannot know if a particular IKE SA exists on
another member.
- The ability of an attacker to direct requests to different members
(either by varying its IP address or by directly addressing the member),
and a willingness of all members to reply with a QCD token.
We are not saying that having such no-sync clusters is a good idea. In
fact, it may be a good idea to recommend against them in the ipsecha
document. But they do exist. I have no problem recommending that
implementations that don't have such concerns just go ahead and implement
the method in 5.1, but since these things do exist, I think it's OK to
recommend the method in 5.2 for these configurations. Frederic is
apparently with me on this, which is good. Yaron has some doubts, though,
and we'd really like to hear what other people think.
Yoav
On Oct 17, 2010, at 9:29 PM, Frederic Detienne wrote:
>
> This type of debate happened before and once again, it is critical to
design a secure protocol rather than a protocol that can/may be implemented
securely.
>
> The rejoinder is to
> - offer recommended cookie computation methods
> - highlight the risks of each method and the risks of doing something
else
>
> This way, those who follow the spec can ascertain their computation
method is secure and has a well defined domain of applicability.
>
> I feel the draft is headed in the right direction.
>
> If we take out computation methods, we probably ought to restrict the
domain of applicability of the specification and/or spend more time
highlighting the risk of do-it-yourself cookie methods. Neither option
looks attractive.
>
> Notice the problem of address-less cookie is not limited to load balanced
clusters. If the attacker can somehow target a device owning the QCD
cookie-generating-key but not owning the SA, this attacker may gain access
to the QCD token for a given SPI. This applies _for instance_ to HSRP pairs
if the real addresses of the devices are accessible by the attacker and if
the standby device accepts connections. This is just an example but it is
likely to affect many implementations in practice.
>
> The address-less method will likely require more severe warnings in order
to restrict or constraint its domain of applicability.
>
> regards,
>
> fred
>
> On 17 Oct 2010, at 15:41, Yoav Nir wrote:
>
>>
>> On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote:
>>
>>> Hi Frederic,
>>>
>>> I understand the scenario now and I agree that a solution is needed.
But
>>> I have two issues, one general and one specific:
>>>
>>> - Even though there are no interoperability implications, I think we
>>> should specify the token format. This will prevent people from making
>>> some security-critical design mistakes. In other words, we should have
>>> *one* token generation method.
>>
>> Since there are no interoperability implications, I thing we should not
specify the format, merely suggest it. Same as we suggest a Cookie format
in RFC 5996:
>> The exact
>> algorithms and syntax used to generate cookies do not affect
>> interoperability and hence are not specified here. The following is
>> an example of how an endpoint could use cookies to implement limited
>> DoS protection.
>>
>> Also, if different methods match different scenarios, I don't think we
should have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting
*two* methods. I would not want to implement the method in section 5.2 just
because somebody has some issues with a load balancer.
>>
>>>
>>> - The proposed method uses the taker's IP address, making some
>>> assumptions on the load balancer's behavior. But what if the load
>>> balancer behaves a bit differently, e.g. by including the source port
in
>>> the decision function? Such a system will still have the vulnerability.
>>> What if we choose instead to include the *maker* identity (a sequential
>>> member number, or a private IP, or even a MAC address)? This would
>>> prevent another member from re-generating the same token for an
>>> attacker, and as a side benefit, will not require token changes when
the
>>> client is roaming.
>>
>> Yes, but this will interact badly with clusters. We actually do want two
cluster members to return the same tokens for the same IKE SPIs. If they
have their states synched often, then it's no problem, because they both
know which IKE SAs exist, and which do not. If they don't have their states
synched and they are hot-standby, we also don't have a problem, because a
fail-over is like a reboot (but much faster), and you can't get a response
from the non-active member. The only problem scenario is when you have load
sharing and no synchronized state, and no control over the load balancer
(otherwise, I would tell it to balance by the initiator's IKE SPI). So if
one member fails, you can't get the others to offer valid QCD tokens, and
the IKE SAs have to take the long route to recovery. With the method in
5.2, the other members (which don't have state) can still create valid QCD
tokens, to get all those clients that connected to the down gateway to
begin IKE again.
>>
>>>
>>> Thanks,
>>> Yaron
>>>
>>> On 15/10/10 11:53, Frederic Detienne wrote:
>>>> Hi Yaron,
>>>>
>>>> In response to issue 193. For reference:
>>>>
>>>> --8<--
>>>> Section 9.3: this entire discussion is probably redundant, because
when a node fails in the LS cluster, you switch to another node.
Implementing QCD on top of this is probably an overkill. If we remove this
section, we can get rid of sec. 5.2 as well, and we can focus on a single
recommended way to generate the token, which would make analysis that much
easier.
>>>> --8<--
>>>>
>>>> 9.3 has been moved to 10.4 under security consideration. I will refer
to 10.4 instead of 9.3 from now on.
>>>>
>>>> The token generation method highlighted in 5.1 presents a security
risk highlighted in section 10.4.
>>>>
>>>> We can not get rid of 5.2 nor 10.4, however we could make it clearer
that 5.2 is the recommended token generation method when the risk
highlighted in10.4 is present.
>>>>
>>>> Regards,
>>>>
>>>> fred
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>> Scanned by Check Point Total Security Gateway.
>>
>
>
> 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
