Re: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-keystore-02

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Aug 02, 2017 at 11:47:42PM +0000, Kent Watsen wrote:
> 
> Hi Juergen,
> 
> > <snip/>
> > Yes, the host-key resides on the server, the public part of the host
> > key may be stored on a client in a known-hosts file so that client can
> > check whether it talks to the right server. So far so good.
> >
> > It seems /keystore/trusted-host-keys/trusted-host-key represents
> > /etc/ssh/ssh_known_hosts (i.e. a _global_ known hosts list) and there
> > is no way to learn the public known host key from a server via the
> > YANG module. Can I request creation of a hew host key? There is
> > generate-private-key but that seems to be more tied to X.509 stuff.
> 
> The 'generate-private-key' action is no way meant to be just for X.509
> stuff.  But I acknowledge that there might be a semantic-gap here.
> For instance, if one wants to ask an SSH server to generate a new
> host-key, one expects an API called something like 'generate-host-key'
> (inside an SSH namespace, or as an action to the server instance),
> rather than first generating the 'key' and then separately saying that
> it's the host-key.  I think that this could be caulked up to saying
> that there is a base API layer and then, separately, higher level
> layers that use it, but it's worth the discussion if it makes sense
> at all...

Sound complex and unclear to me.
 
> > Note that this does not model ~/.ssh/known-hosts since the list is not
> > on a per user account base. It would actually be the equivalence of a
> > global /etc/ssh/ssh_known_hosts file.
> 
> Not exactly.  As it is undetermined who, or which models, point to the
> keystore host-key lists.  In some data models, it might be global and,
> in others, user specific.

OK, but very different from how implementations work (they tend to
store account specific known host keys in account specific places).

> >> <snip/>
> >> No, your system most likely does not use a keystore mechanism.  For
> >> instance, OpenSSL's `ssh-keygen` utility just writes to a local file.
> >> We're doing something a little different here, which is a cause for
> >> careful review (thanks again).  Taking a step back, one of the drivers
> >> for this keystore mechanism is to centralize the /trusted-host-keys
> >> and /trusted-certificates, as these lists are referenced from many
> >> locations.  Less important to centralize are the private keys, as
> >> the keys (always?) have a single use.  The only reason for centralizing
> >> the private keys is to give keys created via the generate-private-key
> >> action a place to be listed before they are used for some purpose...
> >
> > The question is whether there is value to centralize beyond the
> > differnet key systems. Is there really added value to try to treat SSH
> > keys and X.509 in the same list infrastructure or are they at the end
> > just different things? What about other keys, i.e., for signing DNS
> > zones or RPKI keys? Is it useful to try to put all of these keys that
> > serve different purposes into a common structure? The open source
> > people maintaining software packages seem to keep things separate. Is
> > Junos having such a centralized asymmetric keystore? How about IOS XR?
> > Others? If not, why would a standard do this?
> 
> JUNOS is not having a centralized keystore.  I can't speak for IOS or
> others, but I guess not.  This model is suggesting a *conceptual*
> keystore.   As the keystore draft says:
> 
>    It is not required that a system has an operating system level
>    keystore utility to implement this module.
> 
> But to your higher-lever question, is there value to treating such
> various keys similarly, all I can say is that all such private keys
> should be protected and, as such, the nacm:default-deny-all property
> given here is apropos.
>

It is easy to specify nacm:default-deny-all on multiple branches. I am
concerned about trying to create a unified asymmetric keystore that
nobody really has experience with and that maintenance of it may
become a real problem given that this would involve collaboration and
coordination between multiple WGs in the IETF (ideally this work
should be done by security WGs).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>