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

[Kent Watsen <[e-mail]>]

>> >> >> >> - 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, 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...




>> >> >> >> - Since the certs of a key do not contain a signature, where are signed
>> >> >> >>   certificates stored or are they outside the scope of the model?
>> >> >> >> 
>> >> >> >> <KENT> I'm confused, certificates are signed structures already...
>> >> >> >
>> >> >> > Well, the description of certificates/certificate/value says:
>> >> >> >
>> >> >> >   An unsigned PKCS #7 SignedData structure, as specified
>> >> >> >   by Section 9.1 in RFC 2315, containing just certificates
>> >> >> >   (no content, signatures, or CRLs), encoded using ASN.1
>> >> >> >   distinguished encoding rules (DER), as specified in
>> >> >> >   ITU-T X.690.
>> >> >> >
>> >> >> > Yes, I am confused how this works.
>> >> >>  
>> >> >> Okay, now I understand your confusion.  I believe the text is 
>> >> >> accurate.  Think of the PKCS#7 structure being a little like a 
>> >> >> TAR file that contains a directory structure like this:
>> >> >> 
>> >> >>  pkcs7:
>> >> >>   /signed-info
>> >> >>   /signature   - this sig is only over 'signed-info' ...
>> >> >>   /extra-certificates
>> >> >>   /extra-revocation-objects
>> >> >> 
>> >> >> So, in this case, we're using a degenerate form of the pkcs7
>> >> >> structure that has no content (signed-info), signature, or CRLs 
>> >> >> (revocation-objects), it only contains the certificates. Perhaps
>> >> >> my use of the word "unsigned" isn't clear enough?
>> >> >
>> >> > So why pkcs7, is this what implementations use? The certificates
>> >> 
>> >> Why pkcs7 is because each certificate may have an associated chain
>> >> of certificates leading to a trust-anchor CA certificate.  For instance,
>> >> a vendor might have a CA called "foo-root" that signs an intermediate
>> >> CA called "foo-intermediate" that signs the "foo-entity" certificates.
>> >> So, a given foo-entity certificate (a single X.509 structure) is
>> >> commonly presented along with its chain of CA certs (more X.509 
>> >> structures), in this case, the "foo-intermediate" and "foo-root" CA
>> >> certs.  The pkcs7 structure is commonly used for this purpose in the
>> >> PKI world.  Yes, it could be just a TAR file having a flat list of
>> >> certs, but then we'd have to define that structure, whereas its 
>> >> already defined in pkcs7.
>> >> 
>> >> > I find in /etc/ssl/certs on my Debian system seem to be in PEM format.
>> >> 
>> >> PEM and DER are interchangeable formats.  PEM is essentially the base64
>> >> encoding of the DER surrounded by the "===== BEGIN/END CERTIFICATE
>> >> =====" header/footer.
>> >> 
>> >
>> > DER encoded certificate or pkcs7? I thought PEM is just a base64
>> > encoded version of the DER encoded certificate, no pkcs7 involved.
>> 
>> Both PKCS7 and X.509 or ASN.1-encoded structures, and all ASN.1 structures
>> can be encoded using PEM, DER, or even BER.   Your debian system's "certs"
>> directory undoubtedly only contains root certs, hence there is no cert-chain
>> to staple to them, and hence a single X.509 structure (either PEM or a DER)
>> is perfect.  As soon as you step into needing more than one cert, then
>> either PKCS7 or PKCS12 (both of which could be PEM or DER encoded), or a
>> very special multi-part PEM (one that contains more than one of the "====="
>> BEGIN/END blocks) could be used.  BTW, all this was discussed a while back
>> related to https://github.com/netconf-wg/keystore/issues/1.  What's written
>> in the GitHub issue tracker should be ignored, search instead the list-archive
>> on issue #1... 
>>
>
> What matters is that the I-D is clear and captures the important
> reasons etc. You can't expect implementors to read github issues
> or mailing list archives. Sorry for my ignorance.

Okay, I rewrote the description. Actually. I just removed the word
"unsigned", as the rest seemed okay:

     A PKCS #7 SignedData structure, as specified by 
     Section 9.1 in RFC 2315, containing just certificates
     (no content, signatures, or CRLs), encoded using ASN.1
     distinguished encoding rules (DER), as specified in
     ITU-T X.690.


Kent