Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt

[Kent Watsen <[e-mail]>]

Hi Tom,


>This is where we start to part company.  A host key is a host key, it is
>public, it is generated for me as part of a key pair for use in public
>key cryptography.  Of itself, it conveys nothing, no verification, no
>validation, no identification.
>
>It only acquires value when it can be tied into an identity or
>identifier, which X.509 certificates do.  Or it can preconfigured into
>the NMS (the key or a fingerprint thereof) but is the act of configuring
>that gives the key some value, there is nothing inherent in the key.


RFC 4251 section 4.1 on "Host Keys" extends the definition to include
certificates too. 



>You say in the I-D that this does not scale, but that is true of
>(almost) everything.  If you use X.509 certificates, then they bind the
>key to an identity; guess what, that identity has to be configured into
>the NMS, so if configuring raw keys does not scale then neither do X.509
>certificates:-(

Yes, the NMS needs to be programed with the identity of the CA, but that
one CA can vouch for any number of devices.   This *is* scalable, from the
NMS's POV.   What is potentially not scalable, is the need to provision
each device with a signed certificate, as the naïve solution would again
be per-device, though it has the up-side that the certificate-provisioning
could be delegated to a 3rd-party, leveraging PKI to its fullest.
However, any solution that needs the device to be "touched" before being
put into commission is not ideal.  The  only no-touch solution I know of
is for the device to already have a signed-certificate when released from
its manufacturer's factory.  This is the strategy is codified in the
zero-touch draft.



>The only thing that scales is Trust On First Use, which I think too
>flaky for us to recommend.  Manual acceptance when a key is first used
>is more secure, but, arguably, scales no better.

Agreed, TOFU is not ideal.



>We have been here before - look at RFC5592, which basically says
>'preconfigure host keys' to which I would now add 'or else use
>certificates', RFC6125 etc.
>
>So my section 5 (skating over PGP use) would be more like
>
>"When the management system accepts a new incoming TCP connection on the
>NETCONF over SSH Call Home port, it starts the SSH client protocol. As
>the SSH client, it MUST authenticate the SSH server, by both identifying
>the network element and verifying its SSH host key.
>
>When not using call home, the management system initiates the TCP
>connection and so may place some reliance on the fact that the device
>that responds is the one that it is configured to communicate with.
>With call home, the network element initiates the TCP connection and no
>reliance can be placed on the source IP address of the TCP connection.
>Identifying the remote peer by its source IP address, as recommended in
>[RFC6187] is NOT RECOMMENDED in the case of call home, unless the
>network takes steps to validate IP source addresses.
>
>The management system may be configured with the host keys of the
>network elements, or fingerprints thereof, and these MAY be used as an
>identifier.
>
>The management system MAY request manually verification of a host key or
>a fingerprint thereof the first time the network element connects, and
>any time the host key changes thereafter.
>
>Digital certificates, such as those in X.509 version 3 (X.509v3) bind a
>public key to a digital identity [RFC5280] and are used in many
>environments for identity management.  This approach is discussed in
>more detail in [5539bis]; this approach is RECOMMENDED."


This text is almost the same as what is there now.  One thing different is
I don't see the word "scale" anymore.   So you want 5539bis to say PKI is
scalable and hence particularly suitable for NMS and then have this draft
reference it for that fact?   You didn't provide text for 5539bis, so I'm
just guessing, is there anything else?


Thanks,
Kent