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
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 asso
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 i
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
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
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
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) objec
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
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 ea
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
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 Extensio
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.or
Hi,
Jari Arkko writes:
> A review from an IPsec implementation perspective would indeed be much
> appreciated.
Yes.
> For background, my AD review is here
> http://www.ietf.org/mail-archive/web/mext/current/msg04450.html
My reply to those comments is in the thread pointed by Jari:
http://w
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
demonst
On Oct 20, 2010, at 5:01 PM, Stephen Kent wrote:
> 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 dange
15 matches
Mail list logo
