Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-20.txt

From: [email-masked]
Date: Tue, 27 Feb 2018 22:07:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Zero Touch Provisioning for Networking Devices
        Authors         : Kent Watsen
                          Mikael Abrahamsson
                          Ian Farrer
	Filename        : draft-ietf-netconf-zerotouch-20.txt
	Pages           : 80
	Date            : 2018-02-27

Abstract:
   This draft presents a technique to securely provision a networking
   device when it is booting in a factory-default state.  Variations in
   the solution enables it to be used on both public and private
   networks.  The provisioning steps are able to update the boot image,
   commit an initial configuration, and execute arbitrary scripts to
   address auxiliary needs.  The updated device is subsequently able to
   establish secure connections with other systems.  For instance, a
   device may establish NETCONF [RFC6241] and/or RESTCONF [RFC8040]
   connections with deployment-specific network management systems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-20
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-20

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Feb 2018 21:20:45 +0000

This update addresses all the LC comments, as well as items discussed after the Last Call.  The diff looks large and, in some places, difficult to read (mostly due to rendering issues).  Please see the change log for a complete list of changes.

I believe that the draft is now ready to published.

That said, I wanted to throw out one thing to the WG, to see if anyone thinks it's worth pursuing. The issue is as follows:

1) The draft defines three CMS-based artifacts that each resist tampering through the use of a signatures, but none of which protect privacy through the use of encryption.  

2) The information contained within these artifacts may be considered sensitive in some environments, especially when placing signed onboarding-information on a removable storage device.

3) It would be relatively easy for us to extend the draft to also support encryption as (a) CMS already supports encryption (i.e., the result is still a CMS structure) and (b) the draft can easily explain that the encryption uses the public key from the client certificate's certificate (e.g., the IDevID cert).

If we don't do it now, how hard would it be to add later?  I think that the text at the very end of Section 3.1 would make it a tricky add.  This text is currently very specific about the top-most content-type being the OID id-signedData, whereas in this case we'd want it to be the OID id-encryptedData.

Any thoughts on this?  If nothing else, add a Security Consideration noting the possibility for unwanted disclosure of information?

Thanks,
Kent // author

=====

Abstract:

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetconf-2Dzerotouch_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=YtaCDlahlDcdzpcJMJWWwCq4U1C86VTnBPuAng3iiAQ&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D20&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=w2t3Leq_NTZ-gqhq-73T5UIOtVPDlGp3uIjSvDJ6GFw&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D20&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=LLo_vD0rJGdGqk1TczIHtWLc4HcaTrL4cSMzd2bDxsM&e=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetconf-2Dzerotouch-2D20&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=ut59EsQnGVgPg4P5693lyk76burJw9gYK678Emllg1c&e=

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=lvqR8pmK1dsncN89PZymiyiQ5fiGZ3VU-DLM46y-tz4&e=

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=wl9ec4YJanRPyQNR2VOtG8P2uc3lCco8GMEZjCwV1fI&s=J-whUo3CptmTuqi4KtpPbfEWzqpHu2jAzQqJRc41vBg&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Mar 2018 00:13:47 +0100

> 3) It would be relatively easy for us to extend the draft to also support encryption as (a) CMS already supports encryption (i.e., the result is still a CMS structure) and (b) the draft can easily…

If its not a big deal, allow for encryption of artefacts. Encryption
is a good thing these days.

I looked over your slides and I immediately thought that I would like
to have the combination of the two approaches, i.e., the bootstrapping
artefacts signed and protected plus communication with the servers
protected by TLS. Working with unsigned artefacts and just relying on
TLS protection of the data transfer would bother me. I think it is
crucial that the artefacts can (ideally always) be trusted, not just
the delivery service.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 1 Mar 2018 00:09:09 +0000

> is a good thing these days.

Okay, any more support?

I could create a branch for it and then post a link to a git commit.  At a minimum, we should be able to relax the language to more easily allow encryption to be added in the future.

> protected by TLS. 

The current draft already supports the downloading of *signed* data from a *trusted* bootstrap server and, in fact, has specific text stating that, in this case, the device MUST still validate the signature.

> Working with unsigned artefacts and just relying on

Interesting.  Of course, many protocols only rely on TLS.  The real concern I think is for systems that stage responses, rather than generate them dynamically, as there would then be a window of time between when the data is uploaded to the bootstrap server and when it is downloaded by the device.  The administrator that uploads the data to the server will sleep better at night knowing the data is tamper-proof (i.e. signed).  

Now the question is, would that administrator sleep even better knowing the data is also not visible to prying eyes (encrypted)?   

Kent // as a co-author

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 28 Feb 2018 17:29:01 -0800

Hi -

>> is a good thing these days.

I agree with Juergen's sentiment.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Mar 2018 07:53:49 +0100

On Thu, Mar 01, 2018 at 12:09:09AM +0000, Kent Watsen wrote:
> 
> Now the question is, would that administrator sleep even better
> knowing the data is also not visible to prying eyes (encrypted)?

My answer is 'yes'. We do not know what people will put into the
bootstrapping artefacts but to be on the safe side, we should at
least allow these artefacts to be encrypted (and it is then the
administrators choice whether he requires encrypted artefacts).

/js