RE: RESEND: Thoughts on identity attacks

[Edward Wilkinson <ewilkinson@efficient.com>]

 Khaja, I must applauded you. As a person that implements and
 supports this mass of security protocols I to believe that it is way to
complicated for
 most people, and causes far to many interop problems.

 Ed

-----Original Message-----
From: Khaja E. Ahmed [mailto:khaja.ahmed@attbi.com]
Sent: Thursday, February 14, 2002 11:15 AM
To: Dan Harkins; David Jablon
Cc: ipsec@lists.tislabs.com
Subject: RE: RESEND: Thoughts on identity attacks 


Dan,

You have asked (in this and in another message) what I think people are
using and how, what they might really want and what I recommend.

Before I answer those questions I should explain what I believe the threats
to be that we should worry about.  That way there is a frame of reference to
these opinions.  I do not believe that we should devote much energy to
developing military grade security.  Our work should be to invent
technologies for civilian organizations and individuals.  Attackers with the
motivation, funding and capabilities of the KGB, Mossad, NSA or other
governments, etc are not what we should worry about.  (If those dudes are
after your information you have serious problems and nothing from any
standards body is going to help you anyway.)  I do recognize however that
the level of security needed by SWIFT for inter-bank funds transfers (for
example) will be different from that needed by a small company trying to
allow it's employees to telecommute over VPN.  That will require that our
standards accommodate something of a range of solutions.  The worst we need
to worry about is, at the high end of the threat, a serious and capable
cryptographer going over to the dark side and working with some COTS
equipment.  I would not assume that the attacker has access to hundreds of
computers for example.  This is just my opinion - like the rest of the
message - and others may feel completely differently about this.

My 'opinion of what these people are using':

Product developers / companies have done as best a job as they can with
implementations of IKE, sometimes leveraging open source stuff (e.g. Pluto)
and sometimes licensing code from OEMs (e.g. SSH) and rarely developing the
thing entirely in-house.  I suspect that most of their code is not used and
they know it and worry about it.  All that unused and redundant
functionality constitutes moving parts in their products, bugs waiting to
surface, a QA nightmare, a documentation burden, and clutter which impacts
the reliability, supportability and maintainability of the product.  If
there was a small core of standardized, mandatory, minimum functionality
that could be implemented it would make the products more maintainable and
reliable. Also as Phil Hallam-Baker has pointed out, such solutions will
more easily fit on devices with severe CPU and memory constraints.  This
would be all that would be needed for 95% of their customers and the rest
could be served with optional modules / upgrades / add-ons.

Most of their customers, the end users, appear quite content to use shared
secrets.  The knowledge that someone casually sniffing packets will not see
their data and can not easily decrypt it, appears sufficient for most.  The
fact that an attacker would actually have to have a pretty serious level of
competence, resources and motivation to hack at their data is all the
comfort and assurance they need.  At the high end of security consciousness,
most large Financial Institutions, Healthcare/big pharma, and some Fortune
500 companies are trying to be more serious about security.  These guys care
about key sizes to the extent that they want 3DES and not DES.  Even in this
crew Aggressive mode is viewed as quite adequate.  No main mode needed. Some
are venturing into certificate based authentication.  The few who did, have
generally ignored certificate status checking.  No OCSP, no CRLs and a
somewhat relaxed attitude towards certificate life cycle management and PKIX
compliance.  I have no doubt that there are large installed bases doing
everything by the book but they are about as rare as the dodo bird.

The ones I worry about are using NAT and thinking they have a firewall.  And
when I contemplate how many SMEs have NOTHING and are quite happy to have
employees pop their corporate mail from home with no VPN or SSL the mind
boggles. It would seem more urgent to focus on getting this crew to use ANY
security before sweating the ratios of key sizes to amount of data encrypted
if and when they do use some security.  For many small companies in this
category even a group shared-key would be an improvement.   What they need
is some minimal, non-invasive, low maintenance solution.  This is NOT to say
that I think the rest of the world should be dragged down to the modest
security aspirations of this segment but certainly this is a need that is
currently left unserved. Frankly, we deny this segment a useful and adequate
solution by steadfastly refusing to come up with something they can digest.
In fact, it appears that what we deliver is hard to use even for Financial
Institutions and large corporations with huge IT staffs.  In other words,
while we ignore this lot, we give more attention than is valued/utilized to
the somewhat more security conscious users.

My 'opinion of what these people want':
Product developers and companies want simpler standards, with fewer choices.
The rest can be options.  Current options are really not options.  The
choices are really not choices because they are not adequately separated in
the standard.  It would be a boon to engineering teams around the world to
have a standard that clearly articulates a mandatory minimum which is truly
minimal and not knitted along and mixed with the options.  Such a standard
itself would be modular.  That allows for the development of high end, low
end, and mobile/PDA solutions with clear demarcations of functionality.  The
trouble with the 'go write yourself a profile or a BCP' argument is that it
almost never gets done.  First, it is not trivial to do that with IKE and
many other standards. And then to have to once again go through the gut
wrenching consensus building process that the standard already has been
through to get the 'profile' accepted by a community is too painful,
wasteful, intimidating and generally will not get done.  This might be a
crazy idea, but while we are talking about opinions, why not modularize the
standard itself?  If the SuccessorToIKE were to specify clearly a minimum
required as the core and document everything else as optional modules, it
would dramatically increase adoption, acceptance and *use* of the
technology.  A more modular standard would also be facilitate profiling.  It
might even make the process of developing the standard itself easier and
less contentious if additional capabilities when added were discrete
modules.  Reference implementations would be easy to develop and adopt,
basic interoperability testing would be easy.  Manufacturers,
application-classes and interest groups could select identifiable sub-sets
of the standard for their use.  Current IKE, IMHO, does not lend itself to
easy separation of a core minimum that is easily implementable.  Even gnarly
stuff like SSL and PKIX is by comparison easier to profile.  For what it is
worth, the Identrus PKIX profile took less than a day to document. (let's
not discuss the consensus building part).  It was even straightforward to
hack SSL down to something smaller and leaner, (although less flexible) for
use between really weak CPU and low memory, low baud rate IrDA port equipped
devices.   My opinion is, that to do the same with IKE is a good deal
harder.  This might be heresy, but it might be worth considering an approach
completely outside of current ISAKMP, Oakley and IKE shadows and influence.
IMHO these standards deliver a level of sophistication and a wealth of
capabilities that might, at most, be needed by the top 5% of the potential
user population.  The unwashed masses cant handle it and are therefore doing
nothing.  In fact SSL is emerging as a solution where ideally IPsec should
be used simply because SSL (without client auth) is brain dead simple and
easy to implement.

Most users want far less security than we wish to have them use.  Not
because they like being insecure but because we have not yet found ways of
delivering the security without a penalty in usage complexity, product
reliability/robustness and/or cost that exceeds (in the judgment of the
user) it's value.  For what it is worth I am myself a late convert to the
'adequate and no more' security religion.  This came after nearly a decade
and a half of working on and trying to promote security solutions that we
thought were right for the market but the market thought otherwise.  A token
based authentication product died on us in the market 1990.  Our elegant,
GUI driven CC:Mail and MS Mail digital signature / PKI enabler add-on was
given the cold shoulder by users in 1992.  With nearly monotonous regularity
since 1992, every year I have seen at least one PKI and SmartCard initiative
rise, take a few steps forward in some sort of pilot and crash.  It doesn't
matter, it turns out, how secure you want users to be.  It doesn't matter
how secure the standard or standards compliant products are.  They are all
non-starters if they don't meet user requirements.  Perhaps incremental
security is the answer.  The scores of unveilings of the golden solution
have mostly all been let downs with few exceptions - like SSL. ESP combined
with some simple key/SA management protocol can be a huge success.  Not a
large collection of protocols to setup an SA (ISAKMP) to setup an SA (IKE)
to setup an SA (IPsec)!   No I am NOT knocking the brilliant work done by so
many people.  I am just saying that it serves the legitimate needs of too
few and we need something for the rest.

Finally, Charlie Kaufman has beautifully captured and explained how
standards get bloated in congressional fashion.  It is good food for
thought.  If we don't find a way of solving that problem, there isn't much
hope of being able to produce lean, efficient and easy to adopt standards.
He explains how and why 'a camel is a horse designed by committee.'  Perhaps
we can consider things like adopting a process which mandates that there
will always be a cleanly separated 'minimum and mandatory to implement' part
in any standard.  Nothing gets added to it unless a compelling case is made
for it.  Everything else is separated into optional modules etc.

Khaja

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Tuesday, February 12, 2002 4:09 PM
> To: David Jablon
> Cc: ipsec@lists.tislabs.com
> Subject: Re: RESEND: Thoughts on identity attacks
>
>
>   Well not entirely rhetorical. What I was asking for was his opinion of
> what these people want and are using. The mandatory-to-implement
> authentication method for IKE does not distinguish between a "shared
> [secret] password" and a "shared [secret] key". As long as it's shared
> and symmetric the "entropy" doesn't matter. But given how broken the
> mandatory-to-implement authentication method is I'm surprised that this
> is what is being used in the large deployments he was talking about.
> Or maybe he's talking about legacy authentication using RADIUS or the
> like. I don't know. I'd like to know though.
>
>   Dan.
>
> On Tue, 12 Feb 2002 22:27:00 EST you wrote
> > At 01:41 PM 2/12/02 -0800, Dan Harkins wrote:
> > >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote
> > >> 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. [...]
> >
> > I'm pretty sure that Dan was asking a rhetorical question here.
> > But it is a point of common confusion.
> >
> > To help, I propose the following definitions, based on observed
> common usage:
> >
> >         shared [secret] password:
> >                 a low-entropy secret authenticator.
> >
> >         shared [secret] key:
> >                 a high-entropy cryptographic secret.
> >
> >         shared secret:
> >                 a key that was probably derived from a
> password, but used in
> >                 a cryptographic system in which there is
> misplaced hope that
> >                 the secret truly does have high entropy.
> >
> > I think this, plus the ambiguity argument, makes a good case for
> > "shared secret" to be deprecated.
> >
> > -- David
> >
> >