Subject: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2012 19:49:42 +0300

As described in the IPsecME WG meeting I propose that we change the
registration policy for the IPSEC Authentication Methods (Value 3) of
ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
RFC5226):

----------------------------------------------------------------------
      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.

            Examples: IPSECKEY Algorithm Types [RFC4025],
            Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
            Handshake Hello Extensions [RFC4366].
----------------------------------------------------------------------

I will ask IANA to make the change at the 2012-04-15, unless I get
some objections here in the list. 
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 27 Mar 2012 02:05:24 -0700 (PDT)

Hi Tero,

  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 "Specification Required" but didn't say
who or what the rationale was behind that opposition.

  So I'd like to discuss this a bit. I prefer "Specification Required"
and would like to know what the problem someone has with it is.

  thanks,

  Dan.

On Mon, March 26, 2012 9:49 am, Tero Kivinen wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Mar 2012 12:35:03 +0300

> and would like to know what the problem someone has with it is.

See the orignal thread in the ipsec-list:

http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html

What is your objection to the IETF Review?

-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 27 Mar 2012 07:14:22 -0700 (PDT)

> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html

  OK, but that says "'Specification Required' or 'IETF Review'", it's
not opposition to "Specification Required".

> What is your objection to the IETF Review?

  Well, I feel it is setting the bar too high for what I want to do.
I had to remove a chunk of text from my PAKE draft fixed a significant,
know, serious, and continuing problem with IKEv1. I was told that
I should write another I-D that includes that text and try to see
what happens. The issue is that requiring IESG review and AD sponsorship
will likely result in me not getting over that bar and getting a code
point assigned.

  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?"

  I don't want to burn up what remaining goodwill I might have with
our ADs by continuing to push this topic.

  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.
We can say, "stop using IKEv1" but giving someone the option of
implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
just continuing on with a broken XAUTH deployment, we all know what
they'll do and it's not doing PAKE + IKEv2. It would be a service to
the Internet to provide a fix for this. The IETF has not been successful
in forcing people to do things against their will (viz, the history of
IPv6) and if we tried here we'd likely fail again.

  So let me turn it around, what's wrong with "Specification Required"?

  thanks,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Mar 2012 17:39:00 +0300

> prevalence of XAUTH because there's no other option-- should be fixed.

All others than the dictionary attack IS ALREADY FIXED. The fixes are
in the IKEv2. Also the dictionary attack problem will be fixed by your
IKEv2 SPSK draft. 

> they'll do and it's not doing PAKE + IKEv2.

Yes, we can and should say "Stop using IKEv1".

That is the part I agree with you. I do not want to add any new
features to IKEv1, as that just makes people to continue use it, and
not to update to the IKEv2. If PAKE is the stick that causes people to
move from IKEv1 to IKEv2, that is very good.

> It would be a service to the Internet to provide a fix for this. The
> IETF has not been successful in forcing people to do things against
> their will (viz, the history of IPv6) and if we tried here we'd
> likely fail again.
> 

Read the whole original thread and find out there. I do not really
have any objections for Specification Required, that was what I
originally proposed. The original thread (I just gave the link to
first email in the full thread) has emails which explains why people
felt it was not enough.

Regardless whether it is Specification Required or not, I am still
objecting if someone tries to add new features to IKEv1. Of course my
objecting might not have any effect, but I still think it is BAD idea.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 27 Mar 2012 10:39:10 -0400

Hi Dan,

> 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).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Tuesday, March 27, 2012 10:14 AM
> To: Tero Kivinen
> Cc: [email-masked]; Dan Harkins
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration
> policy
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Mar 2012 17:44:47 +0300

[email-masked] 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
> 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). 

None of the IKEv1 iana registries are expert review, so I do not have
anything to do with them, except as I am expert for the IKEv2
registries, IANA seems to assume I can help them to solve old issues
in the IKEv1 registries too, but I am doing that just as an individual
helping them...
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 27 Mar 2012 08:39:09 -0700 (PDT)

> in the IKEv2. Also the dictionary attack problem will be fixed by your

  Yet there is still this massive deployment of XAUTH + IKEv1.

> Yes, we can and should say "Stop using IKEv1".

  Yes we should. But we should not suffer any delusions that we can
force anyone to do anything.

> move from IKEv1 to IKEv2, that is very good.

  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
IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
though, so it is likely that by adding SPSK to IKEv1 we could get people
off of XAUTH and that too would be a good thing.

  So if we weigh the improbable stretch goal of forcing people to stop
