Hi Dan,
I haven't made up my mind yet whether I support the addition of SPSK to
IKEv1 or not, because both you and Tero have made some good points.
But this very discussion is a strong proof to me that we need to have
IETF Review (in the RFC 5226 sense) for this kind of major change to
IKEv1. Because this is exactly the community that needs to discuss new
authentication methods, and to weigh their security and other properties
against the disadvantages of adding yet more stuff to IKEv1. This needs
to be an open discussion, and I am sure the ADs will use our input when
they decide whether to sponsor any such proposal.
Thanks,
Yaron
On 03/27/2012 06:41 PM, david.bl...@emc.com wrote:
I think we can make things better with a simple addition and I just
want to be able to do that.
To ask bluntly - what is the problem with soliciting AD sponsorship for the
simple addition?
IMHO, "Specification Required" by itself is entirely too weak for security
protocols.
Thanks,
--David
-----Original Message-----
From: Dan Harkins [mailto:dhark...@lounge.org]
Sent: Tuesday, March 27, 2012 12:23 PM
To: Black, David
Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
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 and the remaining votes were "no objection" so it doesn't seem like
the IESG is really interested in this topic and, frankly, I think the
majority think "that stuff is out of my field of expertise". So my only
option is to cajole an AD into sponsoring my draft and hoping that no
one
else on the IESG objects by saying, "didn't we just do this?"
Speaking from long experience as a chair of many WGs, that sort of IESG
vote tally is typical, even for WG docs (although usually both of the
responsible Area ADs vote yes, as they're both "sponsoring"). IMHO,
you're being overly pessimistic.
So let me turn it around, what's wrong with "Specification Required"?
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 the loop to the notion of
deferring to some form of Expert Review (this is not a slam against Tero
as the expert - wider review usually produces better results).
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 zero.
I know IKE's being used wrong and I know the people who are using it
wrong don't want to go to IKEv2. They understand what they're doing is
broken (a shared PSK for everyone followed by PAP in XAUTH) but they
don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
like going to IKEv2 with SPSK is much more attractive.
I think we can make things better with a simple addition and I just
want to be able to do that.
regards,
Dan.
_______________________________________________
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
