As a general rule then, all these modules are encrypted? in transport only?
Deb On Thu, Jul 31, 2025 at 11:34 AM <[email protected]> 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' <[email protected]> > *Cc :* The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected] > *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 <[email protected]> > *Envoyé :* mardi 8 juillet 2025 11:47 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected] > *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 <[email protected]> wrote: > > Hi Deb, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Deb Cooley via Datatracker <[email protected]> > > Envoyé : lundi 7 juillet 2025 12:54 > > À : The IESG <[email protected]> > > Cc : [email protected]; opsawg- > > [email protected]; [email protected]; [email protected]; > > [email protected] > > 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 -- [email protected] To unsubscribe send an email to [email protected]
