Subject: RE: [Isms] ISMS Operational Scenario/Goal

From: "Nelson, David" <[email-masked]>
Date: Wed, 2 Mar 2005 17:00:22 -0500

Wes Hardaker writes...

> 1) require the user to install and configure security infrastructure
>    they're currently not using, such as an AAA server they weren't
>    previously using, or an AAA server with new extensions that aren't
>    needed for anything but SNMP.

If, in fact, we expect that the target customer for the work product of
ISMS doesn't already use some form of AAA infrastructure today, I would
tend to agree.

If, in fact, the AAA server extensions required to support the work
product of ISMS would not also support any other industry or IETF
efforts (are not needed for anything but SNMP), I would tend to agree.

It is not clear to me, currently, that either of these are true.  More
work needs to be done to make that determination, I think.  

> David's argument (one I agree with) is merely that if you do #1 you
> aren't achieving the original goals set forth in the charter.  IE, to
> reuse existing infrastructures.

If you assume that AAA is an existing infrastructure...  it's reuse.

> If you require them to do something, that's simply not reusing.

Well, there two levels of reusing.  The first is reusing protocols and
products (potentially via version upgrades) that have a wide market
penetration.  The second is using the exact protocols and exact products
(product versions) that a particular customer has deployed now.  I guess
I was advocating the first definition.

Trying to get new features, functionality and scalability without "doing
something" is akin to the children's fable of Stone Soup.  The premise
of stone soup is that you can feed an entire village using only a
cauldron, boiling water and field stones.  The moral of this fable is
that it really takes a bunch of other ingredients, vegetables, potatoes,
meat, and such that the villagers are enticed to supply on the premise
that the nutrition is coming from the stones, and the rest of the
vittles are inconsequential "flavorings".  Something from nothing. :-)

> SNMP exists because other things need to be
> managed.  It would be useless by itself.  And as such, users would
> rather everything never need management but they know this is
> impossible.

I've always wanted to write that universal clairvoyance module to read
the user's minds.  :-)

> If #2 was doable above, then they'd have to do a lot less
> to make use of the protocol that might help them manage their other
> technologies and thus you'll get quicker and greater adoption.

Stone Soup!  :-)

> David never said, nor will he ever if I know him well at all, that an
> AAA shouldn't ever be used as a possible source of authentication
> information for SNMP.  He said it shouldn't be required, and it
> shouldn't be required to _modify_ it in order to make SNMP
> authentication happen.

AAA should not be required to use SNMP, as we know it today.  I find it
hard to envision, however, how the WG goals can be met without using
some form of KDC/AAA server.

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

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 2 Mar 2005 14:37:32 -0800 (PST)

HI,

Please stick with an argument based on facts instead of
stories, especially when the stories do not match the
situation.

On Wed, 2 Mar 2005, Nelson, David wrote:
<stuff cut>
> Stone Soup!  :-)
<stuff cut>

It seems like your argument is that the cost to define, code,
and deploy a new SNMP security model with no changes to
any existing security infrastructure, is more expensive
than defining a new SNMP security model (that is similar
to USM), and defining, coding, and deploying updates to
the existing security models. Is that what you are saying?

Regards,
/david t. perkins

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Mar 2005 14:59:20 -0800

>>>>> On Wed, 2 Mar 2005 17:00:22 -0500, "Nelson, David" <[email-masked]> said:

David> If you assume that AAA is an existing infrastructure...  it's
David> reuse.

Right.  I don't.  That's my point!

60/149 people from my survey used radius.
43/149 people from my survey used tacacs+.

Thus, I couldn't draw from those numbers that AAA was existing for all
people.

(note that there could be overlap in those figures, but why anyone
would run both radius and tacas+ at the same time I'm not sure.  I
actually could check for overlaps if need be;  (I looked at the first
of my response files just to see how easy the grep would be to count.
Interestingly enough the first file that I looked at contained both in
use [and ssh and local-accounts]).

David> Well, there two levels of reusing.  The first is reusing
David> protocols and products (potentially via version upgrades) that
David> have a wide market penetration.  The second is using the exact
David> protocols and exact products (product versions) that a
David> particular customer has deployed now.  I guess I was advocating
David> the first definition.

There are definitely multiple levels, I agree.  The more the better,
though, is what I was arguing.  If you could reuse something else
without augmentation or modification that'd be better than reusing
something else that may or may not be available everywhere.

David> Stone Soup!  :-)

I don't buy your analogy I'm afraid.  It doesn't fit in many ways.
I'm not going to dive into it though, as I don't think it would be
productive.

-- 
Wes Hardaker
Sparta