Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-trust-anchors-23: (with DISCUSS and COMMENT)

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for your valuable comments.
Please find responses below.

Kent


> On Jan 30, 2024, at 11:47 AM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-trust-anchors-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** Section 5.1
>   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.
> 
> Similar feedback to draft-ietf-netconf-keystore.  If this recommendation is NOT
> followed how would this expectation be satisfied?  Shouldn't ensuring that the
> truststore is protected be mandatory?

Yes, one might think so.

Unlike my response for Keystore, stating that the API is the Security-boundary doesn’t relieve the server from preventing unauthorized modifications when at rest.

OLD: it is RECOMMENDED that implementations 
NEW: server implementations MUST


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Yoav Nir for the SECDIR review.
> 
> ** Clarifying that certificates are actually certificate chains in the node
> descriptions. YANG.  typedef central-certificate-ref
> 
>       description
>         "This typedef defines a reference to a specific certificate
>          in a certificate bag in the central truststore. This typedef
>          requires that there exist a sibling 'leaf' node called
>          'certificate-bag' that SHOULD have the typedef
>          'central-certificate-bag-ref'.";

It is true that each “certificate” YANG container has a descendant node “cert-data” that is a CMS, which means  the “certificate” (singular) could actually be a chain certs (plural), which leads to some confusion.

However, renaming the YANG node from “certificate” to, e.g., “certificate-chain” would be correct sometimes and incorrect other times.  

I don’t have a good answer for this.



> YANG.  list certificate
>               description
>                 "An arbitrary name for this certificate.";

OLD:             "A trust anchor certificate.";
NEW:            "A trust anchor certificate or chain of certificates.";


> 
> ** YANG.  Typo. s/inlucging/including/

Fixed - thanks!


> ** YANG.  list certificate-bag
>             "A bag of certificates.  Each bag of certificates SHOULD
>              be for a specific purpose.  For instance, one bag could
>              be used to authenticate a specific set of servers, while
>              another could be used to authenticate a specific set of
>              clients.";
> 
> Since normative language is used here, can additional guidance be provided on
> qualifying “specific purpose”.  For example, can one put different applications
> for the same server in the same bag?  

Technically possible, yes.


> What is the consequence of incorrectly binning the certificate chains?

A misconfiguration, possibly leading to trusting something in an undesirable context.


> More generally, I’m wondering about the
> significance of where certificates are binned.  Because of natural language
> describing the purpose of these bags, I don’t see an obvious, interoperable,
> general purpose way to automatically parse this structure to know which
> certificate to use for a server beyond checking subjectAltNames in the
> certificate against a domain name (which precludes the need to even organize
> these certificates into bins beyond readability).

Each bag has a “name” and “description” fields.  From https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-23#section-2.2.1:

    <certificate-bag>
      <name>trusted-server-ca-certs</name>
      <description>
        Trust anchors (i.e. CA certs) used to authenticate server
        certificates.  A server certificate is authenticated if its
        end-entity certificate has a chain of trust to one of these
        certificates.
      </description>

So it seems very easy for clients to know a bag’s purpose without having to look at, e.g., the SAN.   
Does this resolve your comment?


> ** Section 3.
>   Built-in bags of trust anchors and/or specific trust anchors, that
>   are referenced by configuration (e.g., a "leafref"), MUST be present
>   in a datastore in order for the datastore to be valid.
> 
>   Built-in bags and/or their trust anchors MAY be copied into other
>   parts of the configuration but, by doing so, they lose their
>   association to the built-in entries and any assurances afforded by
>   knowing they are/were built-in.
> 
> As with netconf-keystore, I’m having trouble with the guidance for built-in
> keys, more specifically, the guidance around a data-store.
> 
> -- If something is “built-in”, isn’t it by definition in some kind of datastore
> already?  Are there now multiple data stores?

Built-in certs (and keys) are expected to be in the “system” datastore, where <system> is defined in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config. 

There are multiple datastores (https://datatracker.ietf.org/doc/html/rfc8342).  Importantly, the “configuration” datastores include <startup>, <running>, and <candidate>. 


> -- What does “copying” into a different part of the configuration mean?  Aren’t
> we talking about an XML file?  Does this imply keys are moved from one
> data-store (the built-in?) to another one (e.g., a OS or application specific
> one)?

The NETMOD WG had a Virtual Interim last week.  Point #2 in the minutes [1] regards if these datastores MUST be complete, or is it okay for some referenced system-defined objects (including built-in certs and keys) to be not copied into, e.g., the <running> datastore.  [1] https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/

That said, Rob Wilton, in his Ops AD review, was very keen that this draft not reproduce any text better found in the "system-config” draft mentioned above (to be a DRY as possible).  Looking at the paragraphs you quoted, I concede that I didn’t remove enough.  I have now removed both of those paragraphs, plus the next paragraph, and the artwork that follows.  Stated another way, I removed everything to end of the section.



> ** Section 4.3
>   None of the readable data nodes defined in this YANG module are
>   considered sensitive or vulnerable in network environments.  The NACM
>   "default-deny-all" extension has not been set for any data nodes
>   defined in this module.
> 
> Doesn’t read-access to this module provide insight into which other
> resources/applications/servers this particular server communicates with by
> virtue of having their end-entity certificates or SSH keys?  Wouldn’t this
> provide an attacker insight into potential targeting?  or business
> relationships?

Good point.

Hmmm, but can you clarify, is the concern limited to just the “cert-data” node (i.e., the CMS), or does it include also, e.g., the bag’s “name” and “description” nodes too?



Thanks again!
Kent