Subject: [Netconf] update to client/server drafts

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Jun 2018 00:53:45 +0000

All drafts updated! It looks like a big change, but almost all of it
goes to:

 1) the introduction of the new crypto-types and trust-anchors modules

 2) the resurrection of the keystore module, along with groupings 
    enabling keys to be locally-defined of a reference to a key in
    the keystore module

 3) reformatting all YANG modules to not exceed 69 chars/line.

To recap, the relationship between these drafts is:

                     crypto-types
                       ^      ^
                      /        \
                     /          \
           trust-anchors      keystore
              ^      ^------+    ^   ^
              |              \   |   |
              |      +-----------+   |
              |     /          \     |
       ssh-client-server      tls-client-server
        ^                      ^           ^
        |                      |           |
        |            +---------+           |
        |           /                      |
 netconf-client-server          restconf-client-server

I have some questions for the WG:

 1) no regrets about trust-anchors being separate from keystore,
    right?

 2) are we happy with keystore's "local-or-keystore" groupings
    (not too complicated?) and, if yes, should we have a similar
    ability for trust-anchors (e.g., a "local-or-trust-anchor"
    grouping like in the keystore module)?

 3) should some of keystore's groupings be moved to crypto-types?
    e.g., asymmetric-key-grouping isn't a keystore-specific
    concept.

 4) should trust-anchors include SSH host keys at all?  Maybe this
    draft should define two modules (x509-trust-anchors and
    ssh-trust-anchors)?

 5) should algorithm identities be moved from ssh/tls-client/server
    to crypto-types?

 6) should we add a "periodic" feature to the netconf/restconf
    client/server drafts, enablings the initiating peer to
    optionally support periodic connections? 

I'll start a thread for each later, my only goal for mentioning
them here is to get people thinking about such things when looking
at these drafts. 

Next steps:

My current plan is to update the zerotouch draft next, to make use
of the new trust-anchor and keystore drafts, in the example device
configuration module in the Appendix.

Once the zerotouch draft is submitted for publication, I'll swing
back around to these drafts, hopefully updating them one more time
before Montreal.

In the meanwhile, it would be awesome if you all could take a good
look at these.  You really only need to look at the YANG modules
themselves, but I still recommend looking at the drafts, which
contain tree diagrams and examples that makes everything easier
to understand.

Thanks,
Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jun 2018 13:27:04 +0200 (CEST)

Hi,

> To recap, the relationship between these drafts is:

Well, when the name was changed to trust-anchors, the idea was to
remove keystore.  Now we have a config tree in keystore again, so the
situation is a bit different.

The alternative would be a single module with:

     +--rw keystore
        +--rw asymmetric-keys
        +--rw pinned-certificates* [name]
        +--rw pinned-host-keys* [name]

or maybe:

     +--rw keystore
        +--rw asymmetric-keys
        +--rw trust-anchors
           +--rw pinned-certificates* [name]
           +--rw pinned-host-keys* [name]

BUT, I don't think we should overengineer this.  I don't have a strong
opinion either way.

>     (not too complicated?)

>From a modelling pow it looks fine.  But what is the use case for the
"local" case?  Should it have an "if-feature"?

>     and, if yes, should we have a similar

If there is a use case for non-central keys in keystore, I assume the
same use case applies to trust anchors?

>     e.g., asymmetric-key-grouping isn't a keystore-specific

Seems reasonable.

>     draft should define two modules (x509-trust-anchors and

I don't think that is necessary.  Maybe use features though.

>  5) should algorithm identities be moved from ssh/tls-client/server

Which identities do you mean?

>     optionally support periodic connections? 

I don't think it is necessary, but won't object to it being added.

BTW, why does "persistent" have an idle timeout?  It seems to me it
will just immediately reconnect after termininating the session due to
idleness.

/martin

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Jun 2018 21:13:26 +0000

Hi Martin,

Thanks for diving into the questions right away!

> BUT, I don't think we should overengineer this.  I don't have a strong

Balazs K and I had a non-committal exchange about this before.  Search for "I assume the trust anchors would be fully separated from this?" on this page: https://mailarchive.ietf.org/arch/msg/netconf/q3jrg1DW8xl64AfvIhxjH7em2wQ.  Did you see that exchange before?  Any additional thoughts?  

