Subject: Re: [Netconf] WG LC for zerotouch

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Oct 2017 18:58:11 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> Hi Martin,
> 
> I trimmed the discussion down to just the open threads.
> 
> 
> >> > o  Section 7.2
> >> >
> >> >  Adding custom query parameters like this breaks the normal YANG
> >> >  contract.  If I understand this correctly, the instance data tree
> >> >  presented to the client is supposed to change based on these query
> >> >  parameters.
> >> 
> >> Correct.  The idea is that the response could vary based on the input
> >> query params.  Of course, in case there was any doubt, the response 
> >> would always conform to same YANG schema.
> >
> >See below.
> >
> >> >  If you really need to have that functionality, it would better to
> >> >  model the device-specific data as an action; input would be the
> >> >  os-name, os-version etc, and output would be the
> >> >  zerotouch-information and voucher etc.
> >> 
> >> I thought of this as well, but didn't do anything about it as my 
> >> last message to the list said that we'd add "query parameters"
> >> and I wanted to follow through on that statement.
> >> 
> >> But what is the issue?  Is it primarily that using query params 
> >> on GET should be limited to returning different representations
> >> of a resource, and this use seems to be returning different 
> >> resources altogether?
> >
> > Yes, this is my concern.  A normal RESTCONF / YANG server has *one*
> > single instance of the operational state, and it just provides an API
> > to this data.  It can be filtered and pruned based on access rights,
> > but not modified from the outside based on query parameters.
> 
> I agree, it seems more proper.  Okay, let's make this change.  No
> objections from the WG, right?  As a heads-up for those following
> along, this change doesn't affect the essence of the solution, but
> the diff will appear somewhat big...
> 
> 
> >> FWIW, if we were to do this, we might also consider moving the 
> >> 'serial-number' field from the URL to an input field
> >
> > Hmm, did you mean 'unique-id'?
> 
> Yes. But what about the idea, moving 'unique-id' from the URL path
> to an input param?  Or, even more dramatically, we could remove 
> 'unique-id' altogether, relying instead on the RESTCONF username
> extracted from the DevID certificate?

See below.

> If relying on the extracted username, note that none of the 
> 'cert-to-name' identities defined in RFC 7407, which is also
> used in draft-ietf-netconf-restconf-client-server, would work.
> The 'common-name' identity is closest, but what is really needed
> is a combination of a 'serialNumber' attribute and an optional
> 'hardwareModuleName' attribute (not all DevID certs define it).

Ok.  I've tried to find a spec for the DevID, but couldn't find a
public version.

> I suppose that this is an issue for the afore-mentioned restconf
> client/server draft more so than this one though.  Still, since
> we're talking about it, assuming we did this, would that draft
> add said identities, or would a 7407bis be better?

I think that such an identitiy could be defined in this draft.  Isn't
such an identity quite specific to this use case?

> >> , and make
> >> a similar change to the 'update-progress' action.  But that then
> >> would mess up your NACM rule below.  Thoughts?
> >
> >We can have:
> >
> >  list device {
> >    key unique-id;
> >
> >    leaf unique-id { ... }
> >
> >    action get-bootstrapping-data {
> >      input {
> >        leaf os-name { ... }
> >        leaf os-version { ... }
> >        ...
> >      }
> >      output {
> >        leaf zerotouch-information { ... }
> >        leaf ownership-voucher { ... }
> >        leaf owner-certificate { ... }
> >      }
> >    }
> >
> >    action report-progress {  // I like this name better :)
> >      ...
> >    }
> >  }
> 
> Yes, this is roughly what switching to an action statement would look
> like though, pending on the above discussion, we may use top-level RPCs
> instead of actions, if relying on the RESTCONF username.
> 
> I agree, 'report-progress' does seem better.  It's a minor thing, but
> happy to oblige.  (no objections from the WG, right?)
> 
> 
> >> > o  Section 4.4
> >> >
> >> >     When a device is
> >> >     not able to trust a bootstrap server, it MUST NOT send its IDevID
> >> >     certificate in the form of a TLS client certificate
> >> >
> >> >  How will the server authenticate the client in this case?
> >> 
> >> The idea is that the server doesn't auth the client in this case.
> >> The goal behind not sending the IDevID certificate was so a rouge
> >> bootstrap server wouldn't be able to discover the device's serial
> >> number, which is why Appendix B suggests also masking the serial
> >> number the device sends in the URL.  That said, we might need to
> >> rethink this, especially in conjunction with your next comment.  
> >> (continued below)  
> >> 
> >> 
> >> >  I see that in section 7.3 you have:
> >> >
> >> >   Note that the bootstrap server MUST NOT process a progress update
> >> >   from a device without first authenticating the device.  This is in
> >> >   contrast to when a device is fetching data from the server, a read-
> >> >   only operation, in which case device authentication is not strictly
> >> >   required (e.g., when sending signed information).
> >> >
> >> >  But the server is a normal RESTCONF server, so it will follow
> >> >  section 2.5 of RFC 8040; it will require clients to be
> >> >  authenticated.
> >> 
> >> I was hoping that the draft could suppress this auth requirement
> >> for this specific "untrusted" interaction.  In essence, reducing
> >> the bootstrap server to a simple file server providing anonymous
> >> read-access.
> >> 
> >> But in the security analysis of things, it comes down to what's 
> >> more important to prevent:
> >>  a) a rogue server discovering a valid device's serial number,
> >>     while not being able to provide the device a response the
> >>     device can trust, or
> >>  b) a valid server giving signed redirect information to a
> >>     rogue device, where the information given doesn't provide
> >>     the device any more information than the device must have
> >>     already had to make the request in the first place, other
> >>     than a confirmation that indeed that serial number is one
> >>     that the server is expecting.  
> >> 
> >> Looking at it this way, (b) is more important to prevent and, 
> >> besides:
> >> 1) there is already a Security Consideration related to the use
> >>    of serial numbers in the solution, so (a) seems to be just
> >>    more of the same, 
> >> 2) rogue connections could play havoc with the server's logs, and
> >> 3) (to your point) it would be tricky business to define an
> >>    exception for the standard RESTCONF server to follow.
> >> 
> >> All this is to say that I think we should go back to the device
> >> always sending its IDevID cert and, of course, the server always
> >> authenticating the device.  But I also think that a device should
> >> continue NOT sending any other information (i.e. query params,
> >> progress updates, etc.), beyond its serial number & IDevID cert,
> >> until it can fully authenticate the server.
> >
> > Ok.
> 
> Okay, it seems that we agree.  Any objections from the WG?  In case it's
> unclear, this change is fairly significant from a solution-perspective.
> It will also have a non-trivial impact from a draft-diff perspective.
> Please chime in now with any opinions now.
> 
>  
> >> > o  Section 5.6
> >> >
> >> >     Upon rebooting, the device MUST still be
> >> >     in its initial state, causing the bootstrapping process to run again,
> >> >     which will eventually come to this very point,
> >> >
> >> >  Why this MUST?  What if the new boot image contains other factory
> >> >  defaults that does not enable ZTP, would that be illegal?
> >> >
> >> >  I would think that implementations are free to do whatever they want
> >> >  in case of errors.
> >> 
> >> Maybe not *illegal*, but it would certainly brick the device at that
> >> point.  Would just reducing the "MUST" to a "must" suffice, or should
> >> we add a qualifier along the lines of "in order for the solution to
> >> work..." ?
> >
> > I would just say something like 
> >
> >     Upon rebooting, if the new image also enables zerotouch, the
> >     device will still be
> >     in its initial state, causing the bootstrapping process to run again,
> >     which will eventually come to this very point,
> 
> Okay.
> 
> 
> >> >    In the case of errors, the device MUST reset
> >> >    itself in such a way that forces a reinstallation of the boot image,
> >> >    thereby wiping out any bad state the script may have left behind.
> >> >
> >> >  Is this also required?  Why can't stop and wait for manual
> >> >  intervention be allowed?
> >> 
> >> It could, but again, it would brick the device.  Same question as above,
> >> would reducing the "MUST" to a "must" suffice, or should we add a 
> >> qualifier along the lines of "in order for the solution to work..." ?
> >
> > Well, this depends if the error is transient or not.  If it is not
> > transient, it will just happen again and again.
> 
> Maybe, maybe not.  The device could potentially land onto another/different
> source of bootstrapping data that works the next go around.  The hope is
> that the device keeps trying (and posting progress-updates regarding its
> errors) ad infinitum until things eventually clear up.  For instance, an
> admin eventually takes notice and administers corrective action.

Ok.

> > I don't have a strong opinion, but I would probably be silent about
> > what to do in case of these kinds of errors.  Leave that to the
> > implementation to figure out.
> 
> I feel that it's critical that manual intervention is never required.
> Yes, a manual step could be employed, but it should be a rare step.  I
> think it's best to say something along these lines.  I'll try to state
> this more clearly.

Ok.

> >> >  I suggest you shorten the lines of the examples even more, so that
> >> >  the examples are properly indented in the draft (they are currently
> >> >  outdented)
> >> 
> >> It's hard to make the lines much shorter with the URN being so long.
> >> Options are 1) don't indent just the xmlns line or 2) move from two-
> >> space indent to single-space indent.  Do you have a preference?
> >
> > In the second example you use (1).  You can also use "\", which you
> > are also already using.
> 
> So I do, albeit only in the HTTP-header parts, not the HTTP-body parts.
> 
> FWIW, my build-script inserts source files in situ as directed by
> processing instructions. I can modify the build-script to do the 
> auto-'\' insertion logic on some column-boundary, but it may need
> a complimentary update on the extraction tools.  Do we need some 
> sort of standard around this?
> 
> I'm aware that here you're only talking about examples, which 
> currently are not extracted via tools, but the same auto-'\' 
> insertion logic could also help with the YANG modules, as they
> could become unwieldy too...though I suppose liberal use of 
> groupings could always be employed to keep line-lengths in
> check.  Okay, but still, a YANG Doctors discussion at IETF 99
> suggested introducing the ability to auto-extract and validate
> examples in drafts too, to automate as much of the YD review
> process as possible, so still I think there may be a need for
> a '\' standard of some sort here.  Thoguhts?
> 
> 
> 
> > I just found another outdented figure in section 5.3, which probably
> > is easier to fix.
> 
> Huh?  I don't see it.  The figure in 5.3 looks okay to me...

Yes, my bad.  I think I meant 5.2.

> >> > o  Section 9
> >> >
> >> >  Should you also mention that /device list should be protected by
> >> >  nacm rules?
> >> 
> >> Yes, indeed, I left out the standard security template for the bootstrap
> >> server YANG module.  Will add.
> >> 
> >> 
> >> >  If the RESTCONF user name is the device's unique-id, then a single
> >> >  NACM rule can be used:
> >> >
> >> >       <rule>
> >> >         <name>allow-device</name>
> >> >         <path xmlns:ztbs="urn:ietf:params:xml:ns:yang:\ietf-zerotouch-bootstrap-server">
> >> >           /ztbs:device[ztbs:unique-id=$USER]
> >> >         </path>
> >> >         <access-operations>read</access-operations>
> >> >         <action>permit</action>
> >> >       </rule>
> >> 
> >> Yes, but would you expect this to appear in the draft?  Typically, the specific
> >> NACM rule syntax is left as an exercise to the reader...
> >
> > In order to do this, the "username" must be the same as the
> > "unique-id".  This requires the client cert to be constructed
> > properly.
> 
> Agreed.  In this case, the client cert is a DevID cert, and  802.1AR 
> governs its construction.  Not too many options there.  Of course, 
> the mapping of said cert to username is being discussed above wrt the
> cert-to-name mapping logic... 
> 
> 
> >> Since the NACM rule is not obvious, and due to the cert implications,
> >> I think it would be very helpful with an appendix that describes how
> >> this can be set up.
> 
> I think that this will depend on if we go with an action or a top-level 
> RPC. If an action, then NACM may have a place and an example may help.
> But, if using a top-level RPC, then it seems that the server has no 
> option but to auth the DevID cert and provide a RESTCONF username-specific
> response - NACM can't constrain it any further, right?

Correct.

> (note: this seems
> more secure to me - I like it)

Hmm, I think it is less clear.  With an explicit list and actions, you
can use NACM to do the access control.  With top-level RPCs, the
implementation of the RPC has to do the access control.

Also, a list of devices is more transparent - I mean, this list must
somehow exist anyway, but with top-level RPCs it will be hidden.
Maybe implementations want to add additional objects to this list, for
monitoring or something.

> >> > o  Other comment
> >> >
> >> >  Is it assumed that there will be a vendor-specific YANG module to
> >> >  enable the zero-touch process?  Did you consider an
> >> >  ietf-zerotouch-device module for this purpose?  Such a configuration
> >> >  must be carefully designed to allow for a "merge" configuration file
> >> >  to actually disable the zero touch process.
> >> 
> >> It is assumed to be vendor-specific currently.  I have not thought to
> >> define a ietf-zerotouch-device module as of yet that, presumably, would
> >> contain a boolean or an enum (but not a p-container) for enabling the
> >> service.  Do you think we should add such a module to the draft, or just
> >> put a note somewhere about it?
> >
> > I don't have a strong opinion, but if there's not a standard module
> > for this, the text should mention that it is assumed that vendors
> > define this themselves.   Hmm, I think I would prefer a standard
> > module; it would make the solution more complete.
> 
> We can add a module, but maybe it should be called something like
> ietf-zerotouch-bootstrap-client, to mirror the ietf-zerotouch-
> bootstrap-server module? - though this may be a mismatch as the
> former regards a southbound protocol and the latter regards a
> configuration model...
> 
> Maybe we can discuss what would be in this model.  I'm not sure if
> I'm oversimplifying it, but I think the module might be just a single
> config true leaf called something like "enabled".   There might also
> be some config false leafs for the stuff mentioned in section 5.1, 
> though it doing so is not so important since the bootstrapping only
> occurs once (not ongoing management).  So a module would primarily
> be for the "enabled" leaf.  Anything else?  Still think it's worth it?

I'm not sure.  It does seem odd to write that we expect vendors to
provide this single leaf in a proprietary module, but maybe it is ok.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Oct 2017 00:54:09 +0000

Hi Martin,

Again, trimming down to just open threads.

> Ok.  I've tried to find a spec for the DevID, but couldn't find a

Here's the part you're looking for:

  7.2.8 subject
  The DevID subject field shall uniquely identify the device 
  associated with the particular DevID credential within the
  issuer’s domain of significance. The formatting of this field
  shall contain a unique X.500 Distinguished Name (DN). This
  may include the unique device serial number assigned by the
  manufacturer or any other suitable unique DN value that the
  issuer prefers. In the case of a third-party CA or a standards
  certification agency, this can contain the manufacturer’s
  identity information.  The subject field’s DN encoding should
  include the “serialNumber” attribute with the device’s unique
  serial number.

  7.2.9 subjectAltName
  The non-critical DevID subjectAltName extension may supplement
  the subject field identity information as specified in RFC 5280
  by containing a hardwareModuleName as specified in RFC 4108.

> such an identity quite specific to this use case?

okay, but in which module? - it just needs to be a module imported
wherever ietf-x509-cert-to-name is used (ietf-netconf-server and 
ietf-restconf-server) but not any module defined in this draft.
So maybe yet another module is needed in this draft: ietf-more-
x509-cert-to-name-identities? - naming suggestions welcomed! ;)

> a '\' standard of some sort here.  Thoughts?

This is still open.

> Yes, my bad.  I think I meant 5.2.

Fixed.

>> >> Yes, but would you expect this to appear in the draft?  Typically,
>> >> the specific NACM rule syntax is left as an exercise to the reader...
>> >

Well, maybe not entirely correct.  It looks like NACM rules can 
constrain RPCs using the "rpc-name" rule type.  But, in this case,
an NACM group containing a list of users that matched exactly each 
device would have to be maintained, which isn't quite a nice as
using the $USER variable.

>> implementation of the RPC has to do the access control.

Right, but it wouldn't be "access control" so much as something akin
to a 404.  When establishing the RC connection, the server must first
auth the client's cert (at the TLS-level) that, in the case of an 
IDevID cert, most like maps to checking to see if it has a chain of
trust to the vendor's CA cert.  Then cert-maps is used to extract a
username; in the IDevID case, it is most likely some combo of the 
serialNumber and hardwareModuleName attributes.  This username is 
fed into the RPC handling logic which will do some internal lookup
and either find a match (and return data) or not (and return an error).
No need for NACM in this flow is there?

> somehow exist anyway, but with top-level RPCs it will be hidden.

A list of devices needs to exist in the database, and the NBI, but
not the SBI, right?

> Maybe implementations want to add additional objects to this list, for

Unsure.  The point of the SBI is that the device only receives a 
device-specific response, no other objects are ever included, right?
But maybe you mean some implementations will want to modify the format
of the device-specific response, which I agree is possible, but that
doesn't impact if we use an RPC versus an action.  Do you agree?

> provide this single leaf in a proprietary module, but maybe it is ok.

Okay, I'll add a ietf-zerotouch-device module.  It doesn't hurt.  
Vendors can use it or not.  If nothing else, at least they can
reference it for their native model.

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Oct 2017 12:28:39 +0200 (CEST)

> x509-cert-to-name-identities? - naming suggestions welcomed! ;)

Hmm.  Maybe a new document with just a new version of
ietf-x509-cert-to-name is most appropriate?  (I.e., not a complete
7407bis)  Or even update ietf-x509-cert-to-name in this document...

> > a '\' standard of some sort here.  Thoughts?

I don't have a good solution to this... It is often possible to format
the XML so that it is legal, but then it might look odd, e.g.:

                <tag
                >long line here......</tag>

> constrain RPCs using the "rpc-name" rule type.

Yes, but NACM cannot control access based on input parameters, which
is what would be needed in this case.

> But, in this case,

The bootstrap server has one RC interface.  If it used for NB or SB
access doesn't really matter.  I was thinking that the list of devices
might be useful also for a "NB" client.

> device-specific response, no other objects are ever included, right?

Sure; again I was thinking of objects for other clients.

> doesn't impact if we use an RPC versus an action.  Do you agree?

Right.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Oct 2017 18:33:11 +0000

Hi Martin et al.,

I'm preparing an update to the zerotouch draft.  Should have it out later this week.  More comments below (again trimming down it just open items).

K.

>> > I think that such an identitiy could be defined in this draft.  
>> > Isn't such an identity quite specific to this use case?
>> 

Defining it in this draft would be most expedient, but it goes
against my sensibilities.  The question that will be asked: "why
should the draft-ietf-[net|rest]conf-client-server have a normative
reference to the Zerotouch draft?"

That said, since this draft isn't itself using cert-to-name, we can
defer defining this to when we pick up the client/server model drafts
again - agreed?

> is what would be needed in this case.

Is that true?  Unless you're saying something subtle, my proposal doesn't
entail passing an input parameter for which device to return the data for,
but rather to use the authenticated RESTCONF username directly.  By design,
devices MUST get only their data via this SBI.   A separate NBI (YANG module)
needs to be designed (out of scope to this document) for how the system is
configured to have the data ready for the devices. Does using an RPC make
sense now, or do you still think an action is better?

> might be useful also for a "NB" client.

Yes, a list of devices is useful for the NB client, but I've always
maintained that it comes from another YANG module.  Essentially, a YANG
module for each type of user.  Yes, we could have an uber-module, but
I fear that the NB-part would become too application-specific and thus
not be easily standardized.  Or, as you implied before, an NB module 
could augment a device-list defined by the SB module, but 1) I don't
think an SB module should be designed with that in mind and 2) it 
only works if both the NB and SB modules are implemented on the same
RC server which, from our experience, for security reasons, is rarely
the case.  We use distinct RC servers that are partitioned by port or
machine, and at least half the times located in different data centers.

> Sure; again I was thinking of objects for other clients.

Understood. See above.

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Oct 2017 08:36:31 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Hi Martin et al.,
> 
> I'm preparing an update to the zerotouch draft.  Should have it out
> later this week.  More comments below (again trimming down it just
> open items).
> 
> K.
> 

Ok.  Unless it turns out it is not needed at all...

> sense now, or do you still think an action is better?

I meant that if the RPC takes the unique-id as a parameter, then you
cannot use NACM to ensure that a device cannot get data for some other
unique-id.

However, if the unique-id (or rather serial number etc) is implicit,
an rpc will work.  I'm ok with this approach.

Ok.

/martin