Re: [netconf] draft-ietf-netconf-keystore-09.txt

[Nick Hancock <[e-mail]>]

Hi Kent, 


> -----Original Message-----
> From: Kent Watsen <[e-mail]>
> Sent: 02 May 2019 04:42
> To: Nick Hancock <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt
> 
> 
> Hi Nick,
> 
> You are correct that something is amiss, but I'd like to discuss the fix more.
> 
> Your proposal looks (squinting my eyes) right (have you tested it?), but I'm
> wondering if there isn't a lower-level and potentially more useful fix...

No, I haven't tested it. However, we have implemented similar YANG to 
access an entry of a list that itself is within a list in the same 
way successfully in the past.

> 
> In particular, note that 'ks:asymmetric-key-certificate-ref' points to a
> certificate in the the keystore that comes from the 'uses ct:asymmetric-key-
> pair-with-certs-grouping' statement.   The idea behind this grouping is that,
> whenever a certificate is configured, whether in the keystore or not, that the
> 'asymmetric-key-pair-grouping 3-tuple (alg, pub key, private key) is also
> configured.   This suggests that ct:asymmetric-key-pair-with-certs-grouping
> may be missing a 'must' statement or, more likely (due to the fact that the 3-
> tuple may only exist in <operational>), its 'description' statement is missing
> that precondition in its text.
> 
> Thoughts?

Given that a client has the required permissions, the current model 
allows a client to create an entry in the list 'asymmetric-key' 
without the 3-tuple leafs 'algorithm', 'public-key' and 'private-key' 
as allowed via the must statement on the list. At this point there 
would be no 3-tuple in <operational> either. Defining the 3-tuple in 
<intended> or <operational> would be a second step, such as invoking 
the action 'generate-hidden-key'. Since there is, as you indicated, 
no 'must' statement relevant to the 'certificate' list, the model 
also allows a client to configure a certificate (chain) on an entry 
in the list 'asymmetric-key' without the 3-tuple in either <intended> 
or <operational>. The asymmetric key entry would not be able to be 
used to establish a TLS session due to the missing 3-tuple, of course.

Is this a valid use case? Possibly. I could argue that a client may 
wish to 'park' certificate chains in the keystore without necessary 
immediately using them on the server or even just pre-provision them 
and then provide the actual public key later maybe through some other 
process based on an operator's security policies? It makes no sense 
to reference a certificate in the keystore that is missing the 
3-tuple as the server identity of a NETCONF server or client identity 
of a NETCONF client as it cannot be used, so the question is whether 
it would make more sense to constrain the actual reference to 
reference certificates that have 3-tuple, if this is at all possible 
considering that the 3-tuple may only be in <operational>?


During analysis of deploying the keystore and truststore in our 
implementation, I have made some further observations that may be of 
interest:

1. There is nothing in the model to prevent a client configuring a 
   certificate to an asymmetric key that is not applicable to that 
   asymmetric key or even a certificate chain in the keystore or 
   truststore that is incompatible to the required type 
   ('end-entity-cert-cms' or 'trust-anchor-cert-cms' respectively) 
   or is this to be rejected by the implementation, in which case 
   this behavior is not described in the YANG?

2. I am not convinced whether the use of the prefix 'pinned-' on the 
   containers and lists in ietf-trust-anchors is correct. The 
   certificates are available in the truststore for pinning, yes, but 
   does not the 'pinning' actually take place when the certificates 
   are configured for client authentication on a server or server 
   authentication on a client? So I would argue that a certificate 
   may be in the trust store, but not necessarily pinned, so the name 
   may be misleading or am I missing something? Thus, I would have 
   expected the containers and lists to be without the 'pinned-' 
   prefix within the truststore itself. The 'pinned-' prefix being 
   only on the references, which is the case in the NETCONF client 
   and server models.

3. As an initial step we are analyzing the standalone use of the 
   keystore in truststore modules and were considering some 
   proprietary notifications that would include the certificate 
   (chain) received during TLS session establishment, but could not 
   'use' the groupings in ietf-crypt-types because they include 
   actions and notifications, which are not allowed in notifications. 
   Maybe it would be advantageous to provide basic groupings without 
   actions and notifications for use in proprietary RPCs and 
   notifications and provide refined versions of these groupings that 
   include the actions and notifications? Obviously this would mean 
   even more groupings, but wouldn't this increase their reusability?

Regards
Nick

> 
> Kent // contributor
> 
> 
> 
> 
> On Apr 30, 2019, at 11:39 AM, Nick Hancock
> <mailto:[e-mail]> wrote:
> 
> Hi Kent,
> 
> I have just noticed a issue with the leaf 'keystore-reference' used
> in the grouping 'local-or-keystore-end-entity-cert-with-key-grouping'
> in ietf-keystore.
> 
> This leafref uses the typedef 'asymmetric-key-certificate-ref', but,
> unless I am missing something, this alone will not work, because a
> predicate for the list 'asymmetric-key' is missing.
> 
> I would expect something like the following:
> 
> case keystore {
>  if-feature "keystore-supported";
>  leaf asymmetric-key-name {
>    type ks:asymmetric-key-ref;
>      description
>        "A reference to an asymmetric key that exists in
>         the keystore. ";
>  }
>  leaf certificate-name {
>    type leafref {
>      path
>        "/ks:keystore"
>        + "/ks:asymmetric-keys"
>        + "/ks:asymmetric-key"
>        + "[ks:name=current()/../"
>        + "asymmetric-key-name]"
>        + "/ks:certificates"
>        + "/ks:certificate/ks:name";
>    }
>    description
>     "A reference to a specific certificate associated
>      with the given private key, stored in the keystore.";
>  }
> }
> 
> Regards
> Nick