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
