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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "t.petch" <[e-mail]>; "Bert Wijnen (IETF)"
<[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 12, 2014 5:37 PM

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.


<tp>
Kent,

No, we are still not meeting anywhere in the middle.

It seems to me that you are proposing that all devices share the same
private key and so the same public key (in which case the choice of CA
seems irrelevant).

AFAICT, anything else requires that the NMS is configured with some
identifier for each and every device, which could be the public key,
could be something that appears in the subjectAltName, could be the IP
address (although I think not for 'call home') etc.

I see you describing this per device configuration as 'does not scale'
but I see no other way.

As
http://www.rfc-editor.org/rfc/rfc5592.txt
says "this requires the client
   to know the host's public key a priori and to verify that the correct
   key is being used."
which is the sort of thing I would expect to see, in the absence of
X.509 certificates.  With certificates, then you know the subjectAltName
a priori.  Either way, you configure the NMS for every device.

Tom Petch

>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