The editing and getting of data specified in these modules is encrypted in motion by nature of the underlying transport. How the data are stored in the data store (e.g., on a device) is not specified. I do not think it is on the YANG module to specify how the data at rest is kept as the ultimate operational config could be set by NETCONF, CLI, or other proprietary manner. Other modules, such as ietf-system, only go so far as to mention the sensitivity of the nodes from a protocol access basis.
The protocol being configured in this case (i.e., T+ over TLS 1.3) mentions as part of its operational considerations correct certificate handling, which gets to more of the handling of key matter at rest. Joe From: Deb Cooley <debcool...@gmail.com> Date: Thursday, August 7, 2025 at 11:57 To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Cc: The IESG <i...@ietf.org>, draft-ietf-opsawg-secure-tacacs-y...@ietf.org <draft-ietf-opsawg-secure-tacacs-y...@ietf.org>, opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org>, Joe Clarke (jclarke) <jcla...@cisco.com> Subject: Re: Deb Cooley's Discuss on draft-ietf-opsawg-secure-tacacs-yang-13: (with DISCUSS and COMMENT) As a general rule then, all these modules are encrypted? in transport only? Deb On Thu, Jul 31, 2025 at 11:34 AM <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote: Hi Deb, Do you still think a change is needed given what was explained so far? Thanks. Cheers, Med De : BOUCADAIR Mohamed INNOV/NET Envoyé : mardi 8 juillet 2025 13:48 À : 'Deb Cooley' <debcool...@gmail.com<mailto:debcool...@gmail.com>> Cc : The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-opsawg-secure-tacacs-y...@ietf.org<mailto:draft-ietf-opsawg-secure-tacacs-y...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; jcla...@cisco.com<mailto:jcla...@cisco.com> Objet : RE: Deb Cooley's Discuss on draft-ietf-opsawg-secure-tacacs-yang-13: (with DISCUSS and COMMENT) Hi Deb, As a general rule, only authorized entities are allowed to read/write. The second para of the sec cons section covers that part. Following paragraphs focus on data nodes that are particularly sensitive. Please note that we avoid repeating considerations already covered in other RFCs; citations to those are used instead. For example, the nodes you referred to are also covered by this text: draft-ietf-opsawg-secure-tacacs-yang: This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to Section 5.3 of [RFC9642] and Section 5.3 of [RFC9645] for information as to which nodes may be considered sensitive or vulnerable in network environments. + Section 5.3 of RFC9642 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. These are the subtrees and data nodes and their sensitivity/vulnerability: The "cleartext-symmetric-key" node: This node, imported from the "symmetric-key-grouping" grouping defined in [RFC9640], is additionally sensitive to read operations such that, in normal use cases, it should never be returned to a client. For this reason, the NACM extension "default-deny-all" was applied to it in [RFC9640]. The "cleartext-private-key" node: This node, defined in the "asymmetric-key-pair-grouping" grouping in [RFC9640], is additionally sensitive to read operations such that, in normal use cases, it should never be returned to a client. For this reason, the NACM extension "default-deny-all" is applied to it in [RFC9640]. + Section 5.3 of RFC9645 says: None of the readable data nodes defined in this YANG module are considered sensitive or vulnerable in network environments. The NACM "default-deny-all" extension has not been set for any data nodes defined in this module. Cheers, Med De : Deb Cooley <debcool...@gmail.com<mailto:debcool...@gmail.com>> Envoyé : mardi 8 juillet 2025 11:47 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-opsawg-secure-tacacs-y...@ietf.org<mailto:draft-ietf-opsawg-secure-tacacs-y...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; jcla...@cisco.com<mailto:jcla...@cisco.com> Objet : Re: Deb Cooley's Discuss on draft-ietf-opsawg-secure-tacacs-yang-13: (with DISCUSS and COMMENT) top posting.... modification and disclosure are not the same. Default deny write still allows reading, no? Deb On Mon, Jul 7, 2025 at 7:24 AM <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote: Hi Deb, Please see inline. Cheers, Med > -----Message d'origine----- > De : Deb Cooley via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> > Envoyé : lundi 7 juillet 2025 12:54 > À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc : > draft-ietf-opsawg-secure-tacacs-y...@ietf.org<mailto:draft-ietf-opsawg-secure-tacacs-y...@ietf.org>; > opsawg- > cha...@ietf.org<mailto:cha...@ietf.org>; > opsawg@ietf.org<mailto:opsawg@ietf.org>; > jcla...@cisco.com<mailto:jcla...@cisco.com>; > jcla...@cisco.com<mailto:jcla...@cisco.com> > Objet : Deb Cooley's Discuss on draft-ietf-opsawg-secure-tacacs- > yang-13: (with DISCUSS and COMMENT) > > > Deb Cooley has entered the following ballot position for > draft-ietf-opsawg-secure-tacacs-yang-13: Discuss > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > -------------------------------------------------------------------- > DISCUSS: > -------------------------------------------------------------------- > > Section 6: Any mention of raw private key, epsk, shared secret MUST > be > protected from disclosure (i.e. encrypted in transit, and in > storage). Any > configuration which specifies TLS1.3 cipher suites, epsk hash, epsk > KDFs MUST > be protected from modification - change of these can be a downgrade > attack. > While I see mention of 'shared-secret', I see nothing about epsk, > raw private > key, or TLS1.3 cipher suite negotiation. [Med] The text calls the parent nodes, not child ones. All those nodes you cited fall under: 'client-identity' and 'server-authentication': Any modification to a key or reference to a key may dramatically alter the implemented security policy. For this reason, the NACM extension "default- deny-write" has been set. > > > -------------------------------------------------------------------- > COMMENT: > -------------------------------------------------------------------- > > Thanks to Robert Sparks for their secdir review. > > Section 4, grouping tls13-epsk: 'Selfie-style reflection' attacks? > Reference? > [Med] The reference is already provided in the text: identities to mitigate Selfie-style reflection attacks."; reference "RFC 9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3, Section 5.1 "; 5.1 of 9258 has the following: ImportedIdentity.context MUST include the context used to determine the EPSK, if any exists. For example, ImportedIdentity.context may include information about peer roles or identities to mitigate Selfie-style reflection attacks [Selfie]. See Appendix A for more ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ details. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
