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

[Henk Birkholz <[e-mail]>]

Hi Balázs,
hi list,

Item 3.) is on me, I think. Sorry!

For me personally, there are a few technical questions that have to be 
resolved on the list first.

Under the assumption that the trust stores will be used for TLS (maybe 
potential other things), I am not sure if the YANG module is an 
appropriate place to make some (maybe implicit?) 
"mandatory-to-implement" decisions. If there can be (and I think 
effectively there should be, but I do not know the appropriate place for 
them) prescriptive statements here, I would recommend the following 
proposals for the use with TLS:

1.) With respect to the format of the "raw" pub-key, I propose that the 
structure defined in section 3 of RFC 7250 MUST be used.

2.) With respect to cipher suite and interoperability, I propose to make 
RFC 7151 and RFC 4492 (basically the NIST curve and its format 
extensions) mti for raw pub-key and to point to RFC 7250 for guidance & 
to make RFC6635 mti for psk.

3.) With respect to key identities, I propose that raw pub-key 
identities as specified in RFC 6920 and a minimum hash length enabled by 
mode sha-256-120 MUST be used & to support and recommend the use of 
Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the 
corresponding security considerations (section 7 in RFC 4279).

My first question - on a technical level: do these proposals in the 
context of using TLS sound reasonable to the group?

My second question - on a semantic level: do these normative 
requirements belong here?

My third question - on a noob level :) If they belong here, where would 
these mandatory requirements be spelled out?

Viele Grüße,

Henk


On 06.11.19 04:45, Kent Watsen wrote:
> 
> Hi Balázs,
> 
> 
>> I see some FIXMEs in ietf-crypto-types and related models. I would be 
>> interested about the current state of them and possibility to clean 
>> them up.
> 
> Yes!  thanks for taking this up.
> 
> 
>>  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?
> 
>> 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?
> 
> 
> 
>>  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.
> 
> To your last sentence regarding features, could you provide an example 
> of what you mean?
> 
> 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?   Why was/is seeing them in truststore a 
> surprise, perhaps because they're not encryptable there?  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
> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>