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<yaronf.i...@gmail.com>
To: Yoav Nir<y...@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 Nir<y...@checkpoint.com>
To: IPsecme WG<ipsec@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
