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, 2 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