Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

I'm sorry, I'm not willing to keep this thread
going because it really amounts to the same
equivocation and head-in-sand attitude that has
plagued this WG for years. I've lived through the
problems that Steve seconded. Dismiss them all you
like; the problems remain and SNMPv3 remains a
poor choice for anything but low-fanout
"infrastructure" where shared point to point
secrets are manageable -- or perhaps manifestly
not given SNMPv3's lack of uptake.

	Mike

Randy Presuhn writes:
 > Hi -
 > 
 > > From: Michael Thomas <[email protected]>
 > > Message-ID: <[email protected]>
 > > Date: Tue, 10 Dec 2002 12:11:44 -0800 (PST)
 > > To: Randy Presuhn <[email protected]>
 > > Cc: [email protected]
 > > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
 > > In-Reply-To: <[email protected]>
 > > References: <[email protected]>
 > ...
 > > Randy Presuhn writes:
 > >  > > From: Michael Thomas <[email protected]>
 > >  > Though it's a pain, it is O(n) to establish those
 > >  > initial secrets.  How does IKE/KINK/IPsec/TLS do
 > >  > any better for configuring a virgin box in a wiring
 > >  > closet somewhere.
 > > 
 > >    Wrong. It's O(n*m) for the number of secrets which
 > >    need to be shared. For IKE/KINK/TLS M can be made
 > >    to be 1. For SNMPv3, there is no such way to scale
 > >    back M.
 > 
 > Now I'm *really* mystified.  How can one establish
 > initial secrets for N boxes by only visiting one of them?
 > 
 > For SNMPv3, one needs to visit each virgin box to
 > establish its master key.  Everything else can be
 > automated.
 > 
 > >  > Scaling properties after that virgin box's "root
 > >  > password" has been set are another discussion.
 > > 
 > >    "Root password" is a meaningless abstraction. There
 > >    are shared secrets between hosts. That's all. 
 > 
 > No, such a perspective ignores the basic operational
 > problems of real equipment.  The part that is problematic is
 > establishing the "moral equivalent" of a root password in a
 > virgin box in a wiring closet.  Once that is done, the rest
 > is readily automated.  The cost of physically visiting a box
 > is far greater than the O(n*m) scaling of the automated part,
 > particularly when there are several orders of magnitude
 > difference between "n" and "m".
 > 
 > >  > >    Also: public key identities give the ability to
 > >  > >    use leap-of-faith kinds of enrollment schemes
 > >  > >    to make an explicit tradeoff of explicit
 > >  > >    positive identification for initial enrollment
 > >  > >    vs ease of deployment (cf SSH). Lack of public
 > >  > >    key identities for SNMPv3 makes that
 > >  > >    essentially impossible.
 > >  > 
 > >  > Even with public key systems, how does a virgin box
 > >  > in a wiring closet come to know what it can trust?
 > >  > This is the one point at which the current SNMPv3 docs
 > >  > require "out-of-band" action.  How does the IKE/KINK/
 > >  > IPsec/TLS suite do any better?
 > > 
 > >    1) Initial Enrollment (CA, addprinc...)
 > >    2) Leap of faith (cf SSH)
 > 
 > In other words, it doesn't do any better than SNMPv3.
 > 
 > >    SNMPv3 does not provid a means to leverage those
 > >    mechanisms. 
 > 
 > Your item (1) is exactly what USM suggests.  (2) is what
 > the "kickstart" proposals give us.
 > 
 > >  > >    RFC 2401 defines an access control mechanism
 > >  > >    for ACL-based filtering. I never claimed that
 > >  > >    it was granular enough for VACM/USM access
 > >  > >    control, but to imply that IPsec cannot provide
 > >  > >    access control is flat out wrong.
 > >  > 
 > >  > Uhh... I can't find anything in RFC 2401 that specifies how
 > >  > access control is actually *managed*.  My question was very
 > >  > specifically with respect to how the IKE/KINK/IPsec/TLC
 > >  > combination could address access control management.  Without
 > >  > the ability to manage access control, it seems a theoretical
 > >  > exercise.
 > > 
 > >    Who said anything about "management"? You said you
 > >    weren't sure that IPsec had an access control
 > >    mechanism. That's wrong. 
 > 
 > Please read what I've written before you put words into
 > my mouth.  I've taken great care to consistently refer to
 > access control management in this thread.
 > 
 > >               That's wrong. Also: there's a SPD
 > >    MIB which I assume addresses the management
 > >    angle. 
 > 
 > That brings us back to SNMPv3, doesn't it?  Kinda
 > proves the point.  Specifically:
 >     1) for establishing initial secrets (moral
 >        equivalent of "root password") SNMPv3
 >        fares no worse than IKE/KINK/IPsec/TLC
 >     2) as soon as we start talking about the
 >        management of access control, we're back
 >        in SNMPv3 land anyway
 >     3) the debate shifts from key management per se
 >        to the scaling properties of various key
 >        management mechanisms
 > 
 > >           In any case, this isn't about IPsec
 > >    vs. SNMPv3. It's about SNMPv3's woeful
 > >    inadequacy with regards key management/scaling.
 > ...
 > 
 > Well, I guess this statement is progress from your
 > earlier statement (Decmber 9) that "This is actually
 > a distinct negative for SNMPv3: complete abdication
 > of the problem of key distribution. With COPS and
 > MEGACO you get TLS and/or IKE/KINK. SNMPv3 has nothing."
 > 
 > Now to that question of "woeful inadequacy".  The crux of your
 > argument is the O(n*m) for complete rekey/update.  This is
 > really bad is N and M  are of the same order of magnitude.
 > When we're talking about network management, there are
 > normally several orders of magnitude difference between N
 > and M, making it much less of an issue.  The question for the
 > midcom folk would be whether that USM properties which make
 > it acceptible for network management would hold true in the
 > midcom environment.
 > 
 >  ------------------------------------------------------
 >  Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 >  [email protected]  2141 North First Street
 >  Tel: +1 408 546-1006   San José, California 95131  USA
 >  ------------------------------------------------------
 >  My opinions and BMC's are independent variables.
 >  ------------------------------------------------------