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

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

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


----- Original Message -----
From: "Kent Watsen" <[e-mail]>
Sent: Tuesday, August 01, 2017 7:24 PM

> Hi Tom,
>
> > 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.
>
> Correct, though there was a time when we considered having a
"password"
> leaf, which would've been a form of a symmetric key.
>
>
> > 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).
>
> 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;"
> > so you are really storing public/private key pairs (which may be
> > generated on the box).
>
> 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."
> > 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.
>
> 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
> > 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.
>
> 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?
>
>
> > Tom Petch
>
> Kent
>
>
>
>
>