Re: [secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11
Donald Eastlake <d3e3e3@gmail.com> Sun, 02 February 2014 17:22 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476951A00F3; Sun, 2 Feb 2014 09:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4w9nCB1SI8z; Sun, 2 Feb 2014 09:22:57 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5521A00F1; Sun, 2 Feb 2014 09:22:57 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id wo20so7064938obc.0 for <multiple recipients>; Sun, 02 Feb 2014 09:22:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SrPxE0VVxEgSgLa6zx2pSKdwO6gT/lu3Y5ximzvlNBc=; b=HGy5bYSUe45xnNJbLdRygCvbJb4A4DWpGhnoJrgJCCHnMAWlkSJl+lEYS7BibrZMTY KJOCQmhADqAKo1Fi2sFEJrvF1qhlCqLBg//6bD3L3Mgbc9SrXgc+HXYBQlrCf1FCKWfO LF4iNcHUNXF0YKjvt8v0cGriW10NXK43Ra8jCvIijmKL/iwJT2UsIREStkq1a1NuMqV7 0OW2pYCsh+2jpkzpZsMGYeEUAkXInH8N53I964yTBEIOgNLF7BxyggnoA2sL/AxS+6+3 ylXUsQb240xuNVoDUsbODHiQXxS/SNP74yrApsiwsZUbIPlBLMTX1YAQTLsDjTKv6u6v 0ktA==
X-Received: by 10.60.115.6 with SMTP id jk6mr54820oeb.67.1391361772792; Sun, 02 Feb 2014 09:22:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.33.102 with HTTP; Sun, 2 Feb 2014 09:22:32 -0800 (PST)
In-Reply-To: <20140131.211640.309066023.mbj@tail-f.com>
References: <CAF4+nEGv-3px=XbFksFwSOMk8htSnE5f3EyRR_gDe2egRYr02Q@mail.gmail.com> <20140131.211640.309066023.mbj@tail-f.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 02 Feb 2014 12:22:32 -0500
Message-ID: <CAF4+nEE7BSMMJm_OAV626m7Ky97szZ=x-beWb9obY2fuQTxA=g@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: draft-ietf-netmod-system-mgmt.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Sun, 02 Feb 2014 17:22:59 -0000
Hi Martin, On Fri, Jan 31, 2014 at 3:16 PM, Martin Bjorklund <mbj@tail-f.com> wrote: > Hi, > > Thank you for your review! > > Donald Eastlake <d3e3e3@gmail.com> wrote: >> Hi, >> >> 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. > > Actually, the clear text password is never stored: > > The '$0$' prefix signals that the value is clear text. When > such a value is received by the server, a hash value is > calculated, and the string '$<id>$<salt>$' or > $<id>$<parameter>$<salt>$ is prepended to the result. This > value is stored in the configuration data store. > > The client can send a clear text password (over SSH or TLS) but the > server will never store it in clear text. Ahh, OK. >> 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. > > This was discussed in the WG, and we felt that whatever we would say > would be better stated in RFC 6151. Maybe we can be more explicit > about the recommendation: > > OLD: > > This YANG model defines a type "crypt-hash" that can be used to store > MD5 hashes. ^RFC6151^ discusses security considerations for MD5. > > > NEW: > > This YANG model defines a type "crypt-hash" that can be used to store > MD5 hashes. ^RFC6151^ discusses security considerations for MD5. The > usage of MD5 is NOT RECOMMENDED. That would make me happy. >> 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. > > The Security Consideration section is modeled after a template found > at: > > http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines > > I don't mind an update, but I believe we should update the template as > well in this case. > > The current text says that "write operations [...] without protection > can have a negative effect [...]". > > The other paragraphs use the phrase: > > "It is thus important to control [...] access [to these data nodes]". > > I think the current text says the same thing, but I guess it can be > made more explicit: > > OLD: > > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the > default). These data nodes may be considered sensitive or vulnerable > in some network environments. Write operations (e.g. edit-config) to > these data nodes without proper protection can have a negative effect > on network operations. These are the subtrees and data nodes and their > sensitivity/vulnerability: > > > NEW: > > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the > default). These data nodes may be considered sensitive or vulnerable > in some network environments. Write operations to these data nodes can > have a negative effect on network operations. It is thus important to > control write access (e.g., via edit-config) to these data nodes. > These are the subtrees and data nodes and their > sensitivity/vulnerability: OK. >> Trivial: >> >> 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 >> out. > > All fixed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > /martin
- [secdir] SECDIR review of draft-ietf-netmod-syste… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-netmod-s… Martin Bjorklund
- Re: [secdir] SECDIR review of draft-ietf-netmod-s… Donald Eastlake