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

[Paul Wouters <[e-mail]>]

On Fri, Mar 1, 2024 at 6:20 PM Kent Watsen <[e-mail]> wrote:

>
> 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.
>

It does, thanks for the extra work!


>
> 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.
>

Yes.


> 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.
>

Yes.


>
> 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.
>

Yes.


> 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?
>

No. The server timeout is for when a client's TCP conection is still
working and/or doing keepalives, but the application level user is doing
nothing.
eg of the "ssh user" is idle, not just the "tcp session".

I thought if at this level you would have the ssh keepalives for the
client's behind NAT, this might also be the level for the server to kick
out idle clients.
Consider it a non-blocking comment though on whether you think it should be
added or not.


> 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.
>

Thanks


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

So I believe the SSH protocol uses "namespaces" for some algorithms. If
there is no "@" symbol it means the IETF / IANA
namespace. But OpenSSH has its own namespace with its own entries. That's
why I thought it might be useful to add these
to ensure people are aware that this is valid syntax as well.

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...

The "mac" is belongs to the algorithms and is not related to "mac
addresses".

Eg AES-CBC-SHA2, the "SHA2" part is the integrity aka mac.
For AEAD algorithms such as AES-GCM and CHACHA-POLY, the integrity/mac part
is integral to the encryption algorithm, so it has no separate "mac".
So my question was, when using an AEAD, what is expected for the <mac>
field? Should it be empty? Should it be absent? Should it contain a value
"none"?
So I was wondering if guidance should be given here about what is
valid/allowed and what is not.

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.
>

Thanks.


>
>
> ----------------------------------------------------------------------
> 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.
>

It is but the text "secret" is not a TYPE but a VALUE. Eg you are using a
secret of "secret". I wasn't sure if that was very clear. That also does
not make it
entirely clear of the secret is cleartext or some other format (without
reading 7317). If you used "ExampleSecret", that would be more clear.


>
> 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 was not talking about the node name as far as I know ?


>
> 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.
>

I'll wait with updating my ballot until we understood each other regarding
the "@" namespace and <mac> topics.

Paul

Paul