Re: [netconf] I-D Action: draft-ietf-netconf-keystore-27.txt

[tom petch <[e-mail]>]

From: Kent Watsen <[e-mail]>
Sent: 29 January 2023 02:23

<inline under <tp> in several places >

Hi Tom,

Thank you for your review of the keystore draft.
Please see below for my responses to your comments.

Kent

On Jan 18, 2023, at 11:48 AM, tom petch <[e-mail]> wrote:

From: Henk Birkholz <[e-mail]>
Sent: 18 January 2023 12:56

Hi Tom,

to your comment on "Security 101" content. I do not see that basic
repetition as a flaw considering the scope of audience, as implementers
might occasionally tend not to read all useful, but only the minimal
essential documents.

Having said that. Maybe the "Security 101" problem can be avoided by
some well-selected references to the extend of "Security Considerations
about key management of RFC-XXXX apply"? That could avoid the repetition
a bit.

<tp>
Henk

I am contrasting this I-D with RFC8177 on key chains which says
'  Implementations with keys provided via this model should store them
  using best current security practices.'
which is the sort of statement I would expect to see in a routing or ops RFC, leaving the technical detail to a Security Area one!

Tom Petch

Viele Grüße,

Henk

On 18.01.23 13:37, tom petch wrote:
Some thoughts, editorial mostly, on this version of this I-D.

Generally, I find many of the identifiers cumbersome, up to nine hyphen separated elements; I would see three or four as good and five as tolerable, more than that error prone,

     grouping local-or-keystore-end-entity-cert-with-key-grouping
As ever, I see -grouping as prolix.  I would also like to shorten local-or-keystore as a generic term for well, locality, or location, or place or site or   .... there are lots of possible synonyms.  Also where the grouping is about a cert then I think that that should come before locality.  To me it is the cert that matters not the option about its locality

I would also like to shorten 'cert-with-key' which occurs many times but do not have an alternative to offer.

You're the first to bring this up.   Whilst you make good points, I'm unwilling to change names unless others chime in.

The other general comment is that in places this reads as Security 101, which I do not think that the Netconf WG should be publishing (even if the text has come from Security ADs or such like).  The changes here would be small, deletions mostly,  but I think should be made.  Thus comments about built-in keys SHOULD NOT be cleartext are nothing to do with a YANG module, they are or they are not and no YANG module is going to change that.   There are several such statements in sections 3, 4 and 5 which to me belong in a BCP from the Security Area.

See discuss with Henk at top.   IDK about the the keychain draft, does it's data-model contain nodes such as "cleartext-password", "hidden-password", or "encrypted-password"?   The particular paragraph mentioned regards "built-in" keys, a concept unique to this draft (AFAIK), and it seems proper for the draft to say that "Built-in key types SHOULD be either hidden or encrypted", but not cleartext (even if projected by NACM).   FWIW, I think that there were two SecDir reviews on these sections.

WRT "There are several such statements in sections 3, 4 and 5", please provide a complete list.

<tp>

Well pretty much the whole of section 4 and in Section 3 statements about built-in keys not being cleartext.  This seems as applicable to Kerberos as to NETCONF which is why I see it as a BCP the Security Area should produce.  That said, as other posts of mine may suggest, I do not have high expectations that the Security Area will produce material that other Areas will find a use for.
</tp>

Some less contentious points.

     grouping asymmetric-key-pair-with-cert-grouping
     grouping asymmetric-key-pair-with-certs-grouping
I think an unfortunate pairing; that letter 's' buried in the middle will be missed.  Even
     grouping asymmetric-key-pair-with-cert
     grouping asymmetric-key-pair-with-certs
could cause erors.

The error you're concerned about seems like a small thing.  That is, even if the wrong name were entered, the tree-diagram or CLI/UI would quickly reveal.  So no a big deal?



   The term "keystore" is defined in this /draft /document/

Fixed - other instances (in this draft) are fixed as well.

The term "key" may be used to mean one of three things in this /draft:/document/
Well, four to be picky - you also have it from RFC2119

Yeap, like this one.  Fixed.


In the tree diagrams. the type 'string' seems to wander around, as in 2.1.3.7, and not stay in a predictable place

The tree-diagrams are generated using the latest version of pyang.  The closest RFC 8340 comes to providing guidance is "Additional whitespace may, for example, be used to "column align" fields (e.g., within a list or container) to improve readability".   I don't think we can fault pyang (though we could wish for better).

In lieu of fixing the tool, I could manually edit the tree diagrams, but that is both a lot of work and error-prone.  Note that the tree-diagrams are automatically generated and inserted every time I `make` and the document.

<tp>
No, anyone editing tree diagrams should be banished from the IETF:-)

</tp>

What happens to choice/case if no features are defined?  I do not know if YANG can enforce or cope with that.

Where are you?   Regardless, all the "choice" statements in ietf-keystore are "mandatory true", meaning that one case must be defined.

<tp>

In the choice local-or-keystore in several groupings, both case have if-feature so what happens if the features are not present?  I do not know.
</tp>


s.2.1.4
'The protocol-accessible nodes for the "ietf-keystore" module are an instance'
perhaps instances

Fixed.


s.2.2.3
 a big section when there are no pages numbers - worth splitting into subsections IMHO

Subsections added.


prefix eku
we could do with a documentation-only YANG prefix; to me this looks too real, perhaps ex-eku

Changed to "ex-keystore-usage"


s.3
built-in keys
Built into what?  The YANG module?  suggest 'built into the device' or some such.

Now: "keys built-in into the server".



I-D.ma-netmod-with-system
needs to be Normative IMHO - I cannot understand system without it

This document is not dependent on that work; it merely offered the reference as a related work.

That said, searching for "system", I found and replaced several instances to use the word "server" instead.  I think this may've been the actual source of your confusion.

<tp>

Well, yes in part
</tp>

Also, updated ref to point to adopted name: "ietf-netmod-system-config".


copied into <running>
copied from where?

Two paragraphs up: "...they are present in <operational> (and <system>, if used)."

<tp>
Mmm yes, with hindsight. The 20 or so lines of XML make it harder for me to make the connection with the earlier text, the XML makes it disjoint.
</tp> 

all key types may be copied
again, copied from where?

Again,  <operational> (and <system>, if used).   This paragraph also says <operational> a sentence later"


built-in key
lacks a terminal period

Fixed.


<running> data tree
Why data tree here when every else is just <running>?

Removed.


s.4 Nothing to do with Netconf IMHO!

The WG or the protocol?

<tp>
The Ops Area of the IETF!
</tp>

Regardless, this draft defines a data-model and related semantics.  You may not be aware, but many wanted to see this section fleshed out.

<tp>
I am not surprised by that but see that as a comment on the lack of support from the Security Area rather than something for this WG to address.
</tp>

s.5.3
SSH, TLS lack references

You're right, but this is in the template published by the IESG.  There are likely several dozen RFCs published this way...

<tp>
Which is an issue that a revised security template for YANG modules should address, what does it look like for a module that is all identity or all grouping or such like.

Tom Petch
</tp>

Kent




Tom Petch

_______________________________________
From: netconf <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: 12 December 2022 18:49
To: [e-mail]
Cc: [e-mail]
Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-27.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : A YANG Data Model for a Keystore
        Author          : Kent Watsen
  Filename        : draft-ietf-netconf-keystore-27.txt
  Pages           : 52
  Date            : 2022-12-12

Abstract:
   This document defines a YANG module called "ietf-keystore" that
   enables centralized configuration of both symmetric and asymmetric
   keys.  The secret value for both key types may be encrypted or
   hidden.  Asymmetric keys may be associated with certificates.
   Notifications are sent when certificates are about to expire.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-keystore-27


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


____________________________
_______________________________________________
netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf