Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-ssh-client-server-38: (with DISCUSS and COMMENT)

[Kent Watsen <[e-mail]>]

Hi Roman,

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

Kent // author


> On Feb 27, 2024, at 2:46 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-ssh-client-server-38: 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-ssh-client-server/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I struggle to understand when it is assumed that the security considerations of
> the imported modules apply, and when they will be surfaced as issues in the
> module that is using them.  With that confusion in mind:

I empathize with your confusion  ;)


> ** Section 5.7.  The ietf-ssh-server module is described as having no readable
> data nodes that are sensitive.  Consider the example in Section 4.2.  Wouldn’t
> enumerating the list of users for which there is a client-authentication
> configuration be sensitive?

Per my other response just moments ago wrt the tcp-client-server draft, I’m also
struggling with determining where to draw the line.  My possibly wrong thinking
is that the nam:default-deny-all flag is reserved for truly sensitive (effectively
secret) information that normal authenticated clients should never have access
to.  For instance, cleartext passwords and cleartext private-keys.

In my other email, I suggest that the problem might be that NACM “fails open”
rather than “fail close”.   I suggest that it might be better if all YANG nodes in
all YANG modules were “nacm:default-deny-all”, forcing explicit authorizations
to be made by operators.

IDK how to "draw the line”, but consistent with the thought in the previous
paragraph, perhaps an easy fix is to put “nacm:default-deny-all” on most
all nodes, in all nine drafts, since the entire suite of drafts are heavily
Security-oriented.  Thoughts?  Too much?


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 5.1, 5.2, 5.3 and 5.4?
>   The protocol-accessible read-only node for the algorithms supported
>   by a server is mildly sensitive, but not to the extent that special
>   NACM annotations are needed to prevent read-access to regular
>   authenticated administrators.
> 
> What is meant by “mildly sensitive” to call it out?

Good catch, “mildly” is too informal for an RFC.

That said, I must first apologize as a recent change moved the
“supported-algorithms” node from the IANA-maintained modules to
the "ietf-ssh-common" module.  This is to say, these four paragraphs
should've been moved to a single paragraph in Section 5.5 entitled
"Considerations for the "ietf-ssh-common" YANG Module”.

I have deleted these four paragraphs (and a similar one in the
tls-client-server draft) in my local copy.

Now the question is, what to add to Section 5.5?

Let me first explain my thinking and then perhaps you can provide 
guidance?

At stake is where an authenticated client can see what SSH algorithms
a server implements.  Knowing this information alone isn’t very useful,
as it only aids in generating private keys and/or setting configuration,
which has the “nacm:default-deny-write” flag set.  Furthermore, what
algorithms a server supports is accessible to *unauthenticated” users
when trying to establish an SSH (or TLS) connection to the server, as
the algorithms are typically present in the handshake.

For right now, I’m not adding any paragraph to Section 5.5, relying on
the existing paragraph:

	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.

That said, per our ongoing DISCUSS above and elsewhere, I’m happy
to convert all these to nacm:default-deny-all if you think it’s best.


> ** Section 5.5.  Does this section need a disclaimer that there are groupings
> that importing modules need to fully consider in their own Security
> Considerations?  Same as in draft-ietf-netconf-tcp-client-server?

Yes it does - added  (thanks!)


> ** Appendix A.  Please provide an informative reference to Python for this
> non-normative (?) section.

Done!
  - Added "This section is not Normative.” as the first line in the section.
  - Added an `eref` to "https://www.python.org”.
  - I did this to the tis-client-server draft also.

As an aside, it is unclear if the Python script should be removed by the RFC Editor.   I seems that IANA would be the only reader of the published document that would care about the script...

PS: already there is an “Note to Editor” at the top of the document to remove the four generated YANG modules, as they are only present to aid the IETF-review process and, per rfc8407bis, SHOULD NOT be in the published document.


Kent