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

From: "t.petch" <[email-masked]>
Date: Tue, 1 Aug 2017 11:09:41 +0100

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" <[email-masked]>
To: "Kent Watsen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Aug 2017 18:24:25 +0000

Hi Tom,

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

Correct, though there was a time when we considered having a "password"
leaf, which would've been a form of a symmetric key.

> relying on some other means of authenticating them (e.g. Trust on First

Correct, though it's worth noting that SSH can also distribute X.509 certs
per RFC 6187.

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

My mistake, I was using the old name "private-key" before we changed
it to just "key", and what I really meant to say was that the system
should be able to convert /keystore/keys/key/private-key into a
representation suitable for software consumption (e.g., an openssh
host-key file).

> 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;"

That particular sentence, in the Abstract and Introduction, has been
rewritten based on Juergen's comments.  The abstract now says:

   This document defines a YANG module for a system-level mechanism,
   called a "keystore", containing security-sensitive data including
   private keys, pinned certificates, and pinned SSH host-keys.

The Introduction now says:

   This document defines a YANG [RFC7950] module for a system-level
   mechanism, herein called a "keystore".  The keystore provides a
   centralized location for security sensitive data, as described below.

   This module has the following characteristics:

   o  A configurable list of keys, each a public/private key pair.  If a
      key is used to sign a certificate signing request (CSR), which is
      then signed by a certificate authority (CA), then the resulting
      certificate may be configured as being associated with the key.
      Keys are expected to be configured using standard configuration
      mechanisms, however, to support hardware that generates keys, the
      key may also be created via an action called 'generate-private-
      key" action.  Keys may also be preinstalled (e.g., a key
      associated to an IDevID [Std-802.1AR-2009] certificate).

   o  An unordered list of pinned certificate sets...<snip/>
   o  An unordered list of pinned SSH host key sets...<snip/>
   o  An action to request the server to generate a new key...<snip/>
   o  An action to request the server to generate a CSR...<snip/>
   o  A notification...<snip/>

Does this help?  What "point" are you not seeing?

> The I-D also says "Certificates associated with this private key."

Again, this goes back the old name "private-key" before we changed
it to just "key".  I agree that it's wrong at face-value.  Above you
can see how this text was changed.  Now what it says makes more sense.

> A public key may or may not have a certificate or chain thereof.  

true.

> A TLS client would likely have both but will rarely have a private
> key.

True, assuming client certificate based authentication is "rare".

> A server of any protocol (except SSH and such like) will have a

All true

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

I think it was mostly due to the whole "private-key" to "key" rename
not having percolated through all the text yet.  Yes?

Kent

---

From: "t.petch" <[email-masked]>
Date: Wed, 2 Aug 2017 11:15:33 +0100

Kent

Mostly yes.

I think the one further change that I would like is to move away from
   o  An unordered list of pinned SSH host key sets...

I think that the scope should be a public key, not limited to SSH and
not restricted to what is referred to as  a host key.  Typically this
would be in a client enabling it to trust a server to establish a secure
channel which may then be used for further authentication.  I see this
as far more common than SSH.

And since the scope is asymmetric cryptography, I would state the
obvious in the

Abstract

This document defines a YANG module for a system-level mechanism,
called a "keystore", containing security-sensitive data including
private keys, pinned certificates, and public keys, such as pinned SSH
host-keys, for use in asymmetric cryptography.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Aug 2017 21:37:14 +0000

Hi Tom,

> as far more common than SSH.

Agreed.

>obvious in the Abstract

You're touching a point similar to what that Juergen raised.  I think
the solution here is to refactor the ietf-keystore module into a base
module, which doesn't mention anything protocol-specific, and augmenting
modules that are protocol specific.  If this were done, then the
abstract might read:

   This document defines a YANG module for a system-level mechanism,
   called a "keystore", containing security-sensitive data, such as
   asymmetric private keys.  This document defines additional modules
   that augment the base keystore module adding support for X.509
   and SSH.

What do you think?

Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Aug 2017 23:47:42 +0000

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

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

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

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 08:37:59 +0200

> layers that use it, but it's worth the discussion if it makes sense

Sound complex and unclear to me.
 
> 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).

> should be protected and, as such, the nacm:default-deny-all property

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

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 Aug 2017 13:08:03 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Subject: Re: [Netconf] last call review of
draft-ietf-netconf-keystore-02

Kent

I doubt that it will clarify.

My model is that are different ways of arriving at a public key but that
once you have, then the cryptography is the same, with a choice of
algorithms.

If you are a SSH client, then likely you have a stash of public host
keys associated with one or more SSH servers, and, apart from
algorithms, no more.

If you are a TLS client, then likely you are using X.509 and will have a
pre-configured trust anchor, in the shape of a public key or a
certificate (which may or may not be root).

If you are a SSH server, then likely you will have stash of
private/public key pairs, perhaps with constraints on their usage, and
the ability to generate further private/public key pairs.

If you are a TLS server, then you will have one or more X.509
certificates with your public keys, a chain of X.509 certificates back
to an anchor that the client will trust, the corresponding private keys
and perhaps the ability to generate a X.509 certificate with a
public/private key pair; this may or may not chain back to a trusted
root.

There are other TLS options but I think that their usage is limited, but
in the context of network management, one or more could be significant
although I don't have a specific example in mind ( I like PAKE but do
not see it in use).

So the only part in common is what you do once you have the public key,
which is not much.

Tom Petch.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Aug 2017 23:19:38 +0000

Hi Tom,

> once you have, then the cryptography is the same, with a choice of

A good first-approximation  :)

> certificate (which may or may not be root).

The clients also need their own private keys (which may be a password for
SSH) and associated public-key/certificate.

> public/private key pair; this may or may not chain back to a trusted

The servers also need information for how to authenticate the clients
(hashed password, pinned public-key or cert, pinned trust-anchor, etc.)
and how to map them to application-level usernames (e.g., via cert-maps)

> So the only part in common is what you do once you have the public key,

I'm unsure what change you're looking for with this comment.

Thanks,
Kent