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

[Kent Watsen <[e-mail]>]

Hi Paul,

Thank you for you comments.
Please find responses below.

Kent // author


> On Feb 28, 2024, at 3:11 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters 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:
> ----------------------------------------------------------------------
> 
> Thanks for the document. I have a few DISCUSS items that hopefully are pretty
> minor to resolve.
> 
> 1) client options?
> 
> The ssh client allows to set the source IP. Should that not be exposed here to
> support picking the right source IP on multihomed nodes? Similarly, this does
> not seem to support ports != 22 ? And seeing people are starting to experiment
> with ssh over QUIC or HTTP/3, perhaps a protocol should be added as well? Is
> compression an option that should be exposed here?

For your four question marks:

1) "The ssh client allows to set the source IP. Should that not be exposed here to support picking the right source IP on multihomed nodes?”

Yes, TCP-level source address/port can be configured, assuming a higher-level “stack” includes the "ietf-tcp-client" grouping.  Here’s an example [1] of the "tcp-client-grouping" configuring both a local address and a local port.  With regards to "multihomed nodes”, or VRFs in general, there was a decision a long time back to have those configurations be augmented into the YANG data model.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-22#section-3.2

To be constructive, I have added the following to the Introduction section, in both this draft and also the tls-client-server draft:

	The groupings defined in this document are expected to be used in
	conjuction with the groupings defined in <xref target="I-D.ietf-netconf-tcp-client-server"/>.
	For instance, to configure the remote address/port and local address/port.

Hopefully this clears your DISCUSS on this point.


2) "Similarly, this does not seem to support ports != 22 ?”

This document cannot, in its current form, specify any default port values.  Fixing this would entail defining a new grouping called, e.g., “ssh-client-stack-grouping” grouping, much like exemplified in the netconf-client-server draft here: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server#section-3.2.  One can see that the "tcp-server-parameters” are independent of the "ssh-server-parameters”.  Makes sense?

Hopefully this clears your DISCUSS on this point.


3) "And seeing people are starting to experiment with ssh over QUIC or HTTP/3, perhaps a protocol should be added as well?”

Support for SSH over QUIC can be added by a future-work augment statement into this YANG structure.  Does the document need to say this explicitly?

Hopefully this clears your DISCUSS on this point.


4) “Is compression an option that should be exposed here?”

The “03 - 04” change log entry says:

	Removed the compression algorithms as they are not
	commonly configurable in vendors' implementations.

The expectation is that higher-level modules will augment-in these details if needed.  

FWIW, the modules presented in this document are somewhat barebones, as far as configurable options go.  The focus is primarily on the crypto parts, letting application-layer YANG modules add (via YANG “augment” statements) what extra nodes needed.  Makes sense?

Hopefully this clears your DISCUSS on this point.



> 2) server options
> 
> I think the idle timeout might be a useful server option to expose here? It
> seems the best place for it instead of placing it in another ssh server module
> to include ?

Already there are “max-wait” and “max-attempts” nodes in the “ssh-client-grouping” here https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-38#section-3.1.2.1.  The “description” statement says:

	"An unresponsive SSH server is dropped after approximately max-wait * max-attempts seconds."

Doesn't this cover the concept of an “idle timeout” as well?  Idle timeout is the same as the drop time?


> 3) algorithms, names and IANA entries
> 
>        2.2. Example Usage
> 
> This uses older ctr/cbc algorrithms, why not use more modern examples?
> I'd recommend removing the cbc examples and including the well known AEAD
> ones instead? (see also the catch below)

I have remove all of the “cbs” examples.
I have added two AEAD examples.



> Note openssh uses names like  [e-mail],
> [e-mail],[e-mail] while the IANA registry uses
> names like AEAD_AES_128_GCM and AEAD_AES_256_GCM. How does this relates to
> names in the document, which uses "aead-aes-256-gcm" which is not an IANA
> value, but presumably points to AEAD_AES_256_GCM and [e-mail] ? I
> think some guidance or explanation about the valid value names here compared to
> IANA and OpenSSH would be useful. I believe the "@" ones are non-IETF namespaces

I made a mistake - the "aead-aes-256-gcm” entry has been removed.  

Concerningly, the YANG validator didn’t catch that it was an unknown value…grrr


> I would also include at least one "@" encryption name to ensure people know
> those are valid syntax as well. I do not know if AEAD_AES_256_GCM is the
> same as [e-mail]

I’m confused, where are these ‘@‘ variations defined?   They are not defined in the Encryption Algorithm Name registry here:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters-17.csv



> What should the <mac> field list for AEAD algorithms? Just be empty? Or
> a special "none" value? Or should the field be entirely omitted? Is there
> guidance needed here? (Sorry I am not a yang doctor)

I’m a retired YANG Doctor  ;)

Nowhere in the current suite of client-server drafts is there a configuration for Mac addresses.  If such configuration were to exist anywhere, it might be in the tcp-client-server draft, or maybe some new “ip-client-server” draft.  In any case, it is unclear how this is important...

Do the AEAD algorithms require a local MAC-address address to be configured?


> The value diffie-hellman-group-exchange-sha256 is a valid IANA registry
> name but points to a MAY entry. I would pick a MUST or SHOULD entry for
> examples, in this case diffie-hellman-group14-sha256. Similar, the
> example gss-group1-sha1-curve25519-sha256 is actually a SHOULD NOT
> implement entry. Similar the mac " really has an IANA
> entry of AEAD_AES_256_GCM.

I removed the "diffie-hellman-group-exchange-sha256” and "gss-group1-sha1-curve25519-sha25”, and "aead-aes-256-gcm” entries.

I added a AEAD_AES_256_GCM entry.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> C1) hashed-password ?
> 
> The example "$0$secret" uses the most unsafe option as example. "secret"
> is not a hash. It is cleartext based on RFC 7317 "crypt-hash". Maybe give
> an example with an actual hashed password as well? Maybe change "secret"
> to "cleartext-password" ?

RFC 7317 says:

          The '$0$' prefix signals that the value is clear text.  When
          such a value is received by the server, a hash value is
          calculated, and the string '$<id>$<salt>$' or
          $<id>$<parameter>$<salt>$ is prepended to the result.  This
          value is stored in the configuration data store.

So the example is correctly showing a valid input document.

I cannot rename to the node to “cleartext-password” as 1) that name
is being used already, for real cleartext passwords, and 2) the 
“hashed-password” field is defined as being polymorphic, i.e., 
having an expected implicit change if the $0$ prefix is received.

I hope you see now that this example is valid.


> Since RFC 7317 only defines crypt-hash 0,1,5 and 6 there is some
> ambiguity here for hashed passwords based on other algorithms. My
> crypt(5) man page also supports script, yescript, bcrypt, NT. But not
> argon. But I guess this is an issue for RFC 7317, and not this document.

Yes, that should be captured in a document update to RFC 7317.


Thanks again!
Kent