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

["t.petch" <[e-mail]>]

Kent

Changing the subject because my tack is slightly different.

I cannot reconcile this I-D with my (mis?)understanding of cryptography.

Stepping back, I see two types of keys, symmetric where one key is used
for encryption and decryption, and asymmetric, where there are two keys,
public and private, mathematically related but impossible to derive one
from the other, one used to encrypt, the other to decrypt.

I see this I-D as solely concerned with asymmetric keys.

Public and private key pairs must be generated together, after which the
private key must stay secret else you have no security.  Public keys by
contrast are public for all to know.  The challenge is authenticating
that the public key really is the public key of who you think it is.
Most public keys arrive by certificates which then allow you to follow a
chain thereof to a hopefully trustworthy trust anchor.  SSH, and some
other protocols, are different in distributing naked public keys and
relying on some other means of authenticating them (e.g. Trust on First
Use).

So when you say
"AFAICT, the system should be able to generate its host-key from the
private-key itself.  "
that is at odds with my understanding and would lead to an absence of
security.

When the I-D says,
"that might be used to hold onto private keys and
   certificates "
I struggle to see the point.  Indeed, the module contains public keys as
well as
"leaf public-key {
          config false;
          mandatory true;"
so you are really storing public/private key pairs (which may be
generated on the box).

The I-D also says
"Certificates associated with this private key."
which defeats me.  A certificate or chain thereof gives me a public key,
never a private one, and the means to authenticate the public key.

A public key may or may not have a certificate or chain thereof.  A TLS
client would likely have both but will rarely have a private key.  A
server of any protocol (except SSH and such like) will have a
public/private key pair and a certificate (and likely a chain thereof)
to send to any enquiring client along with the public key.  An SSH
server would have a public/private key pair but likely no certificates.

So, I cannot reconcile my understanding with the I-D.

Tom Petch


----- Original Message -----
From: "Juergen Schoenwaelder" <[e-mail]>
To: "Kent Watsen" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Friday, July 28, 2017 6:09 PM

> On Fri, Jul 28, 2017 at 05:00:06PM +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?
>
> ???
>
> > > 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 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).
>
> >
> > >> >> >> - 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.
>
> > >> >> >> - 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.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf