Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Apr 2014 21:58:03 +0000

I was going to ask about updates needed for 5539bis, when I remembered
this unfinished thread...

Kent

On 3/21/14 3:46 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>On Tue, Mar 18, 2014 at 10:28:12PM +0000, Kent Watsen wrote:
>> 
>> 
>> >No. First, there needs to be an interoperable procedure for a
>> >standard. Second, this is not about how to extract an identity or
>> >something like that but how to check that the identity presented is an
>> >expected identity, means it is trust worthy and not an attempt to fool
>> >the NETCONF client.
>> 
>> There is no foolery here, this is how it works.  When using a TLS-client
>> library, it undoubtedly provides a callback that will be executed for
>>the
>> app to state whether the server's certificate can be trusted.  In
>>addition
>> to the certificate itself (and any intermediate certs that may also have
>> been provided), the callback will likely also a handle to a "connection"
>> object of some sort, from which the application can learn the peer's
>> source IP address.  So that's it, the app has an IP-address, a
>>certificate
>> (+intermediate certs), and its preconfigured state.
>
>So what is this preconfigured state? How is the decision been taken?
>All implementation specific? So I need to study the vendors handbooks
>to figure out how setup things?

The preconfigured state being what certificates and/or information inside
of certificates (e.g., unique identifiers) it trusts.  It's
implementation-specific only up to the application's local policy.  But
for each part of certificate path-verification it implements, I believe
that it is unambiguous (RFC3280, section 6)

>> >>You are probably familiar with SSH host-keys like "id_rsa.pub" and
>> >> "id_dsa.pub".
>> >
>> >These typically are _not_ host keys.
>> 
>> You're right, I meant ssh_host_rsa_key.pub and ssh_host_dsa_key.pub.
>> 
>> 
>> 
>> >> When using OpenSSH, the sshd_config file can contain one of
>> >> more "HostKey" entries, an ordered list.  The ordering is important
>>to
>> >>the
>> >> SSH protocol, not just the OpenSSH implementation.  The configuration
>> >> described in the netconf server configuration draft mentioned above
>>maps
>> >> directly onto this concept, enabling it to be configurable per NMS.
>> >
>> >If this is the thing you want to solve, this first of needs to be
>> >described clearly. But then I am not sure why this needs to be solved.
>> >My SSH servers all have keys of different types, e.g.,
>> >
>> >HostKey /etc/ssh/ssh_host_rsa_key
>> >HostKey /etc/ssh/ssh_host_dsa_key
>> >
>> >and somehow clients manage to use the servers without me configuring
>> >things. Are we moving into general SSH server configuration territory?
>> >Should these details be handled by a generic SSH server configuration
>> >data model, I mean is this essential for every NETCONF over SSH call
>> >home implementation?
>> 
>> It is SSH-server configuration, yes, but not for the generic server
>> listening on port 22 and also not for any generic configuration option.
>> We just need enough to support the netconf-server config model draft
>>(keep
>> alive interval, keep alive count max, etc.).   Being able to configure
>> which SSH HostKeys are presented is equivalent to being able to
>>configure
>> which TLS server-certificate the device should present, if there is more
>> than one, which is completely possible.
>
>This is inconsistent. We have no configuration model for all these
>things for the regular case - why do we now go ahead and define some
>of this for the call home case?

This is Tom Petch's point from just this morning, where I wrote back:

   "True, using PKI-based keys (e.g., X.509) would help scale the
    rolling out of deployments, regardless if TLS or SSH, and
    regardless if "normal" or reversed.  So do we put something
    about this into all three documents, or remove it from all
    three documents, citing that key-distribution is a known problem?

What do you think?

Thanks,
Kent