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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 18 May 2020 15:20:03 -0700

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

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

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

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

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

** Section 7.  Per “An attacker (e.g., a malicious datacenter employee)”, also
a malicious shipping agent.

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

-- Section 1. Editorial. “not intended to be an ‘all singing, all dancing’
fully featured system”, Recommend removing this colloquialism.

-- Section 3.1. Typo. s/Each devices requires/Each device requires/

-- Section 3.1.  Typo. s/cryptograthic/cryptographic/

-- Section 4.3. Typo. s/dependant/dependent/

-- Section 4.3. s/retrys/retries/

---

From: Warren Kumari <[email-masked]>
Date: Tue, 19 May 2020 14:35:24 -0400

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/

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.

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

> ** Per the Security Considerations, what new security services does this

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.

> an example – I think this is an example?

Ooh, yes. I changed it to "on their configuration server". Thank you!

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

> a malicious shipping agent.
Good point. Added "e.g., a malicious datacenter employee, person in the
supply chain, etc.) "

> -- Section 1.  Editorial. “asking the smart-hands to …”, Recommend generalizing

I changed it to "remote-hands" and remote support respectively. Thank you!

> 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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 21 May 2020 14:08:55 +0000

Hi Warren!

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

> -----Original Message-----
> From: Warren Kumari <[email-masked]>
> Sent: Tuesday, May 19, 2020 2:35 PM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; OpsAWG-Chairs
> <[email-masked]>; opsawg <[email-masked]>; Michael Richardson
> <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with
> DISCUSS and COMMENT)
> 
> > 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
> > ** 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).
> >
> 
> 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.

> > Section 1: “this document layers security onto existing auto-install
> > solutions to provide a secure method to initially configure new devices”.
> >
> 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...
> 
> >
> > 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?
> 

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

OLD

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?
> 
> > ** 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"
> > ** 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'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