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

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Jul 31, 2017 at 06:30:21PM +0000, Kent Watsen wrote:
> 
> 
> >> >> >> >> - I am not sure I understand trusted-host-keys. On systems that have
> >> >> >> >>   multiple user accounts, you usually have a per account list of
> >> >> >> >>   trusted host keys in addition to a global system wide list. Perhaps
> >> >> >> >>   make it clear that this models the global known hosts list only?
> >> >> >> >> 
> >> >> >> >> <KENT> it's a list of lists, so there can be many different
> >> >> >> >> sets a host-keys defined, with each application/use pointing
> >> >> >> >> to its own entry.  The ietf-ssh-client module's grouping has
> >> >> >> >> a leafref to a specific entry.  FWIW, this grouping is
> >> >> >> >> used by ietf-netconf-client module.  At the moment, there
> >> >> >> >> no other uses of this grouping.  I think that you may be
> >> >> >> >> getting confused between the key the server presents (the
> >> >> >> >> host-key) versus the key user presents.
> >> >> >> >> .
> >> >> >> >
> >> >> >> > I though these are the authorized host keys? Yes, I am confused. If
> >> >> >> > these are user public keys, they should not be called host keys. But
> >> >> >> > yes, I am confused (but I started to read the other documents).
> >> >> >> 
> >> >> >> This leaf encodes an SSH public key (RFC4253, 6.6), same as used in 
> >> >> >> /ietf-system/system/user/authorized-key/key-data (and I have changed
> >> >> >> this leaf's type to match it in my local copy already), but the uses
> >> >> >> are different.  In ietf-system, the authorized-key is configured on
> >> >> >> a server in order to authenticate subsequent SSH-client connections.
> >> >> >> Here, we're taking about the key that that SSH-server presents to
> >> >> >> the client.  These are the host keys that OpenSSL often puts into the 
> >> >> >> ~/.ssh/known-hosts file.
> >> >> >
> >> >> > I understand what you are modeling is /etc/ssh/ssh_host_rsa_key.pub
> >> >> > and friends. Make sure it is described clearly. Or do you actually
> >> >> > mean the clients cache of authenticated keys that goes into an
> >> >> > account's known-hosts file? In this case, the keystore may be the
> >> >> > wrong place.
> >> >>  
> >> >> /keystore/trusted-host-keys/trusted-host-key is in fact like the
> >> >> known-hosts file.  That is, these are the host-keys that a client has
> >> >> "pinned" or "trusted".  The ietf-ssh-client has a leafref to one of
> >> >> these entries.  We could rename "trusted-host-key[s]" to 
> >> >> "pinned-host-key[s]" if that helps. Ditto for trusted-certificate[s])
> >> >> 
> >> >> By contrast, /keystore/keys/key/name is referenced by ietf-ssh-server
> >> >> to identify the host-key(s) the SSH server presents to SSH clients.
> >> >> This is analogous to /etc/ssh/ssh_host_rsa_key.pub and friends.  This
> >> >> node isn't called e.g. /keystore/keys/key/ssh-host-key because, AFAICT,
> >> >> the system should be able to generate its host-key from the private-key
> >> >> itself.  Thus, referencing the name is equivalent.  If there were a
> >> >> /keystore/keys/key/ssh-host-key node, it would be a gratuitous config
> >> >> false value that somehow encoded the host-key in a more SSH friendly
> >> >> format.  But, it may have a subtler value in that, I think that your
> >> >> confusion may be because it was NOT there and so, in its absence, 
> >> >> you may have thought that the "trusted-host-keys" must serve that 
> >> >> function.  Thoughts?
> >> >> 
> >> >> BTW, "host key" has a specific meaning, defined in RFC4251#4.1, not to
> >> >> be confused with authorized keys.
> >> >
> >> > I do not really follow you. I think I do understand what a host key
> >> > (pair) is and that it is different from a users key (pair).
> >> 
> >> Fine, but this is SSH architecture thing, not something specific to
> >> the draft - right?
> >
> > ???
>  
> I'm unsure about what you want here.  
> 
> A host-key is how the server authenticates itself to clients.  It is the thing that, when an SSH client first connects to a server and is presented the fingerprint, is placed into the client's ~/.ssh/known-hosts file.
> 
> Separately, user accounts can be configured to authorize a client based on a public-key (as opposed to a password).  This public-key is the thing that is commonly placed in ~/.ssh/authorized_keys, and is configurable via ietf-system/system/user/authorized-key/key-data.
> 

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.

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.

