On Mon, May 18, 2020 at 6:20 PM Roman Danyliw via Datatracker <[email protected]> wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-opsawg-sdi-10: 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 3.2. If keying material is being distributed as a certificate, do > the expected behaviors of certificate process apply? For example, how is > expiration handled? > > -- If a customer downloads a certificate from the publication server and it > is > expired, what should be done? > > -- If a certificate is loaded in the TPM of the device, should the client stop > accepting configurations if it expires? > > ** Section 4.3. “After retrieving the config file, the device needs to > determine if it is encrypted or not. If it is not encrypted, the existing > behavior is used.” What downgrade protection is assumed or recommended here. > A rogue data center employee could re-target a DHCP response to a server of > choice which provides only unencrypted, tainted configuration. It would seem > that a device expecting an encrypted configuration should not accepted > unencrypted ones (or at least this should be a policy consideration). >
Thank you very much for your review. I have addressed these (and below) in https://github.com/wkumari/draft-wkumari-opsawg-sdi/commit/22d2ad52983e03309796867db22b88a5960bf039 (and will be posting a new version of the draft soon, once I address other comments as well). For those following along at home, Roman kindly provided me some text to clarify the above. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** I struggled a bit to understand where this solution was applicable. For > example: > > Abstract: “This document extends existing auto-install / Zero-Touch > Provisioning mechanisms to make the process more secure.” > > Section 1: “this document layers security onto existing auto-install solutions > to provide a secure method to initially configure new devices”. > > -- Which “auto-install” and “zero touch provision mechanisms” is this > updating? I added some text to clean this up, and point at the archetype - Cisco's AutoInstall - https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/15mt/fundamentals-15-mt-book/cf-autoinstall.html It is by no means the only org which does this, but it has been around for a long time, and is probably best known... > > -- What exact preconditions are necessary to make this “solution” (reference > architecture?) applicable? Would this still be useful if the “auto-install” > mechanism was encrypted? What non-DHCP configurations should be considered? > Does the way the device identifier bind to the configuration matter? Because > there is little specificity, it is difficult to review the security > properties. > > ** Per the Security Considerations, what new security services does this > overlay provide? Added some text. Thank you! "This reference architecture is intended to incrementally improve upon commonly accepted "auto-install" practices used today that may transmit configurations unencrypted (e.g., unencrypted config files which can be downloaded connecting to unprotected ports in datacenters, mailing initial config files on flash drives, or emailing config files and asking a third-party to copy and paste it over a serial terminal) or allow unrestricted access to these configurations. This document describes an object level security design to provide confidentiality assurances for the configuration while it is in transit between the configuration server and the unprovisioned device even if the underly transport does not provide this security service. The architecture provides no assurances about the source of the encrypted configuration or protect against theft and reuse of devices. > > ** Section 2. Per “This document extends this (vendor specific) …”, what is > “vendor specific” about this approach? > > ** Section 4.2. Per “The operator will then encrypt the initial configuration > (for example, using SMIME [RFC5751]) using the key in the certificate, and > place it on their TFTP server”, is this always a TFTP server, or is this only > an example – I think this is an example? Ooh, yes. I changed it to "on their configuration server". Thank you! > > ** Section 4.3. Per “Give up, go home” in the figure, is there a retry > procedure? The text above states that “If it cannot decrypt the file, or if > parsing the configurations fails, the device will either abort the > auto-install > process, or will repeat this process until it succeeds.” Good point - I should actually redo the diagram to include the retry, but I'm also trying to keep it uncluttered. For now I just changed it to "Retry or Abort" (this will show up in next commit) > > ** Section 7. Per “An attacker (e.g., a malicious datacenter employee)”, also > a malicious shipping agent. > Good point. Added "e.g., a malicious datacenter employee, person in the supply chain, etc.) " > ** Editorial > -- Abstract. Editorial. I would recommend generalized wording to replace the > phrase ‘smart-hands’-type support. > > -- Section 1. Editorial. “asking the smart-hands to …”, Recommend > generalizing > this reference. I changed it to "remote-hands" and remote support respectively. Thank you! > > -- Section 1. Editorial. “not intended to be an ‘all singing, all dancing’ > fully featured system”, Recommend removing this colloquialism. Fair. Done. > > -- Section 3.1. Typo. s/Each devices requires/Each device requires/ DONE > > -- Section 3.1. Typo. s/cryptograthic/cryptographic/ DONE > > -- Section 4.3. Typo. s/dependant/dependent/ DONE > > -- Section 4.3. s/retrys/retries/ DONE. I'm using VS Code as my XML editor at the moment, and it's lack of integrated spell check exposes my poor typing skills :-) W > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
