Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Warren!

Thanks for the response and -11.  More inline ...

> -----Original Message-----
> From: Warren Kumari <[e-mail]>
> Sent: Tuesday, May 19, 2020 2:35 PM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; OpsAWG-Chairs
> <[e-mail]>; opsawg <[e-mail]>; Michael Richardson
> <[e-mail]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with
> DISCUSS and COMMENT)
> 
> On Mon, May 18, 2020 at 6:20 PM Roman Danyliw via Datatracker
> <[e-mail]> 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?

The text in -11 works for me.  If you think there are alternatives to using X.509 in this reference architecture it might be worth mentioning.

> > ** 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.

For the downgrade issue noted above.  I think we need a little more text.  My concern is around the following text:

Section 4.3:
After retrieving the configuration file, the device needs to
determine if it is encrypted or not. If it is not encrypted, the
existing behavior is used.

If a new device supports this architecture and the deployment environment supports it too (which should be known), but the device still gets an unencrypted config, that should be a sign of something suspicious.  I would envision language here that says that devices should abort.

> >
> > ----------------------------------------------------------------------
> > 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.

Thanks for this update.  I think it is also worth adding that it protects configurations at rest on the config server.

OLD
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.

NEW
This document describes an object level security design to provide
confidentiality assurances for the configuration stored at rest on the configuration server; and for 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.

Regards,
Roman

> 
> >
> > ** 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