> >> > Yes, I did
> >> > not understand from reading the ID that the private SSH host key is to
> >> > be found in /keystore/keys/key/name (likely because of all the
> >> > certificate stuff around it that I have never seen used with SSH host
> >> > keys).
> >> 
> >> Okay, then do you like having a /keystore/keys/key/ssh-host-key node?
> >
> > I guess what I am looking for is a more radical split between X.509
> > stuff and SSH key stuff, the most radical split would be a module for
> > X.509 keys and certs and another module for SSH host keys. Or
> > alternatively, if there is really a strong reason to have all these
> > different keys in one list, then define the list such that
> > augmentations add X.509 stuff and SSH key stuff. I am not a fan of
> > lists where the usage of leafs for different purposes is not clear.
> 
> I just filed https://github.com/netconf-wg/keystore/issues/7 to track
> this.  My current thought is to break the module up into a main module
> and two augmenting modules.  This isn't quite what you want, but I'm
> hoping that the net-result is more readable, since nodes will be
> prefixed.  If nothing else, it can be a first step to a larger 
> break-up...
> 
> 
> >> > I guess I am not a big fan of bundling the way X.509 keys and certs
> >> > work together with how SSH keys work (because I am not used to this
> >> > and the systems I tend to use do not do this either). Anyway, if this
> >> > is the direction to go, I think this needs explanatory text somewhere.
> >> 
> >> So then perhaps factoring out the x.509 and ssh stuff out into augmenting
> >> modules? 
> >
> > I am not sure how much is left, other than a list with a key name leaf
> > and whether it is worth to have this common structure (and whether any
> > uniqueness constraints resulting from that are a benefit or not).
> 
> Right, the remaining module would be pretty skinny - just a list of keys
> and an action to generate a new private key.  I think the primary value
> is that everything is in one location, but maybe that doesn't matter here,
> since there is no human-in-the-loop, such as there is for desktop-oriented
> keystore mechanisms. Generally, the keystore is password-protected, but
> in this case there is no password, other than whatever the client used
> when connecting to the server.
> 
> 
> 
> 
> >> >> >> >> - Should the document title be aligned with other YANG module
> >> >> >> >>   definitions, so it is easier to spot it?
> >> >> >> >> 
> >> >> >> >> <KENT> I don't understand, what do you mean?
> >> >> >> >
> >> >> >> > We often use "[A] YANG Data Model for ....".
> >> >> >> >
> >> >> >> > https://en.wikipedia.org/wiki/YANG#Usage_in_Standards
> >> >> >> >
> >> >> >> > The current name does not say YANG (sometimes I search for YANG 
> >> >> >> > in the RFC index) and Keystore is also pretty broad given the
> >> >> >> > related work we have.
> >> >> >> 
> >> >> >> Gotcha, how about "YANG Data Model for Keystores"?
> >> >> >
> >> >> > Yes, except that 'keystores' leaves readers unclear about the scope. I
> >> >> > commented several times that the names of this module and the other
> >> >> > module for symmetric keys are unfortunate. Concerning the SSH keys, I
> >> >> > am still concerned that we would be better off to have a separate SSH
> >> >> > module that takes care about managing an SSH server's host keys and
> >> >> > then this module would be X509 certificate specific, i.e., a 'YANG
> >> >> > Data Model for Managing X.509 Keys and Certificates' would be a clear
> >> >> > and well defined scope.
> >> >> 
> >> >> From a refactoring perspective, we could have a base module and then
> >> >> two augmenting modules, one for SSH and the other for X.509.  I would
> >> >> think to define all three modules in the same draft, but that wouldn't
> >> >> help your draft-name issue.  We could put each module into own draft
> >> >> (e.g. +2 drafts), but is it worth it for renaming sake?  Maybe an even
> >> >> longer title?  "YANG Data Model for Managing Asymmetric Private Keys,
> >> >> X.509 Certificates, and SSH Host Keys'?  Naming aside, what do you 
> >> >> think about the module-factoring idea?
> >> >
> >> > Perhaps it is simpler to have one data model to manage X.509 keys and
> >> > certs and another data model to manage SSH keys. I do not know how
> >> > much commonality there is. At the end, I also do not mind if
> >> > everything is lumped together as long as it is clear how to implement
> >> > things and key formats etc match with what implementations typically
> >> > do.
> >> 
> >> Two modules, something like ietf-ssh-keystore and ietf-x509-keystore?
> >> Of course, there would overlap between them (e.g., both modules would
> >> have the /keys/key hierarchy, the ietf-ssh-client/server modules might
> >> need to import both keystores, since SSH can use X.509 certs too (per
> >> RFC6187).  I don't know, this doesn't seem right.  For instance, what
> >> is a server to do if it generates a private key that has not yet been
> >> associated with an X.509 cert or SSH host key, is the private key to
> >> appear in both keystores?
> >
> > Is this how systems work? My command line tools either create X.509
> > keys or SSH keys.
> 
> 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?

/js

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