using IKEv1 with the probable, more easily attainable, goal of getting
people to stop using XAUTH by giving them an alternative that can pretty
easily be implemented, I still come down on settling for an achievable
goal of goodness and not making that be a victim for an unachievable goal
of betterness.

> objecting might not have any effect, but I still think it is BAD idea.

  OK, so we're in agreement: "Specification Required."

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 27 Mar 2012 09:23:04 -0700 (PDT)

Hi David,

On Tue, March 27, 2012 7:39 am, [email-masked] wrote:
> 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.
>
> 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.

---

From: <[email-masked]>
Date: Tue, 27 Mar 2012 12:41:28 -0400

> 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

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 12:23 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 27 Mar 2012 23:13:28 +0200

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 28 Mar 2012 00:49:27 -0700 (PDT)

Hi,

  Let me answer David here in a response to Yaron....

  To be equally blunt, it is because this PAKE work became extremely
political and I was, and still am, very unhappy with the way it turned
out. Repeating it, this time with an obsoleted protocol, would cause
(more) people to question my sanity-- i.e. doing the same thing and
expecting a different result.

  I'd like to just get a stable reference for this minor change that
has the potential to do good. I don't want to fight over it anymore.

  regards,

  Dan.

On Tue, March 27, 2012 2:13 pm, Yaron Sheffer wrote:
>>>> does

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Mar 2012 10:14:51 +0200

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 poor PSK support for mobile peers) just works. The big vendors have at least server-side support, and Microsoft has a client in Win7. I think EAP is a hindrance, because XAuth works better with older backend servers.

Your proposal will be more secure than XAuth and require less round trips, but won't integrate with AAA servers.  I think anyone who is going to go to the effort of implementing this (replace or update all IKEv1 endpoints) might as well move them to IKEv2. The big hurdle to implementing what you suggest for remote access is that XAuth works. 

What doesn't work is a gateway with a dynamic external IP address that doesn't have a certificate. But I don't see how upgrading the gateways to support your extension is easier than upgrading them to support IKEv2. 

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Mar 2012 14:12:26 +0200

>>>>> "Yoav" == Yoav Nir <[email-masked]> 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 vendors have at least server-side
    Yoav> support, and Microsoft has a client in Win7. I think EAP is a
    Yoav> hindrance, because XAuth works better with older backend
    Yoav> servers.

Let me suggest that enhancements to IKEv1 are point releases, for which
you get with your maintenance.
But, IKEv2 is a major release, for which the customer pays again.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Mar 2012 14:43:26 +0200

> But, IKEv2 is a major release, for which the customer pays again.

I don't know about other vendors, but for us IKEv2 was introduced in a version called R71. Customers eventually do upgrade, whether it's to get IKEv2 or get one of the other features. Similarly in Windows, customers buy Windows 7 for the 64-bit support, or the aero interface, or for IPv6 support, and they also get the IKEv2. 

I don't think anyone is going to add new enhancements to old releases now, unless those "enhancements" begin with the words "prevent an attack where…"

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Mar 2012 16:04:23 +0300

> goal of goodness and not making that be a victim for an unachievable goal

The reason they cannot move to use IKEv1 + SPSK any faster than they
can move to use IKEv2 + SPSK is same. Both of them do require new
version of both client and server. The client customers always tell
that the reason they cannot use IKEv2 as the SGW's they use do not
support IKEv2 (or it is not turned on by default). The SGW customers
say that the reason they cannot use IKEv2 as they clients do not
support it (or it is not turned on by default)...

>   OK, so we're in agreement: "Specification Required."

I originally suggested "Specification Required", so yes we are in
agreement in that, but we are not only people in the WG, and there has
been people saying otherwise. If we do not reach some kind of
concensus, then the default action will most likely be "do nothing",
which will mean the registry stays what it is now, and I do not want
that.

I think "IETF Review" would be good compromise for this as it would
make it easier than "Standard Track RFC", but would satisfy those who
do not want to have it as lower as "Specification Required" is... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Mar 2012 16:06:05 +0300

> pretty done. At this point I'm pretty sure that j would be zero.

Most likely not, as all IPsec work had to be stopped so we could ship
the IPsec out... IPSRA was supposed to do things like XAUTH and
Configuration mode etc, but it failed...
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 28 Mar 2012 09:58:41 -0400

> do not want to have it as lower as "Specification Required" is...

Summarizing my views:
- "Specification Required" is an unacceptably low bar for this sort of
	security protocol due to the possibility of security flaws.
- I prefer "IETF Review" to "Expert Review" for this sort of security
	protocol as "IETF Review" should yield higher-quality results.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Wednesday, March 28, 2012 9:04 AM
> To: Dan Harkins
> Cc: [email-masked]