Subject: Leverage existing infrastructure (was RE: [Isms] Thoughts on Encapsulation)

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 19 May 2005 18:46:18 -0700

> From: Wes Hardaker
> The right way to think about it, IMHO, is being able to use 
> whatever the operators already have in place.  That was the 
> whole point of the WG.  IE, if they have something in place 
> we can directly leverage then the incremental cost is 0 

I do agree that leverage existing infrastructure is important.
The "minimal deployment efforts" criteria should take into 
account what operators already deployed.  

The problem is that different operators deploys different things.
Your survey indicates that local accounts is the only auth method
that a majority of operators use.  All other methods are < 50%.
So I think leveraging local accounts should be #1 priority.

In addition, I believe we should not focus only on leveraging
*other* management interface (e.g. CLI) while ignore leveraging
existing SNMP deployment itself (e.g. SNMPv1/v2).  I think 
SNMPv1/v2 installed base out there is huge, and that should
be the primary target of our new security model.

Imagine that you can convert the whole SNMPv1/v2 infrastructure
of a company overnight to highly-secure SNMPv3 with "zero touch" 
(except some automated software upgrade) and "zero dependence"
on other external infrastructure (PKI, kerberos, radius, CLI...)
Is that appealing?  I don't want to do self-promoting, but the 
LPSK proposal can do just that.  

Regards.

Khanh

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Wayne Kading" <[email-masked]>
Date: Fri, 20 May 2005 10:00:37 -0500

Khanh,

Your reasoning below is one of the major reasons I preferred the EK
architecture.  I would like to know whether the WG would consider the LPSK
proposal as a mandatory option for ISMS authentication.

Also, what is involved with your reference to "some automated software
upgrade?"

Wayne

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Khanh Nguyen (khanhvn)
Sent: Thursday, May 19, 2005 8:46 PM
To: Wes Hardaker
Cc: [email-masked]
Subject: Leverage existing infrastructure (was RE: [Isms] Thoughts
onEncapsulation)

Regards.

Khanh

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 23 May 2005 11:05:06 -0700

>>>>> On Thu, 19 May 2005 18:46:18 -0700, "Khanh Nguyen (khanhvn)" <[email-masked]> said:

Wes> The right way to think about it, IMHO, is being able to use 
Wes> whatever the operators already have in place.  That was the 
Wes> whole point of the WG.  IE, if they have something in place 
Wes> we can directly leverage then the incremental cost is 0 

Khanh> I do agree that leverage existing infrastructure is important.

It's not "just" important, it's the whole reason the WG was created.

Khanh> All other methods [!local accounts] are < 50%.  So I think
Khanh> leveraging local accounts should be #1 priority.

The problem is not so simple.  Yes, local accounts are the most widely
used but they also don't scale very well.  I think to succeed we'll
likely have to recommend implementation of 2 different services.  Or,
do something that will work for both local accounts and centralized
accounts (eg, radius).  Doing something that supports both will
certainly have a huge impact in potential deployment and thus is
probably what we should shoot for.

Khanh> In addition, I believe we should not focus only on leveraging
Khanh> *other* management interface (e.g. CLI) while ignore leveraging
Khanh> existing SNMP deployment itself (e.g. SNMPv1/v2).

I agree that there is a large deployment of SNMPv1/SNMPv2c.  However,
I don't think that operators are actually happy about that.  I doubt
they wanted to configure community names in all their devices if they
didn't have to.

Khanh> I think SNMPv1/v2 installed base out there is huge, and that
Khanh> should be the primary target of our new security model.

I disagree entirely.  The purpose of this work was to try and move
away from a SNMP-centric authentication system like SNMPv1/2c and
communities and SNMPv3/USM and into a system they already use for
everything else they do (CLI access, web-access, etc).  Merely taking
our existing system and transforming it into another SNMP-centric
system will not help the situation at all.

Khanh> Imagine that you can convert the whole SNMPv1/v2 infrastructure
Khanh> of a company overnight to highly-secure SNMPv3 with "zero
Khanh> touch" (except some automated software upgrade) and "zero
Khanh> dependence" on other external infrastructure (PKI, kerberos,
Khanh> radius, CLI...)  Is that appealing?  I don't want to do
Khanh> self-promoting, but the LPSK proposal can do just that.

I've finally gotten around to reading the LPSK proposal, and I'm sorry
it's taken so long, but in essence  it is essentially a USM clone.
You're merely promoting a new way to generate SNMP-specific keys that
could actually be done today with USM keys for that matter (there is
no reason that at account creation time in a device you couldn't
auto-populate the USM table based on the same information; but no one
does this).  You're proposing having essentially a parallel user
database that is populated either with community string to key
conversions or existing password to key conversions.  This doesn't
meet my expectations on a number of levels:

1) Most importantly, to summarize the above: you're not reusing
   existing infrastructure other than SNMP's own infrastructure.
   That's not what I believe is what operators want.  They want you to
   reuse *their* infrastructure, not SNMP's.

2) community strings have been sent in the clear already; I'd rather
   not convert those previously-passed-unprotected strings to keys
   when an attacker quite possibly may already know the starting data.

2) You're making an assumption about being able to convert existing
   users into LPSK users merely by taking their existing passwords and
   converting them to keys.  This has multiple issues with it:

   a) The passwords may not be stored in the box in the clear.  MD5
      sums, crypt sums, or other one-way hash functions are often used
      to store messed-with passwords locally so that the real
      passwords need not be kept live on the device.  Exceptions to
      this include systems that make use of cram-md5 and similar
      services which require live-password storage.

   b) The accounts may not be stored in the device.  EG, Radius and
      other AAA like mechanisms don't communicate the password to the
      device and thus the device can't bootstrap itself in the first
      place.

   c) What happens when account passwords change either locally or
      remotely.  Those keys need to be updated too, and if they're not
      stored locally then you'd have to have notification of the new
      password or key to use.  This should be avoided if at all
      possible for multiple reasons, including scalability.
      Synchronizing 2 independent user tables will be a pain to make
      work properly and be scalable, robust and not prone to severe
      errors.  IMHO, There should be one database and snmp shouldn't
      have an independent one.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 23 May 2005 16:26:39 -0400

Tongue firmly in cheek ;-)

> they wanted to configure community names in all their devices if
they

This problem has already been solved; device vendors provide default
passwords of "public", and most operators leave them configured that
way. What could be simpler? ISMS problem solved!

David Harrington
[email-masked]