Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed

From: Kent Watsen <[email-masked]>
Date: Mon, 1 Jun 2015 22:51:36 +0000

Hi Juergen,

On 3/19/15, 9:26 PM, "Kent Watsen" <[email-masked]> wrote:

>>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder"
>><[email-masked]> wrote:
>>
>>
>>* sec 3: Are certificates sometimes represented as strings and
>>  sometimes represented as binary?
>
>That's an oversight, they should all be binary.

I was just looking to make this change and realized that I misspoke
before.  The reason why one of the certificates is a string (not binary)
is because it's intended to be a poor-man's leafref.   Recall before we
had a read-only list of certs and a real leafref, but we subsequently took
out the read-only list and now the description says this:

    "An unordered list of certificates the TLS server can pick
     from when sending its Server Certificate message.  The value
     of the string is the unique identifier for a certificate
     configured on the system.  How valid values are discovered
     is outside the scope of this module, but they are envisioned
     to be the keys for a list of certificates provided
     by another YANG module";

Makes sense?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Jun 2015 07:43:35 +0200

>      to be the keys for a list of certificates provided

OK. What about the other then?

It would IMHO be nice to have a keychain YANG model so that we could
have a common way to deal with security credentials. I am struggling
with the need to refer to certificates and other credentials in the
LMAP YANG data model and I would love to be able to simply refer to a
keychain data model instead of creating another ad-hoc solution.

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Jun 2015 21:44:24 +0000

>keychain data model instead of creating another ad-hoc solution.

Are you referring to the leaf "credentials" in draft-ietf-lmap-yang?  This
leaf appears to be for client auth: username, password, rsa-key,
client-cert, and the like.   The server-model doesn't configure
client-auth; not even for call home, as the NETCONF/RESTCONF server is
always the SSH/TLS server (never the client).  Nonetheless, I appreciate
that client auth is a common use case for a keychains (password managers /
vaults)

However, as we've been discussing in this thread, the server-model does
need to configure which SSH host-keys or TLS server-certs the server
presents when establishing secure connections.  Ideally there is a global
store of host-keys and server-certificates that can be referenced on a
per-use basis (e.g., present cert-1 when accepting a connection, present
cert-2 when establishing a call home connection to app-2, etc.).

Another consideration is that keychains are often used to store trust
anchors.  Both lmap and server-model need trust anchors.  LMAP uses trust
anchors to authenticate the server-certificate of a server it is
connecting to, whereas server-model uses trust anchors to authenticate the
client-certificate of a client that is connecting to it.  Again, there
should be a global store of trust anchors that specific apps can
cherry-pick from.  For instance, use Verisign's trust anchor is OK when
connecting to 3rd-party web-server, but assert a specific trust anchor
when connecting to a well-known service.

Do we want to act on this now, or proceed with current drafts?

Sketching this out quickly, maybe something like this:

  module: ietf-keychain
     +--rw client-credentials
     |  +--rw client-credential* [name]
     |     +--rw name                      string
     |     +--rw type                      enumeration // password,
rsa-key, etc.
     |     +--rw value                     anydata // type-specific format
     +--rw private-keys
     |  +--rw private-key* [name]
     |     +--x generate-new               // returns public key
     |     +--rw name                      string
     |     +--rw type                      enumeration // elliptic, rsa,
dsa, etc. 
     |     +--rw value                     anydata // type-specific format

     +--rw host-keys
     |  +--rw host-key* [name]
     |     +--x generate-new               // input res a private key

     |     +--rw name                      string
     |     +--rw type                      enumeration // rsa, dss, x509,
etc.
     |     +--rw value                     anydata // type-specific format
 
     +--rw server-certificates

     |  +--rw server-certificate* [name]
     |     +--x generate-csr               // returns a cert signing
request
     |     +--rw name                      string
     |     +--rw certificate               binary

     +--rw trust-anchors
        +--rw trust-anchor* [name]
           +--rw name                       string
           +--rw certificate                binary

Then server-model would be something like

  import ietf-keychain {
    prefix kc;
  }
  ...
  container tls {
    container trusted-ca-certs {
      leaf trusted-ca-cert {
        type leafref {
          path "/kc:trust-anchors/kc:trust-anchor/kc:name";
        }
      }
    }
  }

What do you think?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Jun 2015 12:30:12 +0200

> Do we want to act on this now, or proceed with current drafts?

This is a tough question. I will take time to fully work out a
keychain module but once we have it, we surely safe effort in many
other places. Since using encryption is now a must, almost all
protocols will have configuration objects to setup the necessary
credentials and trust anchors. So in an ideal world, we would have a
generic infrastructure for this. But yes, creating such an
infrastructure delays other work, ranging from administrative
questions (which WG would host this effor (perhaps NETMOD), how we get
security folks involved (or whether they even prefer to host it) etc.)
and of course technical details. From an LMAP perspective, I would
love to simply refer to something else instead of trying to cook our
own solution. But then it is the LMAP WG to make that decision.

>           path "/kc:trust-anchors/kc:trust-anchor/kc:name";

Yep, this is a good sketch of something I would love to have for the
LMAP data mdoel.

/js