Subject: [IPsec] Last Call: <draft-kivinen-ipsecme-secure-password-framework-01.txt> (Secure Password Framework for IKEv2) to Informational RFC

From: The IESG <[email-masked]>
Date: Wed, 27 Jul 2011 09:44:59 -0700

The IESG has received a request from an individual submitter to consider
the following document:
- 'Secure Password Framework for IKEv2'
  <draft-kivinen-ipsecme-secure-password-framework-01.txt> as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-08-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document creates a generic way for Internet Key Exchange (IKEv2)
   to use any of the symmetric secure password authentication methods.
   There are multiple methods already specified in other documents and
   this document does not add new one.  This document specifies a common
   way so those methods can agree on which method is to be used in
   current connection.  This document also provides a common way to
   transmit secure password authentication method specific payloads
   between peers.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/

No IPR declarations have been submitted directly on this I-D.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Jul 2011 01:30:41 +0300

I think this is a terrible idea. 

IKEv2 has a way for mutual authentication with a shared key.

A concern was raised that this method was vulnerable to guessing if trivial shared keys were configured.

There were several proposals for a better cryptographic method.

The IPsecME working group failed to choose between them. This is not so surprising, because most participants are engineers, not cryptographers. Even those with some cryptographic background stayed silent because choosing between several cryptographic protocols is hard. IETF last calls and the IESG did not help much either.

This draft represents a total shirking of our responsibility. Rather than decide on one protocol that is "best" or even arbitrarily choosing one that is "good enough", it proposes to build a framework so that everyone and their dog can have their own method. This is a nightmare for developers: since you can't know what method the peer will support, you have to implement all of them. 

If this had been a hierarchical organization, some manager would decide which of the methods gets developed (or published) and the others would be relegated to the recycle bin.

The IETF is not like that and we seek to reach consensus. That's a good thing, but this time it's leading us to a really bad solution for interoperability, and a really bad solution for implementers. 

I am opposed to this draft.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jul 2011 01:52:23 +0300

Yoav Nir writes:
> This draft represents a total shirking of our responsibility. Rather
> than decide on one protocol that is "best" or even arbitrarily
> choosing one that is "good enough", it proposes to build a framework
> so that everyone and their dog can have their own method. This is a
> nightmare for developers: since you can't know what method the peer
> will support, you have to implement all of them.  

Partially yes, but unfortunately all of the authors of those actual
protocols decided that they wanted to continue publishing those drafts
as individual RFCs, and each of them used different way to negotiate
them, so there was no way to even implement multiple of them.

At least this drafts gives you that option to implement multiple of
them if you want. This draft only provides instructions for those
other draft authors so they can at least common methods to negotiate
the feature and use common method to trasmit data between peers.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jul 2011 20:12:49 -0400

<hat location="off">

> I think this is a terrible idea. 

+.5. I think is is a bad idea.

> This draft represents a total shirking of our responsibility.

+.5. I think think it represents a shirking of our leadership's responsibility. Our leadership said that they would deal with the issue if the WG could not come to consensus, and the WG could not come to consensus. Adding a layer of indirection that is mostly transparent is not dealing with it.

> Rather than decide on one protocol that is "best" or even arbitrarily choosing one that is "good enough", it proposes to build a framework so that everyone and their dog can have their own method. This is a nightmare for developers: since you can't know what method the peer will support, you have to implement all of them. 
> 

+1

> them, so there was no way to even implement multiple of them.

Is this true? Because each has it's own way to negotiate its use, one should be able to implement multiple of the competing proposals as-is, yes?

> the feature and use common method to trasmit data between peers.

True, but it is still punting the problem of us having just one.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 27 Jul 2011 22:02:39 -0700 (PDT)

Paul,

  The existence of this draft shows a failure of YOUR leadership (and
that of your co-chairman) of the working group. Consensus was achieved
to add an authentication method based on a simple password yet you
seemingly worked to do everything possible to create division in the
working group and then stepped in to declare failure because no
consensus existed.

  We could've had a single standards-track solution to this problem over a
year ago if you had treated the singular draft used to argue for addition
of this work to the charter in the same way that you treated the singular
draft used to argue for addition of "EAP only" authentication to the
charter. The latter (authored by one of the chairmen) was advanced to
standards track after receiving a whopping ZERO comments from the WG and
the former was killed by the chairmen because the only comments on the
list were from authors of competing drafts (after manufacturing the
competition in the first place).

  There was hostility by the IPsecME chairmen to this work item from
