Thanks Stephen for valuable review. See reply inline below. -----邮件原件----- 发件人: Stephen Kent via Datatracker [mailto:[email protected]] 发送时间: 2020年3月10日 3:15 收件人: [email protected] 抄送: [email protected]; [email protected]; [email protected] 主题: Secdir last call review of draft-ietf-netmod-factory-default-14
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. [Qin]: Replicating definition in RFC8342 and RFC7950 seems redundant and reference the existing definition means honor existing work and also help reader to find the source of definition,:-) 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. [Qin]: Okay, try to fix this,thanks. 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. [Qin]:the module definition will be evaluated or validate by using pyang tool which has already be part of datatracker with Henrik's support. 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. [Qin] See relevant discussion and response in netmod below https://mailarchive.ietf.org/arch/msg/netmod/5RFxOEODUMMMV0YL2TuojLa203k/ https://mailarchive.ietf.org/arch/msg/netmod/sItCtzXzqNuwKjYOm5_xWINlrvI/ https://mailarchive.ietf.org/arch/msg/netmod/JFurLpsf8d1-3A9QweykoixkKr4/ 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. [Qin]: Thanks, many of your comments are self-explanation comments, no need for further clarification, thanks. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
