Subject: [netmod] Secdir last call review of draft-ietf-netmod-factory-default-14

From: Stephen Kent via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 12:14:52 -0700

Reviewer: Stephen Kent
Review result: Has Issues

SECDIR review of draft-ietf-netmod-factory-default-14

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This is a very brief document- only 9 pages (ignoring notes that are to be
removed before publication)! It is a proposal for a YANG data model that will
allow clients to reset a server to its factory default settings. It also
defines a “factory-default” datastore that enables a client to determine the
values for the default settings for a server. The datamodel is said to conform
to the architecture defined in RFC 8342.

RFC 8342, and RFC 7950, define the terms used in this document, and the
terminology Section (1.1) cites these RFCs when enumerating these terms. This
reader would prefer to have the definitions replicated here for the nine terms
in question. Only one additional term is defined in this document, the
factory-default datastore. The acronym “RPC” (remote procedure call) is not
expanded upon first use.

The description of how to effect a factor-reset RPC, in Sections 2 & 3 seems
pretty thorough, and includes appropriate comments about security-relevant
data, e.g., private keys and certificates. I an not familiar enough with YANG
to evaluate the module definition in Section 4.

Section 6, Security Considerations, calls for use of SSH (RFC 6242) with
NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current,
citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH
with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC
4253 for a description of SSH. 4253 is a very much out of date document; the
integrity and key management algorithms in the original RFC have been updated 3
times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all
outdated. This discussion of SSH security for use with NETCONF, based on the
one citation, seems to be inconsistent with current IETF crypto guidelines.
This is a problem that the net management area should address before this
document is approved.

The discussion of how a factory-reset RPC may isolate a device, is good, as is
the warning about not relying on this RPC to prevent recovery of
security-sensitive data from NV storage.

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 10 Mar 2020 11:58:50 +0000

As an author of netmod drafts I would like to see some general guidance on this issue. Can someone help please.
Balazs

-----Original Message-----
From: Stephen Kent via Datatracker <[email-masked]> 
Sent: 2020. március 9., hétfő 20:15
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-netmod-factory-default-14

Reviewer: Stephen Kent

Section 6, Security Considerations, calls for use of SSH (RFC 6242) with NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current, citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC
4253 for a description of SSH. 4253 is a very much out of date document; the integrity and key management algorithms in the original RFC have been updated 3 times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all outdated. This discussion of SSH security for use with NETCONF, based on the one citation, seems to be inconsistent with current IETF crypto guidelines.
This is a problem that the net management area should address before this document is approved.

The discussion of how a factory-reset RPC may isolate a device, is good, as is the warning about not relying on this RPC to prevent recovery of security-sensitive data from NV storage.