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: Wednesday, May 14, 2014 10:30 PM

Hi Tom,


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

On this we can agree, but hopefully we'll get there soon  ;)

>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).

Of course not, each device must have unique private keys.  The
zero-touch
draft goes into more specifics regarding certificate construction and
use
of PKI.

>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.

The zero-touch draft touches on this as well:

<tp>

So what:-)  Perhaps we are not agreeing because you have zero touch in
mind, whereas I expect certificates to be used without zero touch (as
they long have been with TLS).  I expect this I-D to make sense when
taken with its Normative references and, for me, at present, it does
not.

If you have 1000 devices, then the NMS needs configuring with 1000
identifiers, and if that does not scale for host keys, then I do not see
it scaling for any other identifier, be it the subjectAlternateName in a
certificate or anything else, so for me, the references to 'does not
scale' do not make sense.  There is no magic short cut to configuring
the NMS once for 1000 devices, unless they share some property such as a
private key.

Likewise, if the identifier is embedded in the host key by some means,
you still have 1000 identifiers to configure in the NMS

I do not think it enough to leave it up to implementations.  We should
recommend something that is secure, and do it not just because a
Security AD says so.  My experience is that Security ADs usually ask for
too much but equally, most WGs start out with too little and for me at
present, we are too close to the latter.

Tom Petch



Section 3.5:

   The NMS SHOULD also validate that the unique identifier (e.g., serial
   number), within the "Common Name" field of the device's X.509
   certificate, is an identity that the NMS is expecting, and not
   another device having the same device type.  In order for the NMS to
   know the unique identifiers for devices shipped directly to their
   destinations, it may be necessary for the device manufacturer to
   provide the unique identifiers along with other shipping or billing
   information.  This draft not specify a format for this information
   exchange.

Section 4.1:

   The unique identifier MUST be something that is both known to the
   device and easily tracked through labels affixed to the device as
   well as the box it is packaged in.  A device's serial number is
   commonly treated this way and would be suitable for this purpose.


I guess my point is that we agree on how the solution can scale.  The
reverse-ssh draft leaves it up to deployments to decide what to do,
while
the zero-touch draft specifies a specific solution that satisfies all
its
particular use-cases.


Thanks,
Kent