Re: RESEND: Thoughts on identity attacks

[Dan Harkins <dharkins@tibernian.com>]

  Khaja,

On Tue, 12 Feb 2002 12:34:17 PST you wrote
> Please do not treat this as an assault on the product of your love and
> labor.  Treat this as nothing more than an appeal for simplicity in any
> successor/replacement to IKE.  IKE is clearly is a very sophisticated, rich
> and elaborate protocol.  It's influence and comprehensiveness is also
> evidenced by the fact that popular successor candidates have really made no
> departure from IKE1s current structure or even the entirety of it's goals.
> I may well be the only one who wishes this but I was thinking that it would
> be great to have a radically simple alternative that can be an option
> perhaps coexisting with IKE2.  Rather like the coexistence of SSL 2.0 and
> 3.0 in implementations supporting the two.  I was hoping to see such an
> alternative fielded as a successor.  Such an alternative would do only the
> minimum necessary to create an SA for ESP.

  Please don't take this or my previous email as an assault on your sincere
desire for simplicity. And you don't need to make gratuitous compliments. IKE
is a protocol that no one likes, including me. 

  What features are the "the minimum necessary"? 

> You are quite right to point out that I may not be aware of the context
> here.  I am not as active a participant/reader of this list as I would like
> to be so I don't know if it is acceptable for a candidate successor to IKE
> to start from a clean slate and even sacrifice backward compatibility with
> IKE.

  There are no restrictions on what can be the replacement protocol for IKE.
I encourage you to check out the proposals and see for yourself.

> One goal that such an alternative could depart from is the goal of affording
> anything like Identity protection. Firstly, it is really hard to deliver
> given all the other things that give away identity, in most cases, of
> communicating parties.  Secondly, and more importantly, there seems to be no
> one clamoring for this feature.  I am not even hearing anything to suggest
> that anyone thinks otherwise.  The only comment I hear on this suggests that
> input from product managers and users would be deemed worthless.  You, and
> perhaps others, appear to have written of one as being apathetic and the
> other as being stupid.  I myself don't subscribe to the view that a few
> really clever people who understand it all can devise the solution and save
> the users from corporate avarice and their own ignorance.  Also, I am not
> sure that many product managers or users are likely to step forward and feel
> comfortable sharing their views given how they are viewed.

  It is interesting that you admit to not knowing the context of the
discussion and did obviously not use the past week (since our last exchange
of emails) to come up to speed on the issues yet you seem to know that no
one wants identity protection. How do you know that? What do they want then?

  If you know what the requirements are then please tell us all what they are
so we can just avoid this (apparently pointless) discussion and get on to
the task of satisfying them. Some people obviously think identiy protection
is needed or we wouldn't be discussing it. But if you know otherwise then
please enlighten us.

  My reference to the product marketing people from the major VPN vendors
was in the support for a group pre-shared key (or worse a NULL pre-shared
key) and XAUTH. Most every "major VPN vendor" supports this horribly
insecure hack. Why? Because customers want it. That's why. And product
management insisted on it being implemented. It is not really apathetic or
stupid. It is more like putting expediency above security. People who would
demand such a thing should be made uncomfortable. I'm glad they don't
work for "major healthcare providers". 

> Once again, this is not a criticism of all the excellent work that you and
> many other people have put in to develop/refine IKE and it's successors.  If
> nothing else, treat this as a suggestion to reexamine the constraints /
> requirements that we may have placed on SuccessorToIKE.

Please, you're making me blush....  

> Couple of final clarifications:
> I mentioned VPNs only as an example.  In most other applications Identity
> protection is equally uninteresting or even less (as in iSCSI).
>
> I meant shared secrets not shared password.

  If that's what you meant then you shouldn't have written "shared password".
But please explain the difference anyway. What sort of authentication 
technique do "VPN solution providers and large users" want?

  Dan.