> "local" case?  Should it have an "if-feature"?

For the use-case, search for "So my take would be that ietf-keystore should support using the same key from multiple protocols, and support separate keys for each protocol too." on this page: https://mailarchive.ietf.org/arch/msg/netconf/xYYf0NSeT9mgtJ1KH-h7SYLSmXA.  

Perhaps I jumped to a conclusion, as the keystore-mechanism can also support distinct keys per use as well but, after suggesting the local-or-external (now local-or-keystore) grouping, follow-ups from Balazs B, who conferred with Balazs L, and also Eric V, seem to suggest that they like the modularity.  

Taking a step back, I think that it's fair to say that keystore-based keys cover all use-cases (esp. the need to share a key across uses, and the need to use a system-provided key, e.g., IDevID), whereas local-keys are best for a) helping some servers avoid needing to implement the keystore mechanism (not sure if this is important, or even a good thing), and b) reinforcing that the key is definitely not being shared (not sure if this is important either).

Regarding having an "if-feature" statement for the "local" case, assuming we keep support for local keys, some thoughts:

a) Balazs and Balazs suggested the same before, I just missed it.  Search for "the cases are in features" on this page: https://mailarchive.ietf.org/arch/msg/netconf/t-QtmTs7gZoKd2Cm8tVpxDpeA2U.

b) I'm unsure about *if* a feature statement makes sense.  I hesitate because it seems that any code able to process a keystore key surely could process a local key; it is literally the same key structure, only its storage location varies.  It seems that "local" should always be possible, a server would never not implement it unless, of course, we remove the support for locally-defined keys.

c) I'm unsure about *how* to best introduce the feature statement.  Note that the "keystore-implemented" feature is defined in the keystore module, which makes perfect sense, either the keystore module is *implemented* or not; it's a global thing.  Whereas, the decision to support locally-defined keys seems like it might be more of a per-use kind of thing.  That is, rather than have an "if-defined 'not keystore-implemented'" (not the negation), each module that "uses" the grouping might instead augment-in an if-feature statement of its own. 

> same use case applies to trust anchors?

Yes, both issues can share the same fate.  And just like with keystore, centralized trust-anchors satisfy all use-cases (esp. the sharing of a large list of trust anchors), whereas locally-defined trust anchors are best for a) helping some servers avoid needing to implement the trust-anchors mechanism (this actually doesn't sound like a good thing to me), and b) reinforcing that some set of trust-anchors are not being shared (unsure if this is important).

>>     e.g., asymmetric-key-grouping isn't a keystore-specific

I think so too, but I recall there being a little pushback before, I think mostly regarding the old top-level "notification" statement.  Now that notification statement has been made part of one of the groupings and so, if we move the groupings to ietf-crypto-types, we will again have the notification statement there.  My view is that this is okay, as being inside a grouping makes it acceptable.

> I don't think that is necessary.  Maybe use features though.

Good idea, achieves the same with less  I just made this change to my local copy.

> Which identities do you mean?

I specifically mean the ones defined here:

  https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-06#section-5.3

and here:

  https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-06#section-5.3

I already reached out to Gary Wu about this.  He went at it from a "what do the SSH and TLS protocols define" perspective.  But the reality is that, if the private key's structure is defined by what's currently in the keystore draft, then there needs to be some reconciliation between the alg-identities used to create the key and the alg-identities used within the protocol.

> I don't think it is necessary, but won't object to it being added.

I'd like to make a case for adding a feature for it, which is that, in my experience, periodic connections are not commonly implemented.  So, a feature would primarily be to accommodate that market trend.  That said, periodic connections are incredibly useful and, by not having a feature, we might nudge the industry into supporting them more.

> will just immediately reconnect after termininating the session due to

Hmmmm, I'm unsure how that got in there.  It looks like it goes back to draft-ietf-netconf-server-model-07 (note, that's the old draft, before the refactoring), and the change log says something about issue #51, which is a typo, should've been #54.  Looking at the issue is interesting: https://github.com/netconf-wg/server-model/issues/54.  AFAICT, I messed up.  I've now removed .../persistent/idle-timeout from ietf-[netconf|restconf-[client|server] (4 modules) in my local copy.

Kent // contributor