Re: RESEND: Thoughts on identity attacks

["IETF_DavidChen" <ietf_davidchen@hotmail.com>]

Khaja,


Don't see your suggestion make sense:
1) IPSec is the only protocol for secured IP connection.
2) If what you said happen, none will use 'low-end' security IPSec.
    Just as none will buy a car with spec. says a 'low-end' safety standard
is used.
    (such as tires will cause your car crash)

3) Need another protocol for 'high-end' security IP and
    the compability between 'low-end' and 'high-end' becomes issue and
etc....
   (maybe 'middle-end' security will be required :-)

I hope IPSec is 'the best we can offer but not perfect' rather than
what you suggested 'not the best we known and its "ok" to use it'.

--- David



----- Original Message -----
From: "Khaja E. Ahmed" <khaja.ahmed@attbi.com>
To: "IETF_DavidChen" <ietf_davidchen@hotmail.com>
Sent: Friday, February 15, 2002 9:15 PM
Subject: RE: RESEND: Thoughts on identity attacks


> David,
>
> I think I understand your concern.  There is certainly a high end in the
> 'civilian' world that converges with the 'military' world.  One can think
of
> companies like Boeing, Lockheed Martin, and some projects in Intel and IBM
> that are of national security relevance.  This is probably less than 1% of
> the target population for which the IETF develops standards.
>
> I am not suggesting that we build solutions that do not serve their needs.
I
> am suggesting that we not deprive the rest of the population of a usable
> solution in an effort to cater to the needs of this small and select
group.
> We need to develop standards and products that can be used by everyone.
The
> absolute high end of the need curve can and should be catered to by
special
> options that do not get in the way of everyone else.
>
> Khaja
>
> > -----Original Message-----
> > From: IETF_DavidChen [mailto:ietf_davidchen@hotmail.com]
> > Sent: Friday, February 15, 2002 7:19 AM
> > To: Khaja E. Ahmed
> > Subject: Re: RESEND: Thoughts on identity attacks
> >
> >
> > Khaja,
> > I have to point out that:
> > The civilian attacker is called terrorist.
> > The KGB (and alike) attack is called espionage.
> > Have you heard 'Industrial espionage'?
> > Think about who is the 'Industry'.
> >
> > Please define more clearly about 'security for civilian' and 'security
for
> > non-civilian'.
> > Furthermore, if 'Our work should be to invent technologies for civilian
> > organizations and individuals.'
> > as you said then this 'invented' technology is the best available on the
> > face of earth.
> > Why it is only for civilian?
> > Or you have different meaning of 'invention'?
> >
> > --- David
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Khaja E. Ahmed" <khaja.ahmed@attbi.com>
> > To: "Dan Harkins" <dharkins@tibernian.com>; "David Jablon"
> > <dpj@world.std.com>
> > Cc: <ipsec@lists.tislabs.com>
> > Sent: Thursday, February 14, 2002 2:15 PM
> > 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
> > > > >
> > > > >
> > >
> > >
>
>