Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13

[Kent Watsen <[e-mail]>]

Hi Yoav,

I finally found some time  :sigh:   ;)

Please see below for responses to your comments.

Kent


> On Oct 2, 2020, at 7:20 AM, Kent Watsen <[e-mail]> wrote:
> 
> [-last-call]
> 
> Hi Yoav,
> 
> Thank you for your review!  The takeaway for me is that some clarifications are needed, but otherwise the draft is fundamentally okay.  I will post an update, or perhaps just a GitHub commit, for your review, when I get a chance.  That said, my getting a chance will be delayed as I have a major engagement I need to focus on now.  This email is just to let you know that your review has not been forgotten.
> 
> Thanks again,
> Kent
> 
> 
>> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker <[e-mail]> wrote:
>> 
>> Reviewer: Yoav Nir
>> Review result: Has Issues
>> 
>> I have reviewed this document as part of the security directorate's ongoing
>> effort to review all IETF documents being processed by the IESG.  These
>> comments were written primarily for the benefit of the security area directors.
>> Document editors and WG chairs should treat these comments just like any other
>> last call comments.
>> 
>> The document defines a YANG model for managing a trust anchor store. It allows
>> two kinds of trust anchors: certificates and raw public keys. However,
>> certificates are not just containers for public keys. Certificates include
>> attributes about key usage, path constraints and name constraints, all of which
>> constrain the ability to use the public key, and are relevant for trust
>> anchors. As far as I can tell the document does not include any attributes to
>> equivalently constrain the use of the raw public keys.  If the intention is
>> that raw public keys will not be constrained, the document should state this
>> explicitly.

Good catch.  You’re right that this document is not constraining the raw keys in the truststore.  Looking deeper, I see that the keys are unconstrained in both the “keystore” draft and the common “crypto-types” draft.  It seems like the right thing to do is to put a Security Consideration note into each draft.  Something like this?

   4.2.  Unconstrained Public Key Usage

      This module enables the configuration of public keys without
      constraints on their usage, e.g., what operations the key is allowed
      to be used for (encryption, verification, both).

      This module also enables the configuration of certificates, where
      each certificate may constrain the usage of the public key according
      to local policy.

Thoughts?


>> Perhaps this is clear to the people who worked on the document, but it's not
>> clear to me.  Are the trust anchors managed with this module supposed to be
>> used to establish trust for the NETCONF or RESTCONF connections?  Section 1.1
>> seems to suggest that it does, but then how is the bootstrap problem solved?
>> How do we establish the NETCONF connection the first time, and if we are able
>> to do that, why do we need more certificates?  If the answer is no, and the
>> certificates are to be used by other protocols, then perhaps some re-wording in
>> section 1.1 would help to show this. Currently, it says: "This document
>> presents ... YANG modules that are part of a collection of RFCs ... define
>> configuration modules for clients and servers of both the NETCONF and RESTCONF
>> protocols."

Answering your question: Yes, the trust anchors may be used to establish trust for NETCONF and RESTCONF connections.   The trust anchors may also be used by other models (e.g., other TLS-based protocols), created outside the effort described in Section 1.1.

For the bootstrap problem, Section 3 (Support for Built-in Trust Anchors) shows how a system may be shipped from a Manufacturer’s facility with preconfigured trust-anchors.  FWIW, the “keystore” draft separately defines how a system can be shipped from a Manufacturer’s facility with preconfigured private keys (e.g., using a TPM-protected key).

You suggest rewording the first paragraph in 1.1.  First, I have to assume you saw the second paragraph, that says that the modules have been defined to be used by other efforts, so my best guess is:

OLD:
This document presents one or more YANG modules [RFC7950] that are part of a collection of RFCs that work together to define configuration modules for clients and servers of both the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols.

NEW:
This document presents one or more YANG modules [RFC7950] that are part of a collection of RFCs that work together to, ultimately, enable the configuration of the clients and servers of both the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols.

Please let me know what you had in mind, if something different.


>> The security considerations section is OK, especially sub-section 4.2.

Thanks.


>> Sub-section 4.1 has the following:
>> 
>>  The YANG module defined in this document defines a mechanism called a
>>  "truststore" that, by its name, suggests that it will protect its
>>  contents from unauthorized modification.
>> 
>> Perhaps this is my different perspective, but the name doesn't lead me to
>> expect that it protects its contents.  I think that the document should either
>> just suggest that some mechanism to prevent unauthorized modification should be
>> used, or to present such a mechanism in detail. The current text suggests is
>> partially specific by mentioning digital signatures and non-volatile storage,
>> but not explaining where the trust for the digital signature comes from and
>> what policies govern its us:
>> 
>>  In order to satisfy the expectations of a "truststore", it is
>>  RECOMMENDED that implementations ensure that the truststore contents
>>  are signed when persisted to non-volatile memory, to prevent
>>  unauthorized modifications from being made undetected.
>> 
>> It is too vague to be a specification, but still unnecessarily constrains the
>> solution space. I think the correct thing to do is to be explicitly vague and
>> to just suggest some mechanism for protecting the content.

Agreed.

OLD:
In order to satisfy the expectations of a "truststore", it is RECOMMENDED that implementations ensure that the truststore contents are signed when persisted to non-volatile memory, to prevent unauthorized modifications from being made undetected.

NEW:
In order to satisfy the expectations of a "truststore", it is RECOMMENDED that implementations ensure that the truststore contents are protected from unauthorized modifications when at rest.

What do you think?


Thanks,
Kent (as editor/author)