Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 3 May 2005 08:33:24 -0700

>From: Salowey, Joe [mailto:[email-masked]] 
>[Joe] In-band and encapsulation approaches either require the addition
>of new fields to SNMPv3/USM messages, changes to the processing of
>SNMPv3/USM messages or both. 
>
>[Joe] Out-of-band minimizes the change to SNMPv3 and USM.  An in-band
>exchange has more impact on existing processing.

Joe,

Your observations make sense to me for symmetric keying approaches like
Kerberos. However, I am having trouble following them to your logical
conclusion. I am stumbling because I suspect that any asymmetric keying
mechanism, such as PKI, will also require changes to the SNMP packet
formats, perhaps including the addition of new fields. Since extending
SNMPv3 to include both symmetric and asymmetric keying technologies is
an explicit goal of mine (i.e., I want SNMP to leverage the major
enterprise-wide authentication systems), I don't understand why this
particular argument would lead us to prefer OOB keying. Or perhaps I am
overlooking something important? If so, I'd appreciate better
understanding your insights. Thanks.

--Eric

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

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 03 May 2005 11:26:05 -0700

Hi Eric,

The key benefit of OOB is that the SNMP protocol does not need to
understand how the keying the happens. The SNMP protocol continues
to use USM for protection of SNMP packets, the keys used by USM for
protection are created by an out-of-band Key Setup Protocol. The Key
Setup protocol supports both symmetric and asymmetric keying.

regards,
   kaushik!

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2005 11:51:44 -0700

>>>>> On Tue, 03 May 2005 11:26:05 -0700, Kaushik Narayan <[email-masked]> said:

Kaushik> The key benefit of OOB is that the SNMP protocol does not need to
Kaushik> understand how the keying the happens. The SNMP protocol continues
Kaushik> to use USM for protection of SNMP packets, the keys used by USM for
Kaushik> protection are created by an out-of-band Key Setup Protocol. The Key
Kaushik> Setup protocol supports both symmetric and asymmetric keying.

Something else does though, and that something else doesn't understand
SNMP today.  Either way something needs to be taught something new.
The keys won't magically get from an existing OOB service into an SNMP
Engine without modification of at least the OOB service and quite
possibly the SNMP engine (I'm not an expert on most of the SNMP stacks
out there, but I doubt all or even most of them provide an API/RPC
that lets you insert running keys into a running SNMP engine without
modification to the SNMP stack to make that happen).

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 3 May 2005 12:05:22 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Kaushik Narayan" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, May 03, 2005 11:51 AM
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>

> modification to the SNMP stack to make that happen).
...

However, any SNMP stack out there that supports USM should provide the
ability to use SNMPv3 to set the keys.  Rather than modifying the SNMP stack,
or modifying the existing "OOB service", one could use an application acting
on behalf of the security administrator to talk to the OOB service, and use
SNMPv3 to set the USM keys.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2005 13:35:25 -0700

>>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn" <[email-masked]> said:

Randy> However, any SNMP stack out there that supports USM should
Randy> provide the ability to use SNMPv3 to set the keys.  Rather than
Randy> modifying the SNMP stack, or modifying the existing "OOB
Randy> service", one could use an application acting on behalf of the
Randy> security administrator to talk to the OOB service, and use
Randy> SNMPv3 to set the USM keys.

The thought had crossed my mind as well, but that still requires
either provisioning of the SNMPv3 service with an initial USM user
(bad IMHO) or requires the service to be run on the same host and a
noAuthNoPriv user with access privileges tied to the loopback address
(or any other form of an internal-to-the-box-trusted-network) which
probably doesn't exist in most implementations today. 

Requiring the setup of just one USM user instead of X is still bad,
IMHO, because operators don't want to do this today either.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 03 May 2005 16:30:14 -0700

Hi Randy,

The use of SNMPv3 to acquire keys generated from OOB key
exchange is something we have been discussing. This does
bring up the issue of requiring to setup a USM "superuser" that
can be used for the key acquisition. This however should not be
a significant issue since we this a local subsystem, setting up and
coordinating a local "superuser" can be done with minimal work.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 3 May 2005 22:26:10 -0400

Can you repost your message with the last sentence rewritten? I
couldn't understand what you said fully.

Could you also justify your conclusion that "coordinating a local
'superuser' can be done with minimal work"?

Thanks,
David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kaushik Narayan
> Sent: Tuesday, May 03, 2005 7:30 PM
> To: Wes Hardaker; Randy Presuhn
> Cc: [email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 03 May 2005 23:03:19 -0700

Hi David,

Here is my previous message

"The use of SNMPv3 to acquire keys generated from OOB key
exchange is something we have been discussing. This does
bring up the issue of requiring to setup a USM "superuser" that
can be used for the key acquisition. This however should not be
a significant issue since with a local subsystem, setting up a
local "superuser" can be done with minimal work."

I was trying to indicate that if indeed SNMPv3 is used as the API
for the keys between the keying subsystem and USM then it
wouldn't be too difficult to setup a local USM "superuser" that
can be used for this purpose. There is actually no co-ordination
required.

regards,
   kaushik!

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 4 May 2005 19:06:30 +0200

Wes

What is acceptable?  Ken said he could not imagine a zero touch secure system
and nor can I.  So at the very least, I have to put in a secret of some shape or
form when I instal the box, along with IPv4 address, default gateway, sysName,
sysContact etc.

Whether that happens to be the key for a preinstalled USM user, a secret used
for OOBK, the password of root/superuser, it makes no difference, I believe it
still has
to be done.

Of course you also have to prevent its re-entry except under controlled
circumstances but that is what we have today (in non-SNMP environments).  And
with SNMPv3, it could be tied into the input of engine id, so both go in
together or not at all.

Tom Petch

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 4 May 2005 11:40:41 -0700 (PDT)

HI,

Tom - the goal is not "zero touch for the box", but "zero touch"
to add support for SNMP. The ideal is that a box is configured
for management without support for SNMP. Then when it is decided
to support SNMP, the only thing that is done is to turn on
SNMP support for the box. Ideally, if syslog targets have already
been set up, then SNMP can use them for notification targets.
Ideally, the identities that have been set up for OTHER management
activities can be used for SNMP request operations on the box. 

> > IMHO, because operators don't want to do this today either.

Regards,
/david t. perkins