Subject: [netconf] updates to client/server drafts

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Jun 2019 22:28:09 +0000

The updates can be broadly described as thus:

1) in crypto-types, replaced the 'action' statements with 'crypt-hash' like equivalents.  If folks don't like the "verbs", then we can simply remove them, having no solution for asking the device to generate a key or install a hidden key.

2) in trust-anchors, renamed "trust-anchors" to "truststore"

3) in both truststore and keystore, moved everything under a 'grouping' statement which is then used by a 'container'.  This is almost an editorial update.

4) in tcp-client-server, added support for external NAT (we can remove is preferred)

5) in restconf-client-server, added an 'http-listen' (not https-listen) choice, to support case when server is behind a TLS-terminator.  This draft isn't adopted yet, but this is driven by my needing to support this use case in a project I'm working on.  (ps: yes, I'm implementing the entire ietf-restconf-server model).

6) also in restconf-client-server, refactored the server module to be more like other 'server' models.  If folks like it, I will also apply the same also to the client model, as well as to both the netconf client/server models.  Now the 'restconf-server-grouping' is just the RC-specific bits (i.e., the "demux" container minus the container), 'restconf-server-[listen|callhome]-stack-grouping' is the protocol stack for a single connection, and 'restconf-server-app-grouping' is effectively what was before (both listen+callhome for many inbound/outbound endpoints).

There are other smaller changes, please see the change logs and diffs for details.

PS: the chairs are hoping to enter crypto-types, truststore, and keystore in Last Call in a couple weeks.   There may be another update to crypto-types draft before then pending on my Huawei co-authors.   The remainder of the drafts need more work before ready for Last Call.

Thanks,
Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Jun 2019 22:30:50 +0000

I misspoke, the restconf-client-server draft is adopted (I was thinking about the http-client-server draft).

K.

> On Jun 7, 2019, at 6:28 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Jun 2019 19:40:24 +0200

> 1) in crypto-types, replaced the 'action' statements with 'crypt-hash' like equivalents.  If folks don't like the "verbs", then we can simply remove them, having no solution for asking the device t…

I am not sure this approach. This just hides the discussion in a
special purpose construction:

               Without the optional '-and-hidden' postfix, the generated
               key pair is stored in the configuration data store as if
               the values had been configured by the client.

A more general note: I assume that humans configuring systems are
mostly familiar with common file formats for X.509 certificates like
.pem files or similar. It seems these formats can't be used with the
YANG module and that tools are needed to extract the pieces of data
and to ship them to the server. Perhaps usability would be higher if
the module would support upload/download of X.509 related material in
commonly used formats.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Jun 2019 20:53:57 +0000

Hi Juergen,

Thanks for broaching the topic, I'm hoping we can suss out such things before the drafts enter Last Call in 2-3 weeks.

>               the values had been configured by the client.

True, this special purpose construction sidesteps us needing to resolve the larger "can actions effect configuration" discussion.  But perhaps that is okay given that the need to have actions effecting configuration is exceedingly rare?   It's clear that you're not thrilled by this approach, but it's unclear if the reason you're not thrilled is because of the approach or because it's sidestepping the larger discussion.    Also, what do you propose we do about it?  Choices:

a) nix the "verbs", leaving the solution for asking the device to generate a key and install a hidden key to a future update.
b) resurrect the 'action' based discussion.
c) cautiously move forward with the "verbs" approach.
d) something else?

> the module would support upload/download of X.509 related material in

This comment seems to apply to the entire client/server suite of drafts.  I believe that your statement regards the somewhat heavy use of CMS structures for conveyed certificate chains, rather than the non-standard though nearly ubiquitous concatenation of PEM-encoded certificates.

I believe that bi-directional `openssl` based one-liners exist for converting between CMS and concatenated-PEMs.  Would it help if the crypto-types draft included an Appendix section to supply the `openssl` commands for just the 'trust-anchor-cert-cms' and 'end-entity-cert-cms' typedefs?  [FWIW, constructing said CMS structures in Python is trivial.]

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jun 2019 08:11:55 +0200

> c) cautiously move forward with the "verbs" approach.

I am strictly against hiding actions by encoding 'verbs' in an ad-hoc
data format. I rather not support creation of keys on the device. That
said, I still think it is desirable to find a solution to support this
that is acceptable to the WG. But replacing an action with 'verbs' and
side effects in config data is for me just obscuring the issue not
solving it.

> This comment seems to apply to the entire client/server suite of drafts.  I believe that your statement regards the somewhat heavy use of CMS structures for conveyed certificate chains, rather than…

Right.
 
> I believe that bi-directional `openssl` based one-liners exist for converting between CMS and concatenated-PEMs.  Would it help if the crypto-types draft included an Appendix section to supply the…

Yes, there are a number of these -cms types and I suspect that not all
people will not know how to generate the proper CMS / DER-encoded
binary (and then base64 encoded XML/JSON) values that are required by
the YANG model. I am much more used to PEM formats but perhaps this is
just my ignorance.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Jun 2019 13:00:24 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> data format. I rather not support creation of keys on the device.

Remember we had this cases:

1.  upload of keys
2a. generation of keys on the box that will go into hardware protected
    storage (and never be accessible)
2b. generation of keys on the box that will be stored on disk
    (and never be accessible over the mgmt interface)
3.  generation of keys on the box that become (protected) configuration

I think the previous version of the draft (with YANG actions) handles
1 and 2 (a and b with trivial updates).

It is only (3) that we don't have a solution for that everybody
accepts.

So perhaps we should solve 1 and 2a and 2b, and publish that, and
leave 3 for the future?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jun 2019 13:10:23 +0200

> So perhaps we should solve 1 and 2a and 2b, and publish that, and

This may be a way to move forward. In 2a and 2b, will there be a way
to remove a generated key via the mgmt interface or do I have to take
a bigger hammer to accomplish this?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Jun 2019 16:17:24 +0200 (CEST)

> a bigger hammer to accomplish this?

If we can agree on this way forward, I think we can solve the life
cycle issue.  One action to create the key and one to delete it seems
reasonable.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Jun 2019 14:58:30 +0000

>> 3.  generation of keys on the box that become (protected) configuration

This list is missing cases #1 and #3 described here: https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc>.  Also, we currently make no distinction between (2a) and (2b) - hidden is hidden, however it's implemented.

> a bigger hammer to accomplish this?

I object to reverting to the approach that doesn't have the key's 3-tuple (algorithm, public key, private key) marked as mandatory true, our doing that before was unhelpful.   I was hoping that the "verbs" approach could leap over the impasse but, if Juergen is strictly against it, then we should go back to the approach described here: https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY>, for which a draft was never published.

In the previous link, search for "Now let's discuss what this action does" and note the two options: (1) is more user-friendly, but one that Martin appears to be strictly against, and so perhaps (2) is all we can agree on, and yes, there would need to be a third (not mentioned) action to delete the key from <operational> (presumably after having deleted the same from <running>).   Yes, it is less friendly, if you want more friendly, then let's do (1).  I'll update the draft shortly based on the less-friendly approach (2).

That said, I'm also okay with giving up (for now) trying to enable a client request the server to generate a key (hidden or not) or request the server to install a hidden key [note: these are #2 and #3 in my first link above].  I would support this less complete solution because it still supports basic configuration (#0) and manufacturer-generated keys for, e.g., IDevID certificates (#1), and thus a passable go-to-market solution.  If folks don't like the update per the previous paragraph, then this looks like a good fallback.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Jun 2019 17:43:26 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> This list is missing cases #1 and #3 described here:
> https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc
> <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc>.

#1 (pre-existing key in hw) is orthogonal to the pain points we have
here; it should be possible to handle this case.

#3 (upload of hidden key) should also be straight forward with an
action.

> Also, we currently make no distinction between (2a) and (2b) - hidden
> is hidden, however it's implemented.

I know, but the discussion seems to imply that this would be useful and
it seems trivial to support.

> I object to reverting to the approach that doesn't have the key's
> 3-tuple (algorithm, public key, private key) marked as mandatory true,
> our doing that before was unhelpful.

I need to go back and re-read (again, I just read all threads on this
issue) some mails to understand what this means.

> I was hoping that the "verbs"
> approach could leap over the impasse but, if Juergen is strictly
> against it, then we should go back to the approach described here:
> https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY
> <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY>,
> for which a draft was never published.
> 
> In the previous link, search for "Now let's discuss what this action
> does" and note the two options: (1) is more user-friendly, but one
> that Martin appears to be strictly against

Yes, and Andy and Rob (at least).  And I do not agree that it is user
friendly at all!

> and so perhaps (2) is all
> we can agree on, and yes, there would need to be a third (not
> mentioned) action to delete the key from <operational> (presumably
> after having deleted the same from <running>).  Yes, it is less
> friendly, if you want more friendly, then let's do (1).  I'll update
> the draft shortly based on the less-friendly approach (2).

I don't think (2) is the right solution either.  I think the previous
version of the draft was very close to a workable solution.

> That said, I'm also okay with giving up (for now) trying to enable a
> client request the server to generate a key (hidden or not) or request
> the server to install a hidden key [note: these are #2 and #3 in my
> first link above].

I don't it is necessary to give up this.

IMO the only problematic use case is "let the device generate a key
that then becomes part of the config".  If we avoid that I think we
can handle the other cases.

