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

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Dec 2020 00:35:32 +0000

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 <[email-masked]> 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 <[email-masked]> 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)

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Dec 2020 17:17:01 -0800

Hi Kent,

I'm not Yoav, but...

>       each certificate may constrain the usage of the public key according

This doesn't really fill me with joy.  In short, constraints are going to
have to be applied at *some* level, even if it's not this one, or the
system as a whole is likely to have some very surprising security
properties.  I recognize that coming up with a new language to describe
this sort of constraints is neither fun nor easy (and trying to repurpose
an existing language, such as that used by X.509, is not without issues
either), but I'd hope we could come up with something to say about how to
effectively use constraints on raw public keys.

Thanks,

Ben

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Dec 2020 21:03:48 +0000

Hi Ben,

> effectively use constraints on raw public keys.

You say constraints have to be applied at some level, but is this true when TLS uses a raw key?  Likewise for SSH keys (e.g., ~/.ssh/id_rsa)?

I’m extremely hesitant to make this change.  Already this work (9 drafts in total) has been in progress for more than 5 years.  Will you object during the IETF Last Call if it’s not added?

One thing not mentioned before, is that, while the keys are unconstrained in the three base drafts (crypto-types, keystore, and truststore), the “tis-client-server” and “ssh-client-server” drafts refine the base YANG models to assert that the raw public key must be a SubjectPublicInfo structure or an SSH public key, respectively.  In fairness, this only constrains the format of the data, not how the keys are used.   That said, this approach works with OpenSSH and OpenSSL keys, apparently indicating that specifying the raw key’s use isn’t always necessary...

Kent