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 Niry...@checkpoint.com To: IPsecme WGipsec@ietf.org 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 Niry...@checkpoint.com To: IPsecme WGipsec@ietf.org 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] Ticket #195 - Protection against SPI enumeration
At 4:37 PM +0200 10/20/10, Yoav Nir wrote: Yaron: 10.3: of course, it is possible that *both* implementations generate predictable/short SPI values Hi all. I think this one was solved together with ticket #191 (The danger of predictable SPIs), but requiring that the token maker randomize IKE SPIs. Unless somebody (like Yaron) objects within the next few days, I will close this issue as well. And yes, Yaron, I have made the language about the PRNG less wimpy. Yoav Why not allow either peer (or both) to add a sizeable nonce as a separate source of unpredictable data? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Review of PF_KEY extension
Folks, We are trying to get this PF_KEY extension document published as an Informational RFC and it would be beneficial if some IPsec experts on this list could help us by reviewing the document. Please let me know if you are willing to review the document. Thanks. --julien PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE draft-ebalard-mext-pfkey-enhanced-migrate-01 Abstract This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and shows how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IPsec/IKE in a Mobile IPv6 environment. PF_KEY MIGRATE message serves as a carrier for updated information for both the in-kernel IPsec structures (Security Policy Database / Security Association Database) and those maintained by the key managers. This includes in-kernel Security Policy / Security Association endpoints, key manager maintained equivalents, and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Review of PF_KEY extension
A review from an IPsec implementation perspective would indeed be much appreciated. For background, my AD review is here http://www.ietf.org/mail-archive/web/mext/current/msg04450.html Jari ___ 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, 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 Shefferyaronf.i...@gmail.com To: Yoav Niry...@checkpoint.com Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG ipsec@ietf.org 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 Niry...@checkpoint.com To: IPsecme WGipsec@ietf.org 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
