RE: RESEND: Thoughts on identity attacks

["Khaja E. Ahmed" <khaja.ahmed@attbi.com>]

Dan,

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.

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.

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.

As for Identity Protection, it is clear that IKE1 is stuck with it.  It is
less clear that we should accept that as our permanent fate.  I suggest that
at some point if we eliminate that requirement as a goal it is quite likely
that it contribute to the simplification of whatever we come up with as a
method to achieve the goal.

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.

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.

Khaja



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Wednesday, February 06, 2002 10:36 PM
> To: Khaja E. Ahmed
> Cc: Paul Hoffman / VPNC; ipsec@lists.tislabs.com
> Subject: Re: RESEND: Thoughts on identity attacks
>
>
> On Wed, 06 Feb 2002 11:05:52 PST you wrote
> > Paul,
> >
> > Perhaps the fact that there were no responses suggests that not enough
> > people think it is important.  Let me introduce a counter view.
>  I not only
> > think it is not important but I think that pursuit of this goal risks
> > further complicating an already too complicated protocol.  I
> really think
> > our energies are best directed at more important issues.
>
> I don't think you understand the context here. It is not to add some new
> feature to "an too already complicated protocol", it is to determine what
> a new protocol should/must have.
>
> As far as "already complicated protocols" go the one we're stuck with now
> already has a mode of protecting both identities from passive attack and
> also one that protects both from active attack (provided the Initiator
> already knows the Responder's public key). So this discussion is about
> _simplifying_ things by removing what is not needed not further
> complicating
> things by adding something new.
>
> > After a year of discussions on requirements with product
> management of all
> > the big VPN manufacturers, I have never even once heard that identity
> > protection or 'obfuscated identities' are a requirement.  Of
> course as the
> > chair of the VPNC you may know much more about these matters
> and I would be
> > delighted if you or someone could point me at data that
> suggests that this
> > is a requirement among manufacturers and/or the user community.
>
> Product management of all the big VPN manufacturers? Aren't those the same
> ones who said, "We know it's insecure but it's easy to deploy and
> customers
> want it so shut up and implement it."
>
> Product management from any company do not frame debate here. On the other
> hand if someone from product management from a big VPN manufacturer wishes
> to add his or her points of view it would probably be better done directly
> and not through rumor.
>
> > I think most companies find PKI itself too complicated.  Both
> VPN solution
> > providers and large users seem to prefer to stick with shared passwords
> > rather than build support for or manage a PKI.  Things like
> PKIX compliant
> > path validation, CRL / OCSP support, certificate life cycle management,
> > enrollment, etc. scare away all but the most intrepid.  At this point I
> > would NOT recommend adding any more features and would only consider
> > removing/simplifying some.  After there is a large population
> of users we
> > can learn from actual security breaches and address security
> concerns that
> > arise - as they arise - in future enhancements to the protocol.
>
> There is no support for shared passwords with the current protocol so I'm
> not really sure what you're proposing here. Limiting the feature set to
> something that is not there while simultaneously recommending
> against adding
> new features?
>
>   Dan.
>
>
>
>