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

["David Arnold" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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:
>    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:
>> <hat location="off">
>>
>> On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote:
>>
>>> I think this is a terrible idea.
>> +.5. I think is is a bad 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.
>> +.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.
>>>
>>> I am opposed to this draft.
>> +1
>>
>>
>> On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote:
>>
>>> 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.
>> 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?
>>
>>> 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.
>> True, but it is still punting the problem of us having just one.
>>
>> --Paul Hoffman
>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec