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

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Sep 2016 23:39:06 +0000

This issue has been quite challenging, but I think that I’m now ready to make a recommendation, which is to say that device should assume that the data signed is the relevant snippet of text, as it’s encoded in the XML/JSON document.  This is consistent with the current definition of the ‘signature’ leaf, which says:

           This signature is generated using the owner's private
           private key and an owner-selected digest algorithm over
           the redirect-information or the bootstrap-information
           nodes, whichever is present, and in whatever encoding
           they are presented in (e.g., XML, JSON, etc.).

To be more clear, the device would have to perform a text-level editing operation, to extract the signed data from the XML/JSON document.  So, for instance, in the examples here (https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-09#section-7.2), the device would extract all the text between (and including) the <redirect-information> and </redirect-information> elements, and likewise between the <bootstrap-information> and </bootstrap-information> elements.  A similar edit would be needed if the text were JSON encoded.  Note: it doesn’t matter if the resulting snippet is itself a valid XML/JSON document, all the matters is that the device can verify snippet in situ.

On the bootstrap server, a similar text-level editing option is required, sort of.  The most obvious implementation would be to have the bootstrap server sign data, after having serialized it to a message format to send to the device.  Being able to do this requires the device to either possess the signing key (i.e., the owner certificate’s private key) or be able to submit a signing request to a signing server that has it (e.g., an HSM).   More complex implementations are possible that obviate the need for the bootstrap server to sign the data dynamically (i.e., at the time the device is requesting it), if only a push-down model is possible.

What do folks think?  Can we move forward with this approach?    If no objections are raised by a week from today, I’ll assume that it’s okay to move forward with this approach.

Thanks,
Kent

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

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 desire 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: Kent Watsen <[email-masked]>
Date: Mon, 19 Sep 2016 23:48:41 +0000

In case it’s not clear how common an issue this is, the bootstrap server needs to, for the sake of the device, provide “signed data” when a device establishes a provisional connection to it (i.e., the device blindly accepts the bootstrap server’s TLS certificate).   The primary reason for why a device would have to establish a provisional connection is because it didn’t learn about the bootstrap server in a secure manner (e.g., it received unsigned ‘redirect-information’).  So, in the scheme of things, this won’t be an overwhelmingly common situation.

Kent

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

On the bootstrap server, a similar text-level editing option is required, sort of.  The most obvious implementation would be to have the bootstrap server sign the data after having serialized it to a message format to send to the device.  Being able to do this requires the bootstrap server to either possess the signing key (i.e., the owner certificate’s private key) or be able to submit a signing request to a signing server that has it (e.g., an HSM).   More complex implementations are possible that obviate the need for the bootstrap server to sign the data dynamically, but the draft doesn’t need to go into it.

Thanks,
Kent

Options:

Thanks,
Kent

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 20 Sep 2016 06:28:55 +0000

Hi Kent,

Just a question from a “practical” point of view.  What is the view of the operators on this?  Reading below to me it seems they may have to provide quite some infrastructure that is currently not there (yet) – at least as far as I am aware.  Is there any point of view from the network operator’s side?  Can we assume they are aware of all the consequences?

Best regards - Vriendelijke groeten,

Bart Bogaert

Broadband-Access System Architect Data

Contact number +32 3 2408310 (+32 477 673952)

NOKIA

Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author.

From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: 20 September 2016 01:49
To: [email-masked]
Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?

Kent

 

Thanks,

Kent

 

Options:

Thanks,

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Sep 2016 19:03:49 +0000

Hi Bart,

Thanks for your comments.   I’d also like to get operator feedback here.    I assume your question/concern specifically regards this issue (#13) and so the “extra infrastructure” regards what’s needed to handle the various solutions outlined below, specifically the one I’m leaning towards.

So my thoughts on this are:

1) unless the device is configured to trust an Internet-based bootstrap server out-of-the-box, and the deployment chooses to use that approach exclusively, then the deployment will need to *step up* to signing data.  This is equally true whether for files stored on removable storage, DHCP, DNS, or a bootstrap server.   It’s just how to sign data hosted on a bootstrap server that is in play here with issue #13.

2) That said, this stepping up to sign data (for any purpose) is where much of the extra infrastructure will come into play.   This infrastructure would cover all of the following: generating a private-key, generating a certificate signing request, setting a signed certificate (e.g., the owner certificate), setting ownership vouchers as they’re made available and, of course, signing the bootstrapping data.

3) While it’s possible that a deployment could do everything themselves using scripts and the `openssl` command line utility, I suspect many will want the functionality integrated into their NMS.

4)  I also think that many will want the bootstrapping server functionality integrated with their NMS, and if so, then having the system dynamically-sign data sent to devices is easy to implement.   For those deployments that don’t want the bootstrapping server integrated with their NMS. then there are two options:
4.a) have the bootstrap server dynamically send a signing-request to the NMS
4.b) implement the bootstrap server to ensure that the bootstrapping data doesn’t change between when it’s signed and when it’s sent to devices.

BTW, most of the above is out-of-scope for the draft.   The draft (per the decision to #13) is only saying how the signed data should be processed by devices, which *implies* how it needs to be assembled by bootstrap servers.  How exactly this is achieved is out-of-scope to the draft.  1-4 above merely discuss my own thoughts on it, FWIW.

Thanks again,
Kent

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tuesday, September 20, 2016 at 2:28 AM
To: Kent Watsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Netconf] zerotouch/13: Signature over YANG data?

Hi Kent,

NOKIA

<<

Kent

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 13, 2016 at 7:39 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?

Thanks,
Kent

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

Options:

Thanks,
Kent

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Thu, 22 Sep 2016 05:06:48 +0000

Ken,

Thanks for the feedback.  I do understand that these considerations are out of the scope of the draft but the consequences of the available option may have a big impact on which solution is taken (or even worse  whether it will be adopted by the operators for reasons of too much additional work).

Bart Bogaert

NOKIA

<<

From: Kent Watsen [mailto:[email-masked]] 
Sent: 20 September 2016 21:04
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]
Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?

Hi Bart,

Thanks again,

Kent

Hi Kent,

Bart Bogaert

NOKIA

<<

 

Kent

 

Thanks,

Kent

 

Options:

Thanks,

Kent