Hi Joe, Thank you for your reply! We have updated the document as requested. Please see below for updated files as well as a followup query.
> >> 9) <!--[rfced] Security Considerations: This text does not > >> exactly match the text provided for security > >> considerations of documents that contain YANG modules: > >> https://wiki.ietf.org/group/ops/yang-security-guidelines > >> Should this document be updated to match those? > >> For example: usage of "all" vs. "some" and the additional sentences > >> in the 5th paragraph (which start with "Logging" and "If logging"). > >> > >> Original: > >> There are a number of data nodes defined in this YANG module that are > >> writable/creatable/deletable (i.e., config true, which is the > >> default). These data nodes should be considered sensitive or > >> vulnerable in all network environments. Logging in particular is > >> used to assess the state of systems and can be used to indicate a > >> network compromise. If logging were to be disabled through malicious > >> means, attacks may not be readily detectable. Therefore write > >> operations (e.g., edit-config) to these data nodes without proper > >> protection can have a negative effect on network operations and on > >> network security. > >> > >> Corresponding text on > >> https://wiki.ietf.org/group/ops/yang-security-guidelines: > >> > >> There are a number of data nodes defined in this YANG module that 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: > >> --> > >> [JMC] Your mods to Security Considerations are good. I think breaking > >> out the boilerplate text and the additional “logging” text into separate > >> paragraphs is a good choice. Virtually the entire module is read-write, > >> but the critical “top-level” nodes are “console”, “file”, and “remote” as > >> each of these can have actions that disable logging. The “remote” branch > >> can also be used as a means to exfiltrate data to a nefarious destination. > > > > The Security Considerations section template has been further updated by > > draft-ietf-netmod-rfc8407bis. In particular, the second paragraph has been > > updated. This will affect your next point #10. > > > > This is a reminder to myself to get the yang-security-guidelines page > > updated once rfc8407bis is approved. > > 6) Thank you for letting us know! We have updated the Security Considerations > to reflect what appears in draft-ietf-netmod-rfc8407bis. Please let us know > if the updates are correct. > [JMC] Some of the changes you mentioned last time for the template are not > reflected (e.g., changing “all” to “some”). That change would also be > required by 8407bis. > Joe [rfced] Thank you for pointing this out (and apologies for missing this earlier). We have updated the Security Considerations section to match what appears in 8407bis [1]. Additionally, please note that we have removed the following text from the Security Considerations to match 8407bis. If this text should be re-added to the paragraph (or if there are any further updates needed), please let us know. Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable. Current: 8. Security Considerations This section is modeled after the template defined in Section 3.7.1 of [RFC8407]. The "ietf-syslog" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This module imports groupings from ietf-crypto-types YANG module defined in YANG Groupings for Crypto Types [RFC9640]. Security considerations described in that document apply to this module also. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: ... Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities: … There are no particularly sensitive RPC or action operations. ---------- Updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9742.txt https://www.rfc-editor.org/authors/rfc9742.pdf https://www.rfc-editor.org/authors/rfc9742.html https://www.rfc-editor.org/authors/rfc9742.xml Updated diff files: https://www.rfc-editor.org/authors/rfc9742-diff.html (comprehensive edits) https://www.rfc-editor.org/authors/rfc9742-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9742-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9742-auth48rfcdiff.html (side by side) For the AUTH48 status page, see: https://www.rfc-editor.org/auth48/rfc9742 [1] https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ Safe travels to those who are attending IETF 122 in Bangkok! Thank you, RFC Editor/mc -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
