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

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