IETF Logo Mail Archive

Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420)

"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 17 April 2012 02:15 UTC

Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D787D21F8594 for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2012 19:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.045
X-Spam-Level:
X-Spam-Status: No, score=-100.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV+-v0yUZIcm for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2012 19:15:01 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB021F858B for <netmod@ietf.org>; Mon, 16 Apr 2012 19:15:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HlGt/G+o8LACiV3KUxRvmlrto4J3aB3ar4ojNu2xF2l+qlODNq6OWqUHWBPtPSEK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.237.246] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1SJxwa-0001n0-BA for netmod@ietf.org; Mon, 16 Apr 2012 22:15:00 -0400
Message-ID: <000e01cd1c40$0d8f6b40$6b01a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: netmod@ietf.org
References: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer><20120416.202832.486818825.mbj@tail-f.com><000401cd1c02$aedace60$6b01a8c0@oemcomputer> <20120416.222122.489615035.mbj@tail-f.com>
Date: Mon, 16 Apr 2012 19:16:07 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88bb79b07f118a1f5ddaaaf88756ca8b36350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.237.246
Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 02:15:03 -0000

Hi -

> From: "Martin Bjorklund" <mbj@tail-f.com>
> To: <randy_presuhn@mindspring.com>
> Cc: <netmod@ietf.org>
> Sent: Monday, April 16, 2012 1:21 PM
> Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420)
>
> "Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
> > > From: "Martin Bjorklund" <mbj@tail-f.com>
> > 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.
> > 
> > > Nevertheless, it would be great to discuss alternative solutions to
> > > 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.

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

v2.23.0 | Report a Bug | By Email