Subject: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respond by 20120420)

From: David Kessens <[email-masked]>
Date: Mon, 16 Apr 2012 01:46:07 -0700

Hi,

During the netmod session at last IETF, there was no opposition to adopt:

http://tools.ietf.org/id/draft-bjorklund-netmod-snmp-cfg-02.txt

as a working group document.

I would hereby like to give the working group a final chance to object
against this proposal.

Please respond to the mailing list by 20120420 if you don't agree that we
adopt this document as a working group document.

Thanks,

David Kessens
---

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Apr 2012 10:33:54 -0700

Hi -

While I suppose it's inevitable that this work will happen, I am
nonetheless horrified by the way the I-D proposes that keys
(and worse still, "passwords") be handled.  This approach
completely undermines the design of USM for preventing
the compromise of one managed device causing the keys
for another device to be revealed.  The configuration management
of keying material needs to be carefully separated from the
rest, and needs to be done in a way that does not undercut
the security of *all* managed devices in an administrative domain.

Randy

----- Original Message ----- 
> From: "David Kessens" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, April 16, 2012 1:46 AM
> Subject: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420)
>
> 
> Hi,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Apr 2012 20:28:32 +0200 (CEST)

Hi,

> the security of *all* managed devices in an administrative domain.

The current draft specifies that only the localized key is ever stored
in the config data store.  I don't understand how that would
undercut the security of all managed devices in an administrative
domain.

Nevertheless, it would be great to discuss alternative solutions to
the problem (configuring keys).

We have a proprietary solution for storing "sensitive information"
like this, and that is to store locally encrypted values.  However,
this requires the encryption key to be stored somehow, and it cannot
be part of the config itself.  Thus, an extra step is needed in order
to replace a device with a backup cofig; first somehow (off line
typically) enter the same passphrase as was used for the old device,
then copy-config the backup.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Apr 2012 11:56:49 -0700

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 16, 2012 11:28 AM
> Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420)
...
> undercut the security of all managed devices in an administrative

Allowing a password (rather than a (localized) key) to be delivered
to a (potentially compromised) managed device undercuts the security
of all managed devices in the administrative domain.  One of the
reasons for using localized keys is to prevent the managed devices
from being able to have a way to figure out the keys of other devices.
I should allow a device to see a password only if I am willing to entrust
the security of my entire network to that device.

> then copy-config the backup.

Another security property of USM that the proposal loses is that with
USM, even if the key update occurs in the clear, an evesdropper
won't know what the new key is unless the evesdropper already knew
the old key.  I'm sure the folks who do key storage will have lots of
ideas about how to implement something on the neconf client side,
but the point is that the netconf server, if that is understood as the
managed device, should never be given a password rather than
a (localized) key.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Apr 2012 22:21:22 +0200 (CEST)

> > the problem (configuring keys).

How would you solve this problem?  I think the problem is not limited
to USM keys, but keys/passwords in general.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Apr 2012 19:16:07 -0700

Hi -

> Sent: Monday, April 16, 2012 1:21 PM

USM is one possible answer, but probably not a palatable one for this group.
:-)

There have been lots of different technologies thrown at the key management
problem space over the years.  I think it would be worthwhile to have a security
guru specializing in that topic (and that's certainly not me!!) give the WG some
pointers to what the current state of the art is, while recognizing that there are
some ways in which the demands put on SNMP keys may seem a little different
from the requirements of user single-signon.  (Think notifications and remotely
executing disman scripts, for starters).

I think it's also worthwhile to spend a little time thinking about what the
configuration management requirements for keying material really are.
For example, is being able to revert the key configuration to what it
was at sometime in the past actually a desirable thing?  Do you want
old keys to be recoverable, or thoroughly scrubbed?  (some jurisdictions
may ask for the former, but security-conscious folks will probably want
the latter)  I'm not going to pretend that I know what the final answer should
be, but I'm pretty confident that in general one would *not* want reverting
a system's operational configuration to yesterday's "known working" state
to also cause any intervening key updates to be undone.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 17 Apr 2012 07:09:40 -0700

"Randy Presuhn" <[email-masked]> writes:

> There have been lots of different technologies thrown at the key
> management problem space over the years.  I think it would be
> worthwhile to have a security guru specializing in that topic (and
> that's certainly not me!!) give the WG some pointers to what the
> current state of the art is

I think the current state of the art with respect to shared secrets (eg,
passwords) is quite simple: don't do it.  For exactly the reasons that
are coming up here: configuring a bunch of boxes with a shared secret
means all boxes have access to it (or in the case of USM, a fortunately
local copy).  I'd say the management station should be delivering
localized keys and that's the best you can achieve. Netconf,
fortunately, should always run over an encrypted protocol and thus is
safe to deliver a localized copy.  You could, if really paranoid, define
a negotiated feature such that the localized key config object would
only be available when an encrypted session was in use.

[I understand the desire to not deliver even those like the keychange
algorithm achieves, but even the USM is typically configured the first
time by manual initialization of the secret outside USM and probably
frequently still over the network].

The state of the art, however, is typically to use public/private key
solutions instead and thus delivery of the public key of the opposite
side only requires that it not be modified and disclosure isn't a
concern.  IE, SNMP over (D)TLS (RFC6353: configuration of which is
defined in the draft) or SNMP over SSH (RFC5592: which there are not
configuration objects for at the moment).
-- 
Wes Hardaker
SPARTA, Inc.