Subject: Re: [Netconf] review of draft-ietf-netconf-ssh-client-server-03 and draft-ietf-netconf-tls-client-server-03

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Oct 2017 20:24:59 +0000

In preparation for posting an update to this draft (to resolve most of
the validation issues caught by Benoit's tools), I reviewed this entire 
thread again.  

First, it looks like the fork in the thread with Gary is still open
(Gary, can you see about closing out these issues?)   Here are the
topics being discussed there:
  - add a config false list of identities in ietf-ssh-common? 
     - rather than moving them to an iana-* module...
  - add a typedef to ietf-keystore that wraps the leafrefs to 
    keystore?
  - SNI/virtual-hosting (this is picked up below as well)

Continuing with this discussion:

>> >> > My understanding is that NC implementations actually come in different
>> >> > forms, some simply running behind a regular SSH server while others
>> >> > come with their own integrated SSH server. Does this affect the data
>> >> > model?
>> >> 
>> >> I think JUNOS is an example where the NC server runs "behind an SSH
>> >> server", but it's not really "behind" so much as a fork/exec of an
>> >> sshd process running the "netconf" subsystem (i.e., the NC server).
>> >> Is this what you meant?
>> >> 
>> >> Regardless, I don't see a need to change either the ietf-netconf-server
>> >> or ietf-ssh-server data models to support either the fork/exec or
>> >> link-to-library implementation strategies.  Do you?
>> >
>> > Well, if your server is running as a subsystem of your regular SSH
>> > daemon, then I think your SSH daemon configuration and your NETCONF
>> > specific SSH configuration are essentially the same, no? Or more
>> > precisely, you have an SSH daemon configuration plus a statement that
>> > enables NETCONF as a subsystem, but you do not have a NETCONF specific
>> > SSH configuration.
>> 
>> Not exactly.  There's SSH listening on port 22 and then there is SSH 
>> listening on port 830.  When listening on 830, it can be a separate 
>> instance of `sshd` and given unique startup parameters (e.g., the 
>> sshd_config file).  It is not expected that this configuration 
>> (ietf-netconf-server) would ever influence the SSH listening on
>> port 22.
> 
> So are you running a separate SSH server just for NETCONF or not? I am
> not asking about 'it _can_ be given unique parameters'.

Yes, sshd running on port 22 and sshd running on port 830 can be completely
different instances of sshd.  The can even be different executables, maybe
port 830 is listened to by a Ruby-based application...

>> Back to if the implementation strategy can affect the data model, my 
>> assertion is that the startup parameters are equally applicable, whether
>> using the fork/exec (e.g., instances of `sshd`) or the link-to-library 
>> (e.g., a python script), and therefore I don't think the implementation
>> strategy affects the data model.
>
> The question is whether there is a separate SSH daemon for NETCONF or
> NETCONF is just hooked up the SSH daemon also used for other services.
> I think this does make a difference, no?

Each NETCONF server implementation is free to choose their SSH strategy.
But this is why the ietf-ssh-* modules have been careful to just focus on
the lowest common denominator and, specifically, not be openssl-specific.

>> >> >> This sounds a lot like what was discussed before about configuring
>> >> >> NC/RC clients to authentication to call-home connections.  We decided
>> >> >> to just support a single set of auth params that would be used for all
>> >> >> servers (and not define a server-id to client-auth mapping).  So, this
>> >> >> grouping may not work well in some examples.  Is it okay?
>> >> >
>> >> > Perhaps not supporting SNI is sufficient for network management
>> >> > purposes but then also pretty clearly the TLS groupings are not
>> >> > generally usable.
>> >> 
>> >> Thinking about this some more, it seems my previous response
>> >> wasn't on target.  This isn't about what auth-credentials the
>> >> client passes, so much as how the client indicates the server
>> >> it wants to connect to in its client hello message.  It 
>> >> seems like something to configure SNI should be added to 
>> >> ietf-tls-client, how about this?
>> >> 
>> >>   +-- server-name-indication
>> >>     +-- server-name* [name-type]
>> >>       +-- name-type  enumeration (e.g., 'hostname')
>> >>       +-- name-value anydata     (e.g., foobar.example.com)      
>> >> 
>> 
>> Second guessing myself here, does this really need to be configuration
>> or is the client-side of SNI just a function of how the code works?
>
> It is the server side that matters I think. 

According to https://tools.ietf.org/html/rfc6066#section-3, the client
is sending this data to the server.  My original idea was that this
needed to be client-side configuration.  But, as I second-guessed
myself, I'm now thinking that the client might do this automatically.
For instance, `wget https://example.com` may very well cause the client
to send SNI info in the TLS handshake, even though it wasn't configured.

>> > Well, the TLS spec text does not help me to configure this such that I
>> > get the right certificate selected for the SNI presented...
>> 
>> Peaking at TLS 1.3, draft-ietf-tls-tls13-21#section-4.4.2.2 says:
>> 
>>    -  The "server_name" and "certificate_authorities" extensions
>>       [RFC6066] are used to *guide certificate selection*.
>> 
>> and in S4.2.4 it says:
>> 
>>    The "trusted_ca_keys" extension, which serves a similar purpose
>>    [RFC6066], but is more complicated, is not used in TLS 1.3 (although
>>    it may appear in ClientHello messages from clients which are offering
>>    prior versions of TLS).
>> 
>> So, there's at least 3 different ways that the server can go about
>> selecting which certificates it sends.  To me, this again seems like
>> something maybe the server's code does internally - e.g., it sifts
>> through all the certs it has (i.e. list certificate in the YANG model),
>> sending the subset matching protocol-level criteria.  Do you know?
>> 
>> Peaking at NGINX config, it seems to have a config like:
>> 
>>   +--- server* [ <not sure what the key might be> ]
>>     +--- listen inet:port    // 443
>>     +--- server_name string  // example.com
>>     +--- root        string  // /usr/share/nginx/www
>>     +--- ssl         Boolean // on
>>     +--- ssl_certificate     // /etc/nginx/ssl/example.org/server.crt;
>>     +--- ssl_certificate_key // /etc/nginx/ssl/example.org/server.key;
>> 
>> Note that the TLS-part of the config has been splayed across the
>> app-specific config.  By contrast, the groupings we have now are more
>> for a single SSL host (not virtual hosting).  We could add 'sni-to-name'
>> mapping structures, but would it be helpful to complex TLS based apps
>> like NGINX?
>
> I think the key here is server_name as this allows nginx to multiplex
> incoming connections to the "right" list instance, i.e., I can have
> multiple server configured to listen on the same port and the TLS SNI
> indication provides a hint which list instance is used and this
> implies the correct security parameters.

Yes, "server_name" would be the key for the server-side SNI lookup.  But
where are we going with this?  I think that we concluded that the current
groupings are more for a single SSL host and not amazingly useful to a
server that wants to do virtual hosting.  Is this a problem we need to
solve now?

PS: Gary also replied regarding the server-side of SNI.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 Oct 2017 22:25:09 +0000

Hi Juergen,

I just noticed this comment went unanswered before.  I don't feel
strongly about this, but 1) I would call it "ietf-ssh-groupings",
2) it will have a large impact on the structure of the draft (what
would the ToC be?), and 3) it definitely will break downstream
modules (as their imports will fail as the old names disappear).

Kent

On Thu, Aug 03, 2017 at 01:26:19PM +0200, Juergen Schoenwaelder wrote:
> Hi,
> 
> I took a look at both documents today and I am attaching my two
> reviews.  Since the structure of the documents is quite similar, the
> review comments are also quite similar.
>

One more thing:

Since ietf-ssh-client, ietf-ssh-server, ietf-ssh-common essentially
define only groupings (one grouping per module) and identities, I
suggest to merge these definitions into a single module, say
ietf-ssh-common. This way, the module name ietf-ssh-server can be used
(later) to define an instantiation of the groupings for a standalone
SSH server.

I would suggest the same for the ietf-tls-* modules (even though there
is not a common standalone TLS server).

Since these modules will have conformance-type 'import' in YANG
library, I do not really see what the benfit of splitting things
into multiple modules. What you implement is defined by the modules
using the groupings.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Oct 2017 08:16:37 +0200

> strongly about this, but 1) I would call it "ietf-ssh-groupings",

Because you are sure you will never put typedefs or identity
definition there?

> would the ToC be?), and

The ToC falls out of the content.

> 3) it definitely will break downstream modules (as their imports
> will fail as the old names disappear).

Nothing got published so far. I think the number of IDs affected are
close to the number of IDs dealing with NC configuration, all in the
hand of one editor.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 Oct 2017 18:14:20 +0000

Hi Juergen,

> Because you are sure you will never put typedefs or identity

Not to say there wouldn't be, but that the reason for importing 
the module would be for the groupings.   BTW, I want to update my 
previous comment, I now have a preference (see bottom).

> The ToC falls out of the content.

The question was/is how to structure the draft, it's not obvious.
It would great if you could provide an example ToC for what you 
had in mind.

> close to the number of IDs dealing with NC configuration, all in the

Not true, if you saw Benoit's recent dependency graph, there's ~6 drafts
authored by others that depend on ietf-tls-server or ietf-tls-client.

That said, I'm beginning to think that this is not a good idea.  The 
impact to the drafts (four of them) is enormous, and all just so that
some future definition can use the module name "ietf-ssh-server".  How
about instead, at that time, a bis of this document is produced to add
in the missing "ieft-ssh-server" container?  That produces an equally
good result (better, I think) and is much less work now.

K.  // contributor