> I would support this less complete solution
> because it still supports basic configuration (#0) and
> manufacturer-generated keys for, e.g., IDevID certificates (#1), and
> thus a passable go-to-market solution.  If folks don't like the update
> per the previous paragraph, then this looks like a good fallback.

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 14 Jun 2019 17:30:08 +0000

Hi Martin, Kent,

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Martin Bjorklund
> Sent: 13 June 2019 16:43
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netconf] updates to client/server drafts
> 
> > >>> I am strictly against hiding actions by encoding 'verbs' in an
> > >>> ad-hoc data format. I rather not support creation of keys on the
> device.
> > >>
> > >>    storage (and never be accessible) 2b. generation of keys on the
> > >> box that will be stored on disk
> > >>    (and never be accessible over the mgmt interface) 3.  generation
> > >> of keys on the box that become (protected) configuration
> >
> <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc
> >.
> 
> #1 (pre-existing key in hw) is orthogonal to the pain points we have here;
> it should be possible to handle this case.
> 
> #3 (upload of hidden key) should also be straight forward with an action.
> 
> 
> I know, but the discussion seems to imply that this would be useful and it
> seems trivial to support.
> 
> 
> > > to remove a generated key via the mgmt interface or do I have to
> > > take a bigger hammer to accomplish this?
> >
> > <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQM
> > JusY>, for which a draft was never published.
> >

I don't think that I'm necessarily against having an action (or RPC) that generates a pair of keys and writes them to configuration as a special type of configuration update.  But I would very much regard this as a special case that is designed as a combined action/RPC solely to make life easier for clients rather than the defacto approach.  I.e., I would like there to be an equivalent mechanism that works, is just as secure and complete, using regular NETCONF <edit-config> config operations and normal semantics.  Then the question becomes: If we can do this using regular NETCONF semantics, do we still need a separate "easy to use" action/RPC as well?

> IMO the only problematic use case is "let the device generate a key that
> then becomes part of the config".  If we avoid that I think we can handle
> the other cases.

I think that Juergen's idea of "store the name of the key in the <running> configuration, but not necessarily the value" is along the right lines.
 - If the client is willing to write the key into the configuration, perhaps obfuscated, or encrypted, then that is fine.
 - If the client wants the server to allocate the keys that also works.

Taking Kent's tree diagram from the 3rd of May, perhaps this could be modified from:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm?                             <--- optional?
              +--rw public-key?                            <--- optional?
              +--rw private-key?           union           <--- optional?   (note union)
              +---x generate-hidden-key
              +---x install-hidden-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

to something like this:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw type!                                  <-- New mandatory field
              +--rw algorithm?                             <--- optional
              +--rw public-key?                            <--- optional
              +--rw private-key?           union           <--- optional
              +---x regenerate-hidden-key
              +---x install-hidden-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

Where the new "type" enum field could have 4 options such as:
 - plain-text <= configured algo, public/private keys in raw format (not secure, transferable)
 - obscured   <= as above, but obscured with a known reversible mechanism (not secure, transferable)
 - encrypted  <= as above, but encrypted using server's public key (secure, not transferable)
 - server-allocated <= only name and optionally algorithm in running config, the server allocates the key when applying the configuration, public key is available in operational, private key is never reported.  Key pair is persisted outside of YANG configuration.
 
YANG "must" statements could be added to "algorithm", "public-key" and "private-key", to enforce that these are always provided if type is (plain-text, obscured, encrypted).

The "regenerate-hidden-key" action would allow a server-allocated hidden key to be regenerated if required.  If user configuration caused the key to be created in the first place, then the key would also be deleted if the key list entry is deleted from configuration.

A server could also automatically create its own key, without any user intervention.  The server chooses the key name, and the key would be of type "server-allocated" but it would only exist in operational (origin=system).  If the key needs to be referenced in configuration then the client would need to configure (asymmetric-key, name=<server-assigned-key-name>, type=server-allocated) into the configuration.  Subsequently removing the configuration wouldn't delete the key (because it is system created, and always exists), but regenerate-hidden-key should work to force the key to be regenerated if required.  The server persists the key outside of YANG configuration.

The "install-hidden-key" action would allow a client to replace any server-allocated hidden key.

Finally, if we are concerned about ease of use, then I would OK with a RPC being defined that performs an edit-config request to just add a named asymmetric-key of type server-allocated.  The RPC could also return the public key that has been generated by the server.  Note that this RPC isn't required, everything that can be done with the RPC can still be achieved through editing the configuration using edit-config, and reading the public key back with get-data, its only purpose to simplify a use case for clients, and perhaps to allow it to have different NACM permissions.

Would a scheme like this work?  Or am I [still] missing something?

Thanks,
Rob

> 
> 
> > I would support this less complete solution because it still supports
> > basic configuration (#0) and manufacturer-generated keys for, e.g.,
> > IDevID certificates (#1), and thus a passable go-to-market solution.
> > If folks don't like the update per the previous paragraph, then this
> > looks like a good fallback.
> 
> 
> /martin
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Jun 2019 08:46:01 -0700

On Fri, Jun 14, 2019 at 10:30 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> > <
> here;
> I don't think that I'm necessarily against having an action (or RPC) that
> generates a pair of keys and writes them to configuration as a special type
> of configuration update.  But I would very much regard this as a special
> case that is designed as a combined action/RPC solely to make life easier
> for clients rather than the defacto approach.  I.e., I would like there to
> be an equivalent mechanism that works, is just as secure and complete,
> using regular NETCONF <edit-config> config operations and normal
> semantics.  Then the question becomes: If we can do this using regular
> NETCONF semantics, do we still need a separate "easy to use" action/RPC as
> well?
>
>
>

IMO it is fair to ask how many servers support actions that change
configuration today?
If several vendors say "this is great! we use it all the time! no problems
at all!" then
it is probably appropriate for standardization. Otherwise, not so much.
(I don't think any vendors use this design pattern now)

> I think that Juergen's idea of "store the name of the key in the <running>
> configuration, but not necessarily the value" is along the right lines.
>  - If the client is willing to write the key into the configuration,
> perhaps obfuscated, or encrypted, then that is fine.
>  - server-allocated <= only name and optionally algorithm in running
> config, the server allocates the key when applying the configuration,
> public key is available in operational, private key is never reported.  Key
> pair is persisted outside of YANG configuration.
>
> YANG "must" statements could be added to "algorithm", "public-key" and
> "private-key", to enforce that these are always provided if type is
> (plain-text, obscured, encrypted).
>
> The "regenerate-hidden-key" action would allow a server-allocated hidden
> key to be regenerated if required.  If user configuration caused the key to
> be created in the first place, then the key would also be deleted if the
> key list entry is deleted from configuration.
>
> A server could also automatically create its own key, without any user
> intervention.  The server chooses the key name, and the key would be of
> type "server-allocated" but it would only exist in operational
> (origin=system).  If the key needs to be referenced in configuration then
> the client would need to configure (asymmetric-key,
> name=<server-assigned-key-name>, type=server-allocated) into the
> configuration.  Subsequently removing the configuration wouldn't delete the
> key (because it is system created, and always exists), but
> regenerate-hidden-key should work to force the key to be regenerated if
> required.  The server persists the key outside of YANG configuration.
>
> Finally, if we are concerned about ease of use, then I would OK with a RPC
> being defined that performs an edit-config request to just add a named
> asymmetric-key of type server-allocated.  The RPC could also return the
> public key that has been generated by the server.  Note that this RPC isn't
> required, everything that can be done with the RPC can still be achieved
> through editing the configuration using edit-config, and reading the public
> key back with get-data, its only purpose to simplify a use case for
> clients, and perhaps to allow it to have different NACM permissions.
>

I also like Juergen's approach.

Thanks,
> Rob

Andy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 17 Jun 2019 13:01:02 +0000

Hi Andy,

Generally, we try and avoid actions modifying configuration, but in some cases this might be allowed (e.g. renumbering ACL entries, or disabling some hardware moves active configuration to pre-configuration).

However, the circumstances where an action might be useful for this scenario is potentially a bit different from regular network device configuration.

E.g. some programmatic mechanism to easily add a key to a client device, the scenario described by Tom in:
https://mailarchive.ietf.org/arch/msg/netconf/7zOypLmuSnMUIYfsc_wTl2nS-84

I don’t know the exact details of what is required here, but having an action (or RPC), dependent on a feature, might be reasonable for this scenario.  I would see this purely as an alternative mechanism to achieving the same end goal as regular configuration, potentially to allow different NACM rules on the action/RPC.

Thanks,
Rob

From: Andy Bierman <[email-masked]>
Sent: 15 June 2019 16:46
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [netconf] updates to client/server drafts

On Fri, Jun 14, 2019 at 10:30 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin, Kent,

> From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Bjorklund
> Sent: 13 June 2019 16:43
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
> >

IMO it is fair to ask how many servers support actions that change configuration today?
If several vendors say "this is great! we use it all the time! no problems at all!" then
it is probably appropriate for standardization. Otherwise, not so much.
(I don't think any vendors use this design pattern now)

[RW]

     +--rw keystore
        +--rw asymmetric-keys

to something like this:

     +--rw keystore
        +--rw asymmetric-keys

Thanks,
Rob

Andy

> [email-masked]<mailto:[email-masked]>

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Jun 2019 09:21:38 -0700

On Mon, Jun 17, 2019 at 6:01 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> Hi Andy,
>
>
>
> Generally, we try and avoid actions modifying configuration, but in some
> cases this might be allowed (e.g. renumbering ACL entries, or disabling
> some hardware moves active configuration to pre-configuration).
>
>
>
> However, the circumstances where an action might be useful for this
> scenario is potentially a bit different from regular network device
> configuration.
>
>
>
> I don’t know the exact details of what is required here, but having an
> action (or RPC), dependent on a feature, might be reasonable for this
> scenario.  I would see this purely as an alternative mechanism to achieving
> the same end goal as regular configuration, potentially to allow different
> NACM rules on the action/RPC.
>
>
>

IMO it is a bad idea to create configuration as a side effect of an action.
Period.
What if the config is locked? Access control allows the user to invoke
action but not
change that specific config? Do the netconf-config-change and yang-push
notifications
get generated? Will the user or the system be identified in the audit logs?
(Too much implementation complexity as well, but the IETF does not care
about that.)

It seems much cleaner for the action to return a label for the keys/cert
(e.g., any sensitive data)
and then the client must configure its use somehow using normal editing
operations.

Thanks,

Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 15 June 2019 16:46
> *To:* Rob Wilton (rwilton) <[email-masked]>
> *Cc:* Martin Bjorklund <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [netconf] updates to client/server drafts
>
>
>
>
>
>
>
> *[RW] *