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
