Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Jun 2015 22:40:54 +0000

[Re-opening issue #49]

The solution verified below was to unify the trust-ca-certs and trusted-client-certs containers across NETCONF/SSH and NETCONF/TLS, but does nothing to unify RESTCONF/TLS.  For a server that implements both NETCONF and RESTCONF, wouldn't the same set of trusted ca/client certs be used for both?

Since both the netconf-server and restconf-server models are in the same draft, it would be relatively easy to define a 3rd YANG model in this draft (no need for a new draft).  But the recent email thread with Juergen regarding keychains highlights an opportunity to do something more applicable to other drafts (e.g., LMAP), which would fix both this issue (how to validate client-certs) as well as the issue of knowing which SSH host-keys or TLS server-certs to advertise.

Options:
   1. Do nothing   (keep all separate)   [issue --> DEAD]
   2. Only unify netconf/ssh and netconf/tls  (current plan)
   3. Unify across netconf/ssh, netconf/tls, and restconf/tls
        A. do this using a 3rd YANG module in this draft
        B. do this by using "poor-man" leafrefs
               - i.e. a string that points to a key in some TBD module
   4. Work on a keychain solution of some sort
            - this would delay server-model draft longer...

I'm on the fence, but my preferences in order are 4, 2, 1, 3B, 3A

Kent

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 18, 2015 at 6:15 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?

The solution described below is now considered verified.

Thanks,
Kent

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 29, 2015 at 7:06 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?

This issue (see subject line and/or link below) was discussed during the Dallas meeting with an agreement to combine the configuration for trusted CA-certs and client-certs into one container for both SSH and TLS.  The new container would use the following YANG 1.1 if-feature statement (assuming the WG adopts that resolution):

    if-feature "(ssh-x509-certs or tls)";

This issue is hence moved to the VERIFY state.  The issue will move to the EDIT state if no objection is raised by April 6th.

Reference: https://github.com/netconf-wg/server-model/issues/49

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Sun, 7 Jun 2015 18:32:43 +0000

This issue is the only issue currently blocking the server-model draft.

For convenience, the email exchange with Juergen mentioned before is here:
 https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html.

As a thought exercise, assume that it is inevitable that a keychain model
will exist some day, and that a future revision of this draft wants to use
It (are these valid assumptions?).  If so, how would this draft be updated
to make use of the new keychain model?

OPTION 1:  use union to mix-in leafref   // allowed in YANG 1.1

  Examples:

    import ietf-keychain {    // some future keychain module
        prefix kc;
    }
    container trusted-ca-certs {
      leaf-list trusted-ca-cert {
        type union {
          type string;       // from original draft
          type leafref {     // added in revision
            path "/kc:server-certificates/kc:server-certificate/kc:name";
          }
        }
      }
    }
    container server-certificates {
      leaf-list server-certificate {
        type union {
          type binary;      // from original draft
          type leafref {    // added in revision
            path "/kc:trust-anchors/kc:trust-anchor/kc:name";
          }
        }
      }
    }

  PROs: backwards-compatible, no feature statements
  CONs: 1) for trusted-ca-cert, how would a server differentiate
           the "string" and "leafref" types?  Does it matter?
        2) for server-certificate, would server implement "binary"
           as a pass-thru to the underlying keychain?  If so, then
           would server maintain metadata to track how the leaf
           was configured so that it can present it the same way
           when returning config to clients?  Would we use an
           attribute so that if the client sends the config back
           to the server, the server's metadata wouldn't change?

OPTION 2: use if-feature statement to mix-in leafref

    import ietf-keychain {    // some future keychain module
        prefix kc;
    }
    container trusted-ca-certs {
      leaf-list trusted-ca-cert {    // from original draft
        type string;
      }
      leaf-list trusted-ca-cert-ref {    // added in revision
        if-feature keychain;
        type leafref {
          path "/kc:server-certificates/kc:server-certificate/kc:name";
        }
      }
    }
    container server-certificates {
      leaf-list server-certificate {     // from original draft
        type binary;
      }
      leaf-list server-certificate-ref {     // added in revision
        if-feature keychain;
        type leafref {
          path "/kc:trust-anchors/kc:trust-anchor/kc:name";
        }
      }
    }

  PROs: still backwards-compatible
  CONs: not a nice data model (imagine it as CLI)

OPTION 3: like Option 2, but use a "choice" statement instead

  PROs: backwards-compatible
  CONs: not a nice data model, no ability for server to
        opt-in to implementing the keychain module

OPTION 4: replace *now* the binary type with a string type
          and dispense altogether using a union later.

  Now:

    container trusted-ca-certs {
      leaf-list trusted-ca-cert {
        type string;
        description "key to some list of certs";
      }
    }
    container server-certificates {
      leaf-list server-certificate {
        type string;
        description "key to some list of certs";
      }
    }

  Later:

    container trusted-ca-certs {
      leaf-list trusted-ca-cert {
        if-feature keychain;
        type leafref {
          path "/kc:server-certificates/kc:server-certificate/kc:name";
        }
      }
    }
    container server-certificates {
      leaf-list server-certificate {
        if-feature keychain;
        type leafref {
          path "/kc:trust-anchors/kc:trust-anchor/kc:name";
        }
      }
    }

  PROs: No change in model structure
  CONs: backwards-compatible?

  I rationalize that OPTION #4 is backwards compatible in that
  the value  is still a string on the wire and that the server
  is still enforcing the rules it must've been enforcing before.

  Thus, no change in syntax or semantics.

Any other options?  Are any options acceptable?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 08:38:29 +0200

> to make use of the new keychain model?

For the sake of completeness:

OPTION 5: factor out a keychain model now and use it

  import ietf-keychain {
      prefix kc;
  }

Yes, this sounds bad since this means another dependency. But that
said, getting the keystore (or keychain or credential store) right is
likely not much more work than getting it right for the server model
(although a generic keystore might attract more security area eyeballs
but then this may not be bad either in terms of quality of the final
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: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 13:51:34 +0200 (CEST)

> OPTION 5: factor out a keychain model now and use it

How is this different from option 4?

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 14:08:33 +0200

> How is this different from option 4?

Option #4 says we use an opaque string to refer to something yet to be
defined. Option #5 says we define it and use a leafref. I actually
think #4 is broken since it requires updates that I think violate YANG
update rules nor do I understand why something that was a string
suddenly becomes conditional via an if-feature.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 14:48:29 +0200 (CEST)

> suddenly becomes conditional via an if-feature.

Maybe I am confused.  I am lookng at the issue page
https://github.com/netconf-wg/server-model/issues/49.  Kent posted a
message there 6 days ago, in which he lists 4 options.  Option #4 is
described as: Work on a keychain solution of some sort - this would
delay server-model draft longer...

Is there another option list for this issue?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 15:42:55 +0200 (CEST)

> Is there another option list for this issue?

Aha, ok, found it in an email from Kent.  I suggest we try to keep a
single option list for each issue up to date.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Jun 2015 15:19:09 +0000

> I actually think #4 is broken since it requires updates that I think
>violate YANG update rules

I couldn't find specific language that prevented it.  I was hoping that it
might be allowed since the syntax/semantics would remain the same...

> nor do I understand why something that was a string suddenly becomes
>conditional via an if-feature.

This was a copy/paste error, OPTION 4 should've been:

  Now:

  Later:

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Jun 2015 20:11:26 +0000

>single option list for each issue up to date.

There are two different lists:

 - one list for what to do with this draft
 - the other list exploring how we might revise the module to use a
   keychain module in the future, assuming we don't do it now.

The goal for the 2nd list was to see if there were any elegant options
to delaying defining a keychain module now.  To which I think only
the "poor man's leafref" played out nicely.

I just updated comment #1 on this issue to reflect the living status of
this 
issue: https://github.com/netconf-wg/server-model/issues/49

Regards,
Kent