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

[Kent Watsen <[e-mail]>]

> On Feb 23, 2023, at 6:17 AM, tom petch <[e-mail]> wrote:
> 
> From: Kent Watsen <[e-mail]>
> Sent: 29 January 2023 02:23
> 
> <inline under <tp> in several places >

As mentioned before, it is never easy to find your comments.  Please consider switching your webmail provider to something enabling threaded comments...


> 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.
> 
> 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>

Moved and consolidated paragraphs:

        "Built-in key types SHOULD be either hidden or encrypted (possibly 
          both hidden and encrypted).  Built-in keys SHOULD NOT be cleartext, 
          even if protected by an access-control mechanism (e.g., NACM)."

           "It is RECOMMENDED that master keys (MKs) are built-in but, if
            this is not possible, access control mechanisms like NACM SHOULD
            be used to limit access to the MK's secret data to only the most
            trusted authorized clients (e.g., an organization’s crypto officer).
            In this case, it is RECOMMENDED that the MK is not built-in and hence
            is, effectively, just like a KEK. 

To the Security Considerations section.




> 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>

+1  laugh



> 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>

Then validation never succeeds.   The server must either implement one to the two provided features, or augment in it's own "case" statement.


> 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>

I'm going to leave it in for the IESG what to do about Section 4.

But I'll say this, the WG was not happy with the model for built-in keys until it could be should how they could be 1) secured and 2) used/referenced in the config. 


> 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>


Not my problem.

Kent // author