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

Hi -

> From: Michael Thomas <[email protected]>
> Message-ID: <[email protected]>
> Date: Tue, 10 Dec 2002 09:20:05 -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]>
> 
>  > > Irrelevant, but IKE,KINK/IPsec and TLS fit your
>  > > definition. This working group decided for its
>  > > own reasons that app layer auth/priv/authz was
>  > > required. As such, none of the usual suspects can
>  > > be used for key management for those SA. We are
>  > > left with a void. This manifestly causes trouble
>  > > with generally poorly conceived and reviewed
>  > > stopgaps.
>  > ...
>  > 
>  > I guess I'm being unusually dense today.  Could you explain how
>  > the IKE,KINK/IPsec and TLS combination delivers the initial
>  > authentication material ("who is superuser and how do I
>  > recognize them") to a virgin box in a wiring closet somewhere?
> 
>    This is quite a gloss on the enrollment problem.
>    There is a vast difference between star topology
>    enrollment O(n) and Hamiltonian enrollment
>    O(n^2) (or it's NxM cousin, "galaxy" topology
>    enrollment). IKE/TLS/KINK all provide O(n)
>    enrollment which can scale to very large
>    numbers. SNMPv3's enrollment is always point
>    to point which ranges from O(n) to O(n^2) with
>    no means of dealing with O(n^2) kinds of
>    problems.

Are we talking about the same thing?  My question is
specifically with respect to the one aspect of key
distribution for SNMPv3 which is not done in-band:
setting up the initial "master key" for an engine.
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.

Scaling properties after that virgin box's "root
password" has been set are another discussion.

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

>  > This is the only part of SNMPv3 key management that is not
>  > addressed by the SNMPv3 protocol and MIBs.
>  > 
>  > (I'd also be curious to learn how the IKE/KINK/IPsec/TLS
>  > combination addresses the question of access control
>  > management.  It might be obvious to you, but I don't see
>  > it yet.)
> 
>    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.

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