Subject: Re: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt

From: Alan Luchuk <[email-masked]>
Date: Mon, 31 Mar 2014 11:37:22 -0400 (EDT)

Hi Kent,

>Awesome comments - thanks!

You're welcome!

>>Section 2.1, Page 3, Second Paragraph:  (wording)
>>-------------------------------------------------
>>
>>The second paragraph seems vague.  Would something along the lines of
>>the following text be clearer and/or more specific?
>
>I forwarded this comment to Steve Hanna, who wrote the Applicability
>Statement.  At first I was just going to ask if he was OK with the
>proposed text, but then I started thinking that I didn't agree with it.
>That is, I think that the SSH protocol does require mutual authentication
>and that NETCONF's requirement that it be possible to derive a "username"
>from the transport doesn't change that.  I'm still OK limiting Reverse SSH
>to just NETCONF, but I want the reason to be accurate.  I'm now waiting
>for a response from Steve on this.

The actual specification for Reverse SSH is not affected by the explanation,
so I'm fine with however this is stated, including the original text.  That
said, a little more specific explanation might be more technically satisfying.

>
>
>>Section 4, Page 4:  (wording)
>>-----------------------------
>>
>>The current text reads:
>>
>>   o  The NETCONF server initiates a TCP connection to the NETCONF
>>      client on the IANA-assigned Reverse SSH port YYYY.
>>
>>   o  The TCP connection is accepted and a TCP session is established.
>
>
>I'm not sure about this change since these bullet-points are preceded by
>the line "From the NETCONF server's perspective:".  The intent is to only
>explain the NETCONF-server's perspective, and to let the next section
>provide the client's perspective.   Currently, neither section references
>the remote peer, so that its text remains squarely focused on its side of
>the connection.  What do you think?

Good point.  Keep the text you propose above.

>
>>Section 5, Page 5, First Paragraph:  (wording)
>>----------------------------------------------
>>
>>The current text reads:
>>
>>   "When the management system accepts a new incoming connection, it
>>    needs to authenticate the remote peer.  Ultimately, this entails
>>    identifying the peer and verifying its SSH host key.
>>
>>    Due to Reverse SSH having the network element initiate the TCP
>>    connection,"
>
>
>I changed the wording to be more clear, but did it another way, please let
>me know if you think it's OK!

Will do.

>>Section 5, Page 6, First Paragraph:  (clarification)
>>----------------------------------------------------
>>
>>The current text reads:
>>
>>   "However, configuring distinct host keys on the management system
>>   doesn't scale well, which is an important consideration to a network
>>   management system.  A more scalable strategy is to have the network
>>   element's host key signed by a common trusted key, such as a
>>   certificate authority.  Thus, the mangement system only needs to
>>   trust a single public key, which vouches for the authenticity of the
>>   various network element public keys."
>>
>>Please help me understand this.  The way this paragraph is written, it
>>is not clear to me why "signing each network element's host key with a
>>common trusted key" scales better than "configuring distinct host keys
>>on the management system".
>>
>>In either of these two situations, it seems like an administrator must
>>do work for each network element.  In one case, it is configuring host
>>keys, in another, it is signing each network element's host key.  If
>>anything, it seems like signing a host key for each network element
>>requires _more_ work for each network element, so it seems like this
>>would scale less well.
>>
>>What am I missing here?
>
>
>Very good question.  Of course it comes down to how the device's "entity
>certificates", as they are called, is distributed.  In the best case, as
>described in the zero-touch draft, the device would ship from factory with
>a built-in entity-certificate, signed by a trust-chain to its vendor's
>well-known trust anchor.  In this case, there is no additional effort
>needed, the management system only needs to trust the vendor's certificate
>for its well-known trust anchor.  For cases where the device doesn't ship
>from factory with an entity-certificate, introducing PKI is still
>advantageous as it decouples the management-system from direct
>involvement, such that it could be outsourced to some 3rd-party.  Makes
>sense?  What update would you like to see in the draft?

Thanks!  That does clear it up, and it makes sense.  Basically, the device
manufacturer does more work so the management system adminstrator has less
work.  That's what I missed from the original text.

How about something like:

   "However, configuring distinct host keys on the management system
   doesn't scale well, which is an important consideration to a network
   management system.  A more scalable strategy for the management system
   is to have the network element's manufacturer sign the network element's 
   host key with a common trusted key, such as a certificate authority.  
   Then, when the network element is deployed, the management system only 
   needs to trust a single public key, which vouches for the authenticity 
   of the various network element host keys."

This text tries to preserve as much of the original text as possible,
although I'm not sure it is as clear as it could be.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------