Subject: Re: [Netconf] zerotouch issues found while preparing -20

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Feb 2018 17:22:38 +0000

Hi Mahesh,

>> Separately, here are a couple other things we might consider doing:
>> 
>> 1) move from PKCS7 to CMS (RFC5652).   CMS is IETF's version of PKCS7.
>> It's practically identical.  The IESG requested this change when the
>> anima-voucher draft went through its IETF Last Call, and so I expect
>> the same change will be requested for this draft as well.
>
> As shepherd of the document, I would prefer that this be addressed 
> now than wait for a IESG request. 
>
> How big a change is this? And what are the differences between CMS and
> PKCS7? Are there any backward compatibility implications?

For the most part, it is a global search and replace.  But, like with the
voucher draft, we will want some language allowing cmsVersion=1, which 
signals that it's actually the legacy PKCS7 format.   We'll also likely 
need to define an OID in the SMI Security for S/MIME CMS Content Type 
Registry, something like "id-ct-zerotouch-information+json".  Lastly,
I'll want to update my tools to process CMS files, to ensure there are
no gotchas that we're not thinking about.

Okay, I'll start looking into this.

>> 2) modify the draft's statement that devices MUST send an IDevID 
>> certificate to one that says devices MUST send an IDevID certificate
>> and/or HTTP-level authentication.   This wording is consistent with
>> RFC 8040 Section 2.5 and, by allowing HTTP-level authentication, it
>> will better represent products shipping by a number of vendors,
>> whereby the installer can, for instance, type in a password into
>> the device while it's booting.  This appears to be a popular
>> low-barrier choice, as implementing IDevID is not easy.
>
> As a contributor I would be ok with RFC 8040 wording.
>
> As a shepherd, how big is the change? Also what is the impact on
> security? Does the Security Consideration section need to be updated?

Hmmm, the IDevID language is engrained.   The certificate and private
key show up in the "Initial State" diagram [1].  The Security Considerations
section would need to be updated.  Importantly, we'd have to say that, if
other credentials are used, they MUST uniquely identify the device.  For
instance, the "username" should be the device's serial-number.  Furthermore,
for provisional connections to an untrusted server, we'd have to explain
that no password should be sent in this case.

[1] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-19#section-5.1

I could do this in a branch, if it helps.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Feb 2018 00:59:53 +0000

Following up on the git commit shared below, here is an update to the 'description' statement for the "configuration" leaf:

https://github.com/netconf-wg/zero touch/commit/f8e2b5af46f2385d6cec2c36832ccb05bea7f97c

Please excuse my company's URL-mangler below.

Kent // contributor

===== original message =====

I found another issue while updating my PoC code to the current draft.  The issue comes from the draft's "zerotouch-information" artifact, a PKCS7 structure, only supporting a JSON-encoded payload.  The reason why it only supports a JSON-encoded payload was discussed on list before, but it goes to aligning with what draft-ietf-anima-voucher does.  The issue manifests itself when the payload encodes "onboarding-information", which has an 'anydata' node called "configuration".  Being 'anydata' inside a JSON-encoded document means that the configuration itself must also be JSON-encoded, but this is a problem for devices that don't support JSON encoded configuration, especially given that it's not possible for a bootstrap server (that may not have access to the YANG for the configuration) to generically convert JSON to XML. 

Stated the issue another way, the current solution couples the encoding of the submitted configuration with the encoding of the envelop that's used to convey the configuration.  

To address that, I propose replacing the 'anydata' node with a 'leaf' of type binary.  I don't foresee any interoperability issue with this change, as already the data sent to the device must be device-specific.  To be clear about this proposal, here is a commit that illustrates the change:

 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_zero-2Dtouch_commit_14d92eec946b50eb980b51670ace6ce8bf2e2334&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=faUqriB9skFYZtE6_oZ7hNbTizENpQ4YshBRdUWH1ZE&s=xsa6WrFHOZGyuJ5mYPrBSnEUFgGnFhiZlJ-yoloEkfg&e=

While this is a technical change, it doesn't change the solution in a material way, so I'm hoping that it doesn't necessitate another last call to approve.  If no objections are raised, I'll also apply this change to the pending -20 update.

<SNIP/>

Thoughts?

Kent  // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 22 Feb 2018 23:16:09 +0000

Finally responding to the point #2 below regarding relaxing to IDevID requirement, here's the git commit that does it:

  https://github.com/netconf-wg/zero-touch/commit/00330bda813bf45bfdfedc077d8de5f6d99e0e7c

Unfortunately, this update also captures a little bit of me converting the normative module "ietf-zerotouch-device" to non-normative module called "example-zerotouch-device".  Please ignore.

Unless there are any objections, I'll merge this branch into master for the -20 update as well.

Thanks,
Kent  // author

Hi Mahesh,

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D19-23section-2D5.1&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vV_Z0ZP3DUf7QDUoYY7GKCDzTslbnJ7ZMEbMRdmcg3w&s=abEL52lwlT6fgx7lZOeYdlJCj-8m009-svd0Q9c-8wg&e=

Kent

_______________________________________________
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=vV_Z0ZP3DUf7QDUoYY7GKCDzTslbnJ7ZMEbMRdmcg3w&s=g_m4WDMK_wYxHTpWPMZDWEuYA9YyM_DmgqXMCsMVIw4&e=