[secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11

Donald Eastlake <d3e3e3@gmail.com> Tue, 28 January 2014 17:25 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8CE621A0158; Tue, 28 Jan 2014 09:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7xZBU3pdVHCy; Tue, 28 Jan 2014 09:25:43 -0800 (PST)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE021A0146; Tue, 28 Jan 2014 09:25:43 -0800 (PST)
Received: by mail-oa0-f41.google.com with SMTP id j17so752635oag.14 for <multiple recipients>; Tue, 28 Jan 2014 09:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=YYYtz7v6Vx9wYCBVslDy+TaR2rxgSednhhQyilIu7qc=; b=ETYBwZoF5M7lyost4NOJRtCLC5ikuMBqGn5nDR3aCBn3wAl1tRcFA9dehsTqVj0bx8 LKhMNELFTsxpdUO5D58IEQ46mgUd5HFhcGrsVveQ1c9K8k3FigkJcelC4AZdWPcmCDKP L0UcCm9luflyg/4u6W3cVygDGALsrbcZbVNN0QkQLVulOFtGhGwU54Xzj5JP2Xy0w4Ae pMGiJ4+vBjTVZ4L2iH4flTpquC6u0OJ68q8S3mUxVxzm8wVbFv7g6I0SBYO9JN3lXmxu g7Qiiqu2b/kpiAIquZSEmraEacQi2a32KY2XVxTp2iuDECUMFBm3e3S7fA9KB5M1JJ9U wLGw==
X-Received: by with SMTP id ec1mr2030127oeb.20.1390929940934; Tue, 28 Jan 2014 09:25:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Jan 2014 09:25:20 -0800 (PST)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 28 Jan 2014 12:25:20 -0500
Message-ID: <CAF4+nEGv-3px=XbFksFwSOMk8htSnE5f3EyRR_gDe2egRYr02Q@mail.gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: draft-ietf-netmod-system-mgmt.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 17:25:45 -0000


Sorry this review is late.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

I believe this draft is ready with issues.

This draft specifies a YANG data model for configuration and
identification of NETCONF server device information. You might think
there would not be much in the way of Security Considerations for a
"data model" but the model includes User Authentication,  sensitive
writable data objects, and the like.

For user password authentication, there are provisions for storing a
plain text of the password or a salted hash. Hash functions available
are MD5, SHA-256, and SHA-512.

Security Considerations:

The Security Considerations section seems pretty thorough in covering
NETCONF security features such as SSH transport and access controls.
However, I believe the Security Considerations should recommend not
storing passwords as plaintext but rather as a salted hash. While the
Security Considerations section refers to RFC 6151 for MD5 Security
Considerations and having that reference is good, I believe this
document should also recommend that MD5 not be used as the password
salted hash function.

For the list of sensitive readable data and sensitive remote procedure
call operations, the draft is careful to say "It is thus important to
control access to these operations." However, while it is pretty
obvious, these words or equivalent seem to be missing in reference to
the sensitive writable data.


Section 2.3, first line: "need" -> "needs"
Section 2.3, 2nd paragraph, second line: "need" -> "needs"
I believe RPC should be expanded to "remote procedure call" at its one
use in the text of the draft, unless I've expanded the acronym wrong,
which would be proof that whatever it stands for it should be spelled

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA