Hi Dan
I have no opinion about the level of review needed for changes to IKEv1, and I
share your unhappiness with the way PAKE turned out.
If I had to guess the reasons for the slow adoption of IKEv2, I would guess
that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and
Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav If I had to guess the reasons for the slow adoption of IKEv2,
Yoav I would guess that it's because IKEv1 (with XAuth/hybrid,
Yoav Config, odd-numbered messages, and poor PSK support for mobile
Yoav peers) just works. The big
On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote:
Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav If I had to guess the reasons for the slow adoption of IKEv2,
Yoav I would guess that it's because IKEv1 (with XAuth/hybrid,
Yoav Config, odd-numbered messages, and poor PSK
Dan Harkins writes:
We can't always get what we want and we should be reasonable in
understanding that. If we could wave a magic wand and grant your wish
that would be good; we can't. And given the limits to our power we
have to accept that what will happen is people will continue to use
Dan Harkins writes:
That's a really good point. Had it been Specification Required all
along XAUTH might've gotten an official code point. And who knows maybe
one of the j-random proposals might be just that. But IKEv1 really is
pretty done. At this point I'm pretty sure that j would be
...@ietf.org] On Behalf Of
Tero Kivinen
Sent: Wednesday, March 28, 2012 9:04 AM
To: Dan Harkins
Cc: ipsec@ietf.org
Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods
(Value 3) registration
policy
Dan Harkins writes:
We can't always get what we want and we should
Dan Harkins writes:
I guess I'd like to register an objection. I wrote a draft a few months
ago to address this:
http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
That suggested making it Specification Required. You mentioned that
someone was opposed to it being
Dan Harkins writes:
That said, the problem I want to fix-- IKEv1's susceptibility to
dictionary attack, it's binding of a PSK to an IP address, and the
prevalence of XAUTH because there's no other option-- should be fixed.
All others than the dictionary attack IS ALREADY FIXED. The fixes are
Methods
(Value 3) registration
policy
On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote:
Dan Harkins writes:
I guess I'd like to register an objection. I wrote a draft a few
months
ago to address this:
http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
david.bl...@emc.com writes:
While I know that you're competent to design a solid protocol, who
does the security review of the next 5 j-random authentication
mechanisms to make sure that they don't have security flaws? I'd
prefer something like IESG approval that puts the Security Area in
On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote:
Dan Harkins writes:
That said, the problem I want to fix-- IKEv1's susceptibility to
dictionary attack, it's binding of a PSK to an IP address, and the
prevalence of XAUTH because there's no other option-- should be fixed.
All others
Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods
(Value 3) registration
policy
Hi David,
On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
Hi Dan,
One process note:
It appears that all the PAKE drafts got one yes from the sponsoring
AD
12 matches
Mail list logo
