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

[Kent Watsen <[e-mail]>]

Hi Paul,


> On Mar 2, 2024, at 1:38 PM, Paul Wouters <[e-mail]> wrote:
> 
> 
> On Fri, Mar 1, 2024 at 6:20 PM Kent Watsen <[e-mail] <mailto:[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!

Actually, I just realized that the above text doesn’t properly make room for future SSH/QUIC .  Fixing it (in the tls-client-server draft too):

NEW:
	The groupings defined in this document are expected to be used in
	conjunction with the groupings defined in an underlying transport-level
	module, such as the groupings defined in [I-D.ietf-netconf-tcp-client-server].
	The transport-level data model enables the configuration of transport-level
	values such as remote address, remote port, local address, and local port.

Even better now?



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

I made the document more QUIC-friendly above.


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

Ah, now I understand, this is on the SSH-server side of the connection.  In OpenSSH, this is configured in sshd_config using the ClientAliveInterval and ClientAliveCountMax.

Looking at the "ssh-server-grouping” here (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-38#section-4.1.2.1) you will find the "max-wait” and "max-attempts” nodes (dig into YANG module for descriptions).  These YANG nodes respectively map onto ClientAliveInterval and ClientAliveCountMax settings in sshd_config.



>>> 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] <mailto:[e-mail]>,
>> [e-mail] <mailto:[e-mail]>,[e-mail] <mailto:[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] <mailto:[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 fixed the validator issue.  It was due to my `yanglint` install being out of date.



>> 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] <mailto:[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.

Oh, this?  https://www.rfc-editor.org/rfc/rfc4250.html#section-4.6.1

Now I understand...


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

Silly me, I had my wrong hat on  ;)

I understand now what you mean about the local names having the ‘@‘ character.

I fixed the YANG by creating new typedefs enabling the various algorithm values to either be from the IANA-defined registry or be a local name (containing the ‘@‘ character.

I updated both examples in Section 2.2 to include the local names "[e-mail]" and "[e-mail]”.


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

Okay but, unless I’m mistaken, the guidance is clear (though possibly wrong).  The YANG says that the value must be one of the values from the underlying IANA registry (or a local name containing ‘@‘).  For reference, the “supported-algorithms” node lists all of the algs the SSH-server supports.

To this end, you are right that IANA's AEAD alg names do not encode a MAC algorithm (e.g., SHA2).  Using your language, the "<mac> field" could be said to be “empty" or “absent”.   I don’t see how this is handled in practice.  I checked RFC 5647 to no avail.

I think that the allowed values are well-defined.  How the AEAD algs set a MAC to use seems to be outside the scope of this document.  Agreed?


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

Changed examples to use the value "example-secret” instead.

Also changed in the http-client-server and restconf-client-server drafts.


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

Please ignore, I was confused about what you wanted before.



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

Have I provided sufficient response above?


> Paul

Thanks again!
Kent