Re: [netconf] Genart last call review of draft-ietf-netconf-keystore-29

[Reese Enghardt <[e-mail]>]

Hi Kent,

Thank you for the responses. Please see inline:

On 1/26/24 17:47, Kent Watsen wrote:
> On Jan 22, 2024, at 8:36 PM, Reese Enghardt via Datatracker 
> <[e-mail]> wrote:
>>
>> […]
>> I was surprised to see that the model allows to store keys in the 
>> clear. I
>> assume that the WG has carefully considered the security implications 
>> here, and
>> at least Section 4.2 says a key SHOULD be encrypted. Still, I wonder, 
>> if it's
>> worth giving a bit of context in the Introduction, maybe saying why 
>> clear text
>> keys are supported but that they SHOULD NOT be used unless there's no 
>> other way?
>
> Whoops, my Security Considerations for the module left out this paragraph
> added to all of the other drafts in the series:
>
> Please be aware that this YANG module uses groupings from
> other YANG modules that define nodes that may be considered
> sensitive or vulnerable in network environments.  Please
> review the Security Considerations for dependent YANG modules
> for information as to which nodes may be considered sensitive
> or vulnerable in network environments.
>
> This is important because the “cleartext-key” and “cleartext-private-key”
> leafs come from groupings defined in the crypto-types draft:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-27#section-2.1.4.3
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-27#section-2.1.4.5
>
> And that draft’s Security Considerations sections says:
>
> 3.7. Cleartext Passwords and Keys
>
> The module contained within this document enables, only when specific
> "feature" statements are enabled, for the cleartext value of passwords
> and keys to be stored in the configuration database. Storing cleartext
> values for passwords and keys is NOT RECOMMENDED.
>
> All good?

Yes, I think that's sufficient.


>> Section 5 (Security Considerations):
>> Given the sensitive nature of the data stored using this model, I suggest
>> another pass at this section following RFC 3552 (BCP 72): Are there 
>> any other
>> possible attacks on confidentiality, integrity, authenticity, or 
>> availability,
>> which are in scope for this section? Is there any specific threat 
>> model that
>> needs to be considered? I also suggest naming some of the possible 
>> impacts of
>> these attacks. Some possible impacts seem obvious, but I wonder if 
>> I'm missing
>> any significant impacts because I'm not very familiar with the model.
>
> IDK either.  But I can say that this draft has had two SecDir reviews.
> I’m happy to email or get on a call to discuss with interested parties 
> at anytime.

Ok. I don't have any specific suggestions and I'll defer to the security 
experts here.


>> Section 5.3:
>> "access control mechanisms like NACM SHOULD be used to limit access 
>> to the
>> key's secret data to only the most trusted authorized clients (e.g., an
>> organization’s crypto officer)." Does "client" refer to a person 
>> here, rather
>> than the RFC 6241 definition of client, which the document says it 
>> uses? If so,
>> I suggest finding a different term here.
>
> Client refers to RFC 6241’s definition of client.  But that client 
> authenticates
> itself to the server using credentials that may, e.g., belong to an 
> organization’s
> crypto officer. I did this:
>
> s/an organization’s/belonging to an organizations’s/???
>
> Is it better?

Yes, that helps, thank you.


>> Nits/editorial comments:
>>
>> Section 5.1:
>> "The YANG module defined in this document defines a mechanism called a
>> "keystore" that, by its name, suggests that it will protect its 
>> contents from
>> unauthorized disclosure and modification." This might be semantics, 
>> but: In my
>> mind, the name suggests that there's sensitive data, which implies 
>> that the
>> data needs to be protected, with obvious consequences otherwise. Please
>> consider rephrasing this sentence.
>
> I get what you’re saying, but turning the sentence around like that 
> seems to
> misplace the emphasis, e.g., the draft isn’t about the data but the 
> mechanism.
> At least I couldn’t see how to do it.  Can you suggest specific 
> replacement text?

Maybe just simplify it as follows?

"The YANG module defined in this document defines a mechanism called a
"keystore" that will protect its contents from unauthorized disclosure 
and modification.

That said, I won't insist on this editorial change, I'd be okay with 
leaving the text as is if you think that's better.


Thanks,
Reese