the beginning and you worked to ensure its failure in the WG. Now you're
against advancement of Tero's draft to forge the best possible outcome
now? Not a surprise!

  Put that hat back on, along with a sackcloth and ashes, and say "mea
culpa".

  Dan.

On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote:
>> The IPsecME working group failed to choose between them. This is not so
>> surprising, because most participants are engineers, not cryptographers.
>> Even those with some cryptographic background stayed silent because
>> choosing between several cryptographic protocols is hard. IETF last
>> calls and the IESG did not help much either.
>>
> +.5. I think think it represents a shirking of our leadership's
> responsibility. Our leadership said that they would deal with the issue if
> the WG could not come to consensus, and the WG could not come to
> consensus. Adding a layer of indirection that is mostly transparent is not
> dealing with it.
>
>> Rather than decide on one protocol that is "best" or even arbitrarily
>> choosing one that is "good enough", it proposes to build a framework so
>> that everyone and their dog can have their own method. This is a
>> nightmare for developers: since you can't know what method the peer will
>> support, you have to implement all of them.
>>
>> If this had been a hierarchical organization, some manager would decide
>> which of the methods gets developed (or published) and the others would
>> be relegated to the recycle bin.
>>
>> The IETF is not like that and we seek to reach consensus. That's a good
>> thing, but this time it's leading us to a really bad solution for
>> interoperability, and a really bad solution for implementers.
>>
> Is this true? Because each has it's own way to negotiate its use, one
> should be able to implement multiple of the competing proposals as-is,
> yes?
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 28 Jul 2011 08:49:42 +0300

Unfortunately Dan cannot accept that there may be objective, non 
political reasons for the group not to adopt his work. Which is the 
reason why three alternative proposals were published several months 
after his proposed PAKE solution.

As co-chairmen of ipsecme, Paul and I did our best to get the group to 
agree on a single solution, to the point where we both supported Dan's 
criteria for selecting such a solution. Unfortunately we failed: while 
the group supported a PAKE in IKEv2 "in the abstract", there was not 
enough energy to pick a single protocol for this purpose.

Back to the matter at hand: I am opposed to 
draft-kivinen-ipsecme-secure-password-framework. It has served its 
purpose when two of the proposals were changed to add method 
negotiation, and thus enable IKE peers to implement none, one or more of 
these methods. I believe the other justifications for this draft, 
including the preservation of IANA IKEv2 namespaces, are bogus. Adopting 
the rest of the framework would be a useless exercise.

Personally, given that all three current proposals are being advanced as 
Experimental outside the WG, I would argue that we are wasting far too 
much energy on this grand unified framework. And this includes the 
current mail exchange.

Thanks,
     Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 28 Jul 2011 05:48:42 -0700 (PDT)

> after his proposed PAKE solution.

  Well there certainly wasn't a technical reason. In fact, after
delaying things for several months what we ended up with were 3
drafts that were effectively _identical_ from a technical point of view.
That is the prime reason that the group (and later the AD) could not
agree on which one to choose.

> enough energy to pick a single protocol for this purpose.

  You are on the record opposing PAKE from the start. It seems that
your "best" is best exemplified by your treatment of your own draft
which whisked through the group on to the standards track with no working
group input or, apparently, interest. PAKE got delayed (by you) and
ultimately killed for lack of interest even though there were emails on
the list discussing the 3 drafts.

> the rest of the framework would be a useless exercise.

  Speaking as an implementer, this is not a useless exercise. If one
must implement > 1 of these PAKE schemes having them inside of this
framework simplifies things.

> much energy on this grand unified framework. And this includes the

  Then don't update your draft! Let it expire and go where dead drafts
go.

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jul 2011 17:10:59 +0300

Paul Hoffman writes:
> Is this true? Because each has it's own way to negotiate its use,
> one should be able to implement multiple of the competing proposals
> as-is, yes? 

Before I proposed my common way to negotiate only one of the proposed
protocols included any kind of support for indicating which version is
used. The other two just assumed that initiator selects the method and
responder supports it without any negotiation, meaning there was no
way to make initiator version which supports multiple methods without
trying the first method, if that failed, then starting IKE_SA_INIT
from the beginning and trying second method etc...

This has already been changing as one of the drafts is already changed
to support what I have described in my draft, and another author
has said he will update his. The third one already had negotiation
altough done bit differently to compared what I proposed.

As an implementor I myself I want to keep this problem concentrated in
my code, meaning I do not want to make three completely differently
done implementations for the same thing, when I can instead make
generic changes to common code once, and separate the secure password
method related processing in one module taking care as any methods
needed to be implemented.

> True, but it is still punting the problem of us having just one.

Yes, but there is nothing I can do to that. I cannot fix the problem
that all 3 drafts were sent forward and most likely will be published.
If someone will decided only one of them will go forward (and there
will not be any other ever) then my draft will be mostly unneeded as
all of my draft can be put inside that one protocol draft going
forward just like draft-shin-augmented-pake has already done.

If there is no need to make sure multiple drafts make the negotiation
and common payload things similarly as there is only one draft, then
this draft is not needed.

I am also the IANA expert for the IKEv2 registries, and that was the
main reason I wanted to have common way to do things instead of doing
dozen new allocations to the registries just to support 3 bit
different ways to do same thing (when 3 allocations is enough). I
wanted to point this out to the draft authors as early as possible, so
it will not come as suprise to the authors that I do not support their
way of allocating that many codepoints from the registries.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jul 2011 17:27:37 +0300

Yaron Sheffer writes:
> these methods.

Actually there is currently only one draft, draft-shin-augmented-pake,
which follows my negotiation process. The
draft-harkins-ipsecme-spsk-auth author did say he is going to change
his draft, but the draft is not yet there, and then there is
draft-kuegler-ipsecme-pace-ikev2 (which you are co-author) which is
doing negotiation differently and I do not know whether that is going
to change to use same way than others.

> I believe the other justifications for this draft, including the
> preservation of IANA IKEv2 namespaces, are bogus.

As an IANA Expert for the registries in question I strongly disagree.

If you want to delay this fight to the IANA allocation time, that is
fine by me, but I will point it out already now that I will be against
allocating separate code points for each protocol as there is no need
for that.

> Adopting the rest of the framework would be a useless exercise.

Keeping the IANA registries clean is important for me, in addition to
make it easy to implement multiple methods in the same implementation.
I do not consider them as useless resons. Especially as it only causes
very small changes to the actual protocol drafts (I would expect less
than an one hour of work).
-- 
[email-masked]

---

From: "David Arnold" <[email-masked]>
Date: Wed, 27 Jul 2011 23:07:45 -0700

Well said

David J. Arnold - VP, Engineering
T: 408.855.2969  M: 707.703.9077  F: 408.855.2978  
SERVICES WITHOUT BOUNDARIES 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Wednesday, July 27, 2011 10:50 PM
To: Dan Harkins
Cc: IPsecme WG; Paul Hoffman; IETF-Discussion list
Subject: Re: [IPsec] Last Call: <draft-kivinen-ipsecme-secure-password-framework-01.txt> (Secure Password Framework for IKEv2) to Informational RFC

Unfortunately Dan cannot accept that there may be objective, non political reasons for the group not to adopt his work. Which is the reason why three alternative proposals were published several months after his proposed PAKE solution.

As co-chairmen of ipsecme, Paul and I did our best to get the group to agree on a single solution, to the point where we both supported Dan's criteria for selecting such a solution. Unfortunately we failed: while the group supported a PAKE in IKEv2 "in the abstract", there was not enough energy to pick a single protocol for this purpose.

Back to the matter at hand: I am opposed to draft-kivinen-ipsecme-secure-password-framework. It has served its purpose when two of the proposals were changed to add method negotiation, and thus enable IKE peers to implement none, one or more of these methods. I believe the other justifications for this draft, including the preservation of IANA IKEv2 namespaces, are bogus. Adopting the rest of the framework would be a useless exercise.

Personally, given that all three current proposals are being advanced as Experimental outside the WG, I would argue that we are wasting far too much energy on this grand unified framework. And this includes the current mail exchange.

Thanks,
     Yaron

On 28.7.2011 08:02, Dan Harkins wrote:
>    We could've had a single standards-track solution to this problem 
> over a year ago if you had treated the singular draft used to argue 
> for addition of this work to the charter in the same way that you 
> treated the singular draft used to argue for addition of "EAP only" 
> authentication to the charter. The latter (authored by one of the 
> chairmen) was advanced to standards track after receiving a whopping 
> ZERO comments from the WG and the former was killed by the chairmen 
> because the only comments on the list were from authors of competing 
> drafts (after manufacturing the competition in the first place).
>
> the beginning and you worked to ensure its failure in the WG. Now 
> you're against advancement of Tero's draft to forge the best possible 
> outcome now? Not a surprise!
>
>    Put that hat back on, along with a sackcloth and ashes, and say 
> "mea culpa".
>
>    Dan.
>
>>> The IPsecME working group failed to choose between them. This is not 
>>> so surprising, because most participants are engineers, not cryptographers.
>> responsibility. Our leadership said that they would deal with the 
>> issue if the WG could not come to consensus, and the WG could not 
>> come to consensus. Adding a layer of indirection that is mostly 
>> transparent is not dealing with it.
>>
>>> Rather than decide on one protocol that is "best" or even 
>>> arbitrarily choosing one that is "good enough", it proposes to build 
>>> a framework so that everyone and their dog can have their own 
>>> method. This is a nightmare for developers: since you can't know 
>>> what method the peer will support, you have to implement all of them.
>>>
>>> If this had been a hierarchical organization, some manager would 
>>> decide which of the methods gets developed (or published) and the 
>>> others would be relegated to the recycle bin.
>>>
>>> The IETF is not like that and we seek to reach consensus. That's a 
>>> good thing, but this time it's leading us to a really bad solution 
>>> for interoperability, and a really bad solution for implementers.
>>>
>>>> Rather than decide on one protocol that is "best" or even 
>>>> arbitrarily choosing one that is "good enough", it proposes to 
>>>> build a framework so that everyone and their dog can have their own 
>>>> method. This is a nightmare for developers: since you can't know 
>>>> what method the peer will support, you have to implement all of them.
>>> protocols decided that they wanted to continue publishing those 
>>> drafts as individual RFCs, and each of them used different way to 
>>> negotiate them, so there was no way to even implement multiple of them.
>> should be able to implement multiple of the competing proposals 
>> as-is, yes?
>>

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Jul 2011 10:50:51 -0500

I support an IKEv2 ZKPP method framework.  I don't understand the
controversy -- i.e., I think it's much ado about nothing.

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 30 Jul 2011 00:31:04 +0300

[Removing the main IETF list]

Hi Tero,

it doesn't matter exactly what negotiation is used, as long as two peers 
can offer multiple methods in IKE_SA_INIT, and find out which auth 
methods they have in common, if any. This is true for PACE, and also for 
version -04 of SPSK, i.e. before it adopted your framework.

Regarding IANA allocation, I would like to quote from RFC 5226:

"The designated expert is responsible for initiating and coordinating 
the appropriate review of an assignment request.  The review may be wide 
or narrow, depending on the situation and the judgment of the designated 
expert.  This may involve consultation with a set of technology experts, 
discussion on a public mailing list, consultation with a working group 
(or its mailing list if the working group has disbanded), etc.  [...] 
Designated experts are expected to be able to defend their decisions to 
the IETF community, and the evaluation process is not intended to be 
secretive or bestow unquestioned power on the expert."

I certainly do not want to turn the IANA allocation into a "fight". I do 
think the community needs to be consulted.

Thanks,
     Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 30 Jul 2011 00:47:17 +0300

Hi Dan,

there are three drafts on the table, and they are NOT identical. Crypto 
protocols, as you know well, are a mixture of cryptography and 
engineering. While the engineering on all three is very similar, the 
cryptography is not.
I do not wish to offend, but I believe cryptography is better left to 
professional cryptographers. I am not a cryptographer; the primary 
author of draft-kuegler-ipsecme-pace-ikev2 is.

Thanks,
     Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 30 Jul 2011 11:47:16 -0700 (PDT)

Hi Yaron,

> engineering. While the engineering on all three is very similar, the

  I didn't say the cryptography was identical, nor did I say the drafts
are identical (if they were then this "controversy" would be even more
contrived!).

  What I meant was that if your original opposition to my draft was
technical (or non-political, as you say) then we would've seen some
demonstrable technical difference in 1 of the 3 new drafts. We didn't.
They all do a zero knowledge proof in about the same number of rounds
(adding one to IKE_AUTH) with about the same amount of work (+- a modular
exponentiation). They all achieve the same goal in approximately the
same amount of messages with approximately the same amount of work.

  If there was a obvious demonstrable technical difference between the
drafts then the WG would've picked a winner or the AD would've picked
a winner or his designated expert would've picked a winner. But we have
no winner so, as I said, they are "effectively _identical_ from a
technical point of view."

  So there wasn't a technical reason for you to do what you did. We
could've had a standards track solution to this work item if you had
just treated my draft in the same way you treated your own. But no. We
have 3 drafts, an implementation problem, and now your opposition to a
draft to lessen that problem as much as possible.

> author of draft-kuegler-ipsecme-pace-ikev2 is.

  I'm not offended because I'm not a cryptographer and have never said
otherwise. But neither are any of the editors of the IKEv2 draft and I
don't remember your opposition to the advancement of that draft to RFC.

  Dan.