Subject: [Isms] RE: Leverage existing infrastructure

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 23 May 2005 17:46:33 -0700

Thanks for your comments.  Please see inline...

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> ...
> 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.

Agree.

> 
> 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.

And they don't have to.  LPSK can be either community-based *or* 
user-based.  It's up to operators to choose.

> 
> 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.

You mean SNMP security should *not* be SNMP-centric?

I think it should be at least an option that SNMP can be
operated independently.  Sometime it may be desirable to 
decouple SNMP users from, say, CLI users.  For example, if 
you have N snmp access views and M CLI access levels (e.g. 
no CLI + regular + enable mode), then by joining SNMP and CLI
users, you have NxM possible combinations of access levels to 
manage.  I am not saying that you should not reuse CLI users,
but we need to give operators a choice.

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

I guess you misunderstood the LPSK proposal (may be that's my
fault :)  LPSK borrows USM key localization concepts, but for
different purposes.  In USM, localized keys (long term) are 
used for MAC and encryption.  In LPSK, MAC and encryp keys are 
generated dynamically (short term), while localized secrets 
are used for authentication (via SRP, CHAP, etc.) 

In addition, LPSK is a generic method that can be used with 
not only USM passwords but also other type of shared secrets
(community strs, CLI passwds, local or remote accounts, etc.)

> 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). 

I think that's in part because USM does not specify a standard 
way to auto-populate the USM table.  It provides only some
suggestions.  LPSK should address that issue by clearly specify
some standard localization method(s).

> 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.

SNMP *is* parts of *their* existing infrastructure too, right?

Anyway, as mentioned above, LPSK can reuse other infrastructures too
(CLI passwords, etc.)

> 
> 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.

Again, using comm str is just one of many LPSK options.  Users
who chooses to use community-based LPSK can reset the old comm 
strs anytime after migration.  Of course that will no longer be
a "zero touch" migration, but it can still be automated using
centralized management appl.

> 
> 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.

Clear-text passwds are not required to generate localized PSK values.  
Anyway, you brought up a good point about different password formats.
Different localization methods may need to be defined, depending on 
whether the passswds are previously stored in clear-text or encrypted.

> 
>    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.

LPSK values can be stored remotely in AAA server.  For example, device
can ask TACACS+/RADIUS server (via CHAP) to authenticate a LPSK value.

> 
>    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.

Password changes can be handled just like before: when a password
is changed, the corresponding LPSK is updated.  If LPSK values are
stored locally, then each device needs to be updated, if they are 
store centrally (AAA server), then the update can be done in one 
place, just like in any other systems.

>       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.

In the end, I think we should give operators both options: 
(1) SNMP-centric (independent) authentication and 
(2) reuse-something-else auth.

Thanks again for giving me a chance to explain.

Regards.

Khanh

> --
> Wes Hardaker
> Sparta, Inc.

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 23 May 2005 20:09:43 -0700

>>>>> On Mon, 23 May 2005 17:46:33 -0700, "Khanh Nguyen (khanhvn)" <[email-masked]> said:

Khanh> You mean SNMP security should *not* be SNMP-centric?

What the operators have indicated over and over to people that they
want is a non-SNMP-centric authentication system.  Yes.  That was the
primary purpose for the creation of the working group: to remove the
burden of maintaining a SNMP-centric user base in addition to their
own.  The majority of the operators don't want a separate user space (*).

Khanh> I think it should be at least an option that SNMP can be
Khanh> operated independently.

I actually agree with you, but that's what they have today and that's
what they don't like.  Some (* from above) may indeed want that, but
if that's the case they already have USM today and are probably happy
with it.

Khanh> Sometime it may be desirable to decouple SNMP users from, say,
Khanh> CLI users.  For example, if you have N snmp access views and M
Khanh> CLI access levels (e.g.  no CLI + regular + enable mode), then
Khanh> by joining SNMP and CLI users, you have NxM possible
Khanh> combinations of access levels to manage.  I am not saying that
Khanh> you should not reuse CLI users, but we need to give operators a
Khanh> choice.

I don't think you can merge authorization (access control) between the
systems and that is not a goal or even one that has been discussed
(because it would likely impossible).

I don't want to continue arguing this point since I think we'll simply
disagree in the end anyway.  What I'm more interested in is if anyone
else agrees with you that they should be separate.  I'm pretty sure we
have consensus that the purpose of the WG is not to create another
parallel user database like LPSK is proposing.

>> reuse *their* infrastructure, not SNMP's.

Khanh> SNMP *is* parts of *their* existing infrastructure too, right?

SNMPv1/v2c may be in use, but a pre-existing community infrastructure
or a USM infrastructure is actually what most want to get rid of even
if they have successfully deployed it.

Khanh> Again, using comm str is just one of many LPSK options.  Users
Khanh> who chooses to use community-based LPSK can reset the old comm 
Khanh> strs anytime after migration.  Of course that will no longer be
Khanh> a "zero touch" migration, but it can still be automated using
Khanh> centralized management appl.

USM today can be automated.  And it is by many products.  Users still
don't want to use it even though it's possible.

Khanh> In the end, I think we should give operators both options: 
Khanh> (1) SNMP-centric (independent) authentication and 
Khanh> (2) reuse-something-else auth.

Agreed.  For 1 we have USM.  For 2 we have the results of ISMS that
should *not* create another database to maintain.  Maybe someone other
than you will disagree with me about this.  Who knows.

-- 
Wes Hardaker
Sparta, Inc.