Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Jul 2016 21:59:29 +0000

I spent some time today trying to get this pkcs#7 idea to work.   I’m able to get the signed-data case working using standard OpenSSL command line, but it seems that getting the unsigned-data case working requires writing code.  For the ‘C’ programming language, it looks like editing the openssl-1.0.2g/apps/smime.c file will do it.  Similar would have to be done for other programming languages (e.g., Java, Python).  Recall that both sides, the controller application and the device, would need to have this code written, hence the desired for language portability...

For now I’ll leave this idea (always using pkcs#7) as an option for us to consider.   To complete the list of options currently on the table, I added in also the idea of using XMLSIG and JOSE.  Recall this was the approach we used earlier, but didn’t like because of the heavy dependency on those xml/json libraries.  Anyway, here’s the complete list now:

Options:

1.       Keep as is (e.g., force device to try both URL resources)   // up to 3 round trips instead of just one

2.       Define a canonical format for XML and JSON encodings   // Not sure if this is even possible…

3.       Define an encoding-independent signature algorithm      // tricky to define, not easy to implement

4.       Encode both resources in a leaf having type “string”        // even though it’s YANG-encoded data

5.       always return a pkcs#7 structure, either signed or unsigned  // unsigned is hard to implement

6.       use XMLSIG and JOSE (for XML and JSON respectively)             // dependency on heavy XML/JSON libraries

I’m think that option #2 is flawed.  That is, even having a canonical format won’t help because the client can request the server return XML or JSON, but likely the data is signed over just one, unless the server has an ability to sign the data dynamically (i.e., it possesses the private key to the owner certificate), which is a huge assumption to make.   One option to fixing this is to say the RESTCONF server can only serve XML or JSON encoding, but I’m unsure if this will be a popular idea either...

Thanks,
Kent

From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Wednesday, June 29, 2016 at 6:38 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?

Trying to move this discussion forward...

An idea not listed below is for the ‘signature’ value (i.e. a pkcs#7 structure) to always envelop the bootstrapping data.  That is, we’d remove the “redirect-information” and “bootstrap-information” from the data-model / API.  More specifically:

OLD:

  module: ietf-zerotouch-bootstrap-server
      +--ro devices
         +--ro device* [unique-id]
            +--ro unique-id         string
            +--ro (type)?
            |  +--:(redirect-information)
            |  |  +--...
            |  +--:(bootstrap-information)
            |     +--...
            +--ro signature?        binary  // an optional detached signature using pkcs#7
            ...

NEW:

  module: ietf-zerotouch-bootstrap-server
      +--ro devices
         +--ro device* [unique-id]
            +--ro unique-id         string
            +--ro bootstrap-data    binary  // a mandatory pkcs#7 structure that wraps the same data
            ...

Some comments:

1) this API is for the bootstrap server’s SBI (southbound api) facing devices; it is read-only and thus does not have to be user-friendly.

2) Though the zerotouch draft says the northbound interface is out-of-scope, it would seem useful for a bootstrap server’s NBI to take care of generating the private-key and CSR and, later, signing bootstrapping data.  That is, the NBI for a bootstrap server might retain the “user-friendly” API defined by the current YANG model (where the tree-structure elements are writable) while internally having logic to dynamically create (signed or unsigned) pkcs#7 structures for devices to obtain.

3) this approach has the downside of forcing bootstrap servers to always serve pkcs#7 structures, even when the data is unsigned, as opposed to only when signed data is needed (as the current draft has it).  Perhaps not a big deal, but it does increase upfront development costs.

4) this approach has the upside of defining a nice artifact encoding for both removable media and DHCP, but with the downside of complicating DNS mappings.  Simple is the solution described in https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-08#section-4.2, but we could bite the bullet and instead *replace* the first four entries listed (hostname + port + anchor + signature) with a single TXT record encoding the four values into a pkcs#7 structure.  That is, there would be *no* SRV records,.  Alternatively, we could allow for redundant data in SRV records, which would be nice for when the data is unsigned.

Thoughts?

Kent

From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Wednesday, May 11, 2016 at 7:20 PM
To: "[email-masked]" <[email-masked]>
Subject: [Netconf] zerotouch/13: Signature over YANG data?

https://github.com/netconf-wg/zero-touch/issues/13

Slide #11 presented during the IETF 95 meeting said:

=====START=====
Current text says that the signature is over the data in whatever form it’s provided (XML or JSON)

This works great for all sources of bootstrapping data but, for the bootstrap server, requires that both the northbound application and the device access specific URL resources:
/ietf-zerotouch-bootstrap-server:devices/device=123456/redirect-information
/ietf-zerotouch-bootstrap-server:devices/device=123456/bootstrap-information

But this approach has issues:

  *   Server MUST NOT change its encoding in any way between the time the data was saved and when the device retrieves the data
  *   These two resources are under a choice node, and the device doesn’t know up front which will be present.
  *   It is desirable for device to just fetch the top-level “device” resource, to get everything in one request

Options:

  *   Keep as is (e.g., force device to try both URL resources) // up to 3 round trips instead of just one
  *   Define a canonical format for XML and JSON encodings // Not sure if this is even possible…
  *   Define an encoding-independent signature algorithm      // tricky to define, not easy to implement
  *   Encode both resources in a leaf having type “string”       // even though it’s YANG-encoded data

Thoughts?
=====STOP=====

In the discussion on this slide, Jeff Haas noted that PKCS#9 is popular in the IETF and that he felt that canonicalization might be a requirement. But Kent noted that canonicalization is practically impossible given that XML/JSON has no guaranteed ordering of tree nodes.

I don't think we have a good solution yet...

Kent