[Agentx] SNMP v3 Security Considerations

"wbenton@aa.aeonnet.ne.jp" <wbenton@aa.aeonnet.ne.jp> Fri, 13 June 2008 14:53 UTC

Return-Path: <agentx-bounces@ietf.org>
X-Original-To: agentx-archive@megatron.ietf.org
Delivered-To: ietfarch-agentx-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E443A698B; Fri, 13 Jun 2008 07:53:27 -0700 (PDT)
X-Original-To: agentx@core3.amsl.com
Delivered-To: agentx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2403A697C for <agentx@core3.amsl.com>; Fri, 13 Jun 2008 07:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB+AU-j-lT4P for <agentx@core3.amsl.com>; Fri, 13 Jun 2008 07:53:22 -0700 (PDT)
Received: from mgkyb2.nw.wakwak.com (mgkyb2.nw.wakwak.com [211.9.231.193]) by core3.amsl.com (Postfix) with ESMTP id 4C1293A698B for <agentx@ietf.org>; Fri, 13 Jun 2008 07:53:22 -0700 (PDT)
Received: from vckyb1.nw.wakwak.com (postfix@vckyb1.nw.wakwak.com [211.9.230.144]) by mgkyb2.nw.wakwak.com (8.14.2/8.14.2/2007-12-27) with SMTP id m5DEroPp082284 for <agentx@ietf.org>; Fri, 13 Jun 2008 23:53:51 +0900 (JST) (envelope-from wbenton@aa.aeonnet.ne.jp)
Received: from aa.aeonnet.ne.jp (aa.aeonnet.ne.jp [211.9.230.92]) by vckyb1.nw.wakwak.com (Postfix) with ESMTP id 3A12230060 for <agentx@ietf.org>; Fri, 13 Jun 2008 23:53:50 +0900 (JST)
Received: from aa.aeonnet.ne.jp (z206.58-98-120.ppp.wakwak.ne.jp [58.98.120.206]) (user=wbenton mech=CRAM-MD5)(pbs=7cj6hq) by aa.aeonnet.ne.jp (8.14.2/8.14.2/2007-12-26) with ESMTP/inet id m5DErnaj004894 for <agentx@ietf.org>; Fri, 13 Jun 2008 23:53:50 +0900 (JST) (envelope-from wbenton@aa.aeonnet.ne.jp)
Message-ID: <48528A12.3020800@aa.aeonnet.ne.jp>
Date: Fri, 13 Jun 2008 23:54:10 +0900
From: "wbenton@aa.aeonnet.ne.jp" <wbenton@aa.aeonnet.ne.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja
MIME-Version: 1.0
To: agentx@ietf.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [Agentx] SNMP v3 Security Considerations
X-BeenThere: agentx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SNMP Agent Extensibility <agentx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/agentx>
List-Post: <mailto:agentx@ietf.org>
List-Help: <mailto:agentx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=subscribe>
Sender: agentx-bounces@ietf.org
Errors-To: agentx-bounces@ietf.org

After having read all of the latest RFC's concerning SNMP v3, I've
notice that there is no mention about one possible weakness when using a
combination of SNMP v3 or SNMP v3 in combination with v2 and/or v1 in a
single device.

Devices such as Cisco Switches and Routers as well as many other
vendor's devices often allow the ability to specify several types of
SNMP support in their configuration.

In that concern, I think a WARNING should be added for the following
combinatoric usage:

1) If SNMP v3 AuthPriv is used in combination with AuthNoPriv
2) If SNMP v3 AuthPriv is used in combination with NoAuthNoPriv
3) If SNMP v3 AuthPriv is used in combination with SNMP v2c
4) If SNMP v3 AuthPriv is used in combination with SNMP v1

All 4 of the above combinations include Encrypted data as well as
PlainText data.

If any device is configured simultaneously with any one or more of the
above combinations, they will be virtually giving away their Encryption
Key because if a device is configured with any PlainText along side
Encrypted text, it will make it very easy to crack the key!

As such, a WARNING against such usage should be included in one or more
of the latest SNMP v3 RFC's where Encryption is mentioned.

Sincerely,
Walter Benton