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

[Kent Watsen <[e-mail]>]

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


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

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://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=

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

Kent



_______________________________________________
Netconf mailing list
[e-mail]
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=