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

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Aug 21, 2017 at 11:09:27PM +0000, Kent Watsen wrote:
> Hi Juergen,
> 
> 
> >> >> For the ssh-client-server draft 
> >> >> ===============================
> >> >> 
> >> >> > - The overall setup is somewhat complicated but I do understand why.
> >> >> >  Obviously, the attempts to make things generic come with a price
> >> >> >  since many YANG definitions interact with other definitions that
> >> >> >  need to be understood. And while the end result is that we can
> >> >> >  configure SSH clients and servers for NETCONF, we only have a
> >> >> >  collection of groupings to configure a regular SSH client or
> >> >> >  server. Should we have an instantiation of these groupings for
> >> >> >  regular SSH clients and servers as well?
> >> >> 
> >> >> I'm hoping to not have to do this, but can see that there might be
> >> >> value in doing so in order to further proof-out the model.  To do
> >> >> this right would entail something like what Clyde did for the syslog
> >> >> model in evaluating many vendor's implementations to find a common
> >> >> denominator.  I can imagine the WG undertaking such an analysis for
> >> >> an SSH-server container, but I fail to see how it could be done for
> >> >> an SSH-client container.  Also, when thinking about symmetry to the
> >> >> tls-client-server draft, note that the idea of creating a container
> >> >> for a TLS-server doesn't make sense (which one, right?)
> >> >
> >> > Yes, for TLS there is no a common standalone TLS service. For SSH,
> >> > there is however since SSH was created for a specific service (while
> >> > TLS was created as a plugin to secure another existing service).
> >> >
> >> > The client question we discussed before and I tend to agree that
> >> > usually a client you configure is embedded into some other
> >> > functionality that likely has its own configuration, so having a
> >> > grouping is OK.
> >> >
> >> > But since there are SSH servers out there, do we expect this ID to
> >> > just provide groupings and we hope that some other module later comes
> >> > along and picks up the groupings and turns them into a more general
> >> > SSH server configuration model?
> >> 
> >> This is my hope, so as to limit the scope of this document.
> >> 
> >> 
> >> > 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'.
 
> Back to if the implementation strategy can affects 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?

> 
> >> >> 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. 
 
> >
> > 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 we it be helpful to complex TLS 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>