Re: [netconf] FIXMEs in ietf-crypto-types and client/server models

[Balázs Kovács <[e-mail]>]

Hi Kent,



1.       Key-format (symmetric-key, public-key, asymmetric-key-pair)
I assume the idea here is to make it possible to have choices for the ASN.1 types holding the keys. If this flexibility for formats is necessary I don’t have any objection to them but having a single agreed type for these different use cases would also suffice.

I believe here you're referring to the 3 instances of lines like:

      leaf key {
        nacm:default-deny-all;
        type binary;
        //must "../key-format";  FIXME: remove comment if approach ok
        ...
      }

FWIW, the whole "key-format" leaf is still being sussed out (your opinion would be helpful on that thread as well) but, so far it seems promising.  The reason these lines are commented out is because 1) the WG hasn't committed to this path yet and 2) I didn't want to update all the examples in all the drafts (other than truststore and keystore) to add a "key-format" leaf until the WG had more consensus on the "key-format" leafs.

I don't understand your last comment/sentence.  Can you provide an example?

Balazs> Ok, then let’s wait for WG decision. Well, I just say that the earlier ways of communicating the key formats were adequate from my point of view, which was that in documentation it was said that for RSA use RSAPrivateKey and for EC use ECPrivateKey, and similarly for other types. I’m also ok with the key-format approach if preferred by the WG.

In earlier versions:

           description
             "The value of the binary key.  The key's value is
              interpreted by the 'algorithm'.  For example, a DSA key
              is an integer, an RSA key is represented as RSAPrivateKey
              as defined in RFC 8017<https://tools.ietf.org/html/rfc8017>, and an ECC key is represented as
              ECPrivateKey as defined in RFC 5915<https://tools.ietf.org/html/rfc5915>."


2.       attributes in asymmetric-key-pair-with-cert(s)-grouping
I think attributes should be kept optional. If there is anything else besides subject seen mandatory maybe it should be extracted out from attributes and be spelled out a separate leaf, but I don’t think there is.

I believe here you're referring to the 2 instances of lines like:

        leaf attributes {
          type binary; // FIXME: does this need to be mandatory?
          ...
        }

These are in the "generate-certificate-signing-request" actions found inside the asymmetric-key-pair-with-cert(s)-grouping.

Hmmm, are you claiming that "attributes" are not required in order to generate a CSR?  I think the CSR itself MUST have attributes (right?) so, if not specified, what default values are used?

Balazs> In RFC2986<https://tools.ietf.org/html/rfc2986#section-3> the attributes are said to be optional. We just need the subject DN as mandatory, don’t we?




        1. A CertificationRequestInfo value containing a subject

           distinguished name, a subject public key, and optionally a

           set of attributes is constructed by an entity requesting

           certification.




3.       PSK and raw public keys
The use case of PSK and raw public keys are not the most urgent in my opinion which now slows a bit the progress of these drafts, but let’s make an attempt to finalize them.

Agreed, but they are legal for TLS and a WG member stated that they were needed in order to support another IETF WG's efforts.  A quick resolution would be best!



raw-public-keys: I see these were added due to RFC 7250 and 8446. I guess in truststore this is a separate container to distinguish from SSH host keys. For configuring the private part I think keystore already gives support for this case with the asymmetric key (w/o cert) and in the client/server drafts Kent’s proposal could be used (I replaced raw public key with existing type, shouldn’t that be useable straight away?)

                    container <client-identity or server-identity> {
                      choice auth-type {
                         uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
                         uses ks:local-or-keystore-asymmetric-key-grouping;


I would also prefer if these choices are in features, so that an implementation can choose.

To your first sentence, yes, "psk" (and "raw-public-key") are top-level nodes in truststore, as can be seen here (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1).   Note, the trust-anchors draft accidentally doesn't include the ietf-truststore.yang module.

The body of your comment above seems to be about supporting the secret-half of the PSK and RPK within the Keystore.  I've raise this question a couple times previously to Henk (who's asking for the PSK/RPK add), but he's not responded yet as to if doing so is important (though I can only imagine that it does).   With that said, I think your YANG snippet is meant to be in ietf-tls-server and ietf-tls-client modules (right?).  I'm having a hard time following the "I replaced raw public key with existing type, shouldn’t that be useable straight away?" comment.

Balazs: You had an example earlier in an email from 10/8/2019, which is about the TLS client/server models. Below, you are referring to some possibly new groupings that you wanted to propose. I don’t understand though why you mentioned these new groupings since ‘ks:local-or-keystore-asymmetric-key-grouping’ (RPK) and something new that just refers to a keystore symmetric key, such as ‘ks:local-or-keystore-symmetric-key-grouping’ (PSK) should be good. This latter I think would be a new grouping, but with existing terminology.

All, looking at ietf-tls-client.yang and ietf-tls-server.yang, adding the ability to configure the "private" half of a PSK or raw public key would be something like:

                OLD
                    container <client-identity or server-identity> {
                      uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
                NEW
                    container <client-identity or server-identity> {
                      choice auth-type {
                         uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
                         uses ks:local-or-keystore-raw-public-key-grouping;
                         uses ks:local-or-keystore-pre-shared-key-grouping;



To your last sentence regarding features, could you provide an example of what you mean?


container <client-identity or server-identity> {
    choice auth-type {
        mandatory true;
        case certificate {
            if-feature x509-certificate-auth;
           uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
       }
        case raw-public-key {
            if-feature raw-public-key-auth;
           uses ks:local-or-keystore-asymmetric-key-grouping;
       }
        case psk {
            if-feature psk-auth;
           uses ks:local-or-keystore-symmetric-key-grouping;
       }

I assume these features would then need to be defined in the TLS client/server draft.

PS: none of this goes to the FIXME in the ietf-crypto-types.  I had previously asked Henk to provide some text here as well but, apparently, like all of us at this time, he's been busy!



 psk: given that the asymmetric keys without certs were covered by host keys and raw public keys, I think psk should only be symmetric keys. Symmetric keys are then sensitive/secret data and as such I believe they should only be referenced from keystore. Seeing them in truststore was unexpected for me. When it comes to their use, clients and servers should be extended with following configuration (and I assume we talk of TLS clients and servers only):

                    container <client-identity or server-identity> {
                      choice auth-type {
                         uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
                         uses ks:local-or-keystore-asymmetric-key-grouping;
                       uses ks:local-or-keystore-symmetric-key-grouping;

Latter grouping would be a new one, but it would use existing constructs and terms from keystore. I don’t think we need new ones. Selected cipher suites will need to have PSK in them for using symmetric key (similar match needed for the others). Note that symmetric keys can be used for other cases than TLS PSK, for example SNMPv3 USM. Again, features would be necessary (those could be saying x.509 or raw-public-key or psk).


Correct, I said the same (that PSKs are essentially symmetric keys) before as well.  Regarding only being referenced to keystore, why not also support them being local-definitions too?  Certainly not a problem if encrypted and, even when not encrypted, then they can be "protected" by NACM-like mechanisms, right?

Balazs> Local definitions are ok too that’s why I used a hypothetical grouping name  ks:local-or-keystore-symmetric-key-grouping.

  Why was/is seeing them in truststore a surprise, perhaps because they're not encryptable there?

Balazs> When PSKs are used then both communicating ends use the shared key for signing and verifying messages. Then one configuration seems enough that is either local or from keystore, why would it be necessary to set it up yet another time for verification from local or truststore? This would mean there is no need for a PSK option when configuring how to  verify the peer.

container <client-authentication or server-authentication> {
    choice auth-type {
        mandatory true;
        case certificate {
            if-feature x509-certificate-auth;
            container ca-certs {

                uses ts:local-or-truststore-certs-grouping
            }
            container server-certs {

                uses ts:local-or-truststore-certs-grouping
            }
       }
        case raw-public-key {
            if-feature raw-public-key-auth;
                uses ks: local-or-truststore-raw-pub-keys-grouping
       }

No need for PSK config since it is already configured in client/server-identity.

Or what is the reasoning why it is necessary to configure a PSK from truststore?

 I agree that symmetric keys can be used beyond PSK (and encryption of the asymmetric keys, the original use case).  Regarding features, again, please provide a YANG-snippet so it is clear to me (and all) what you mean.


Thanks!
Kent