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

["Bert Wijnen (IETF)" <[e-mail]>]

om, is this still an issue with rev 5 of the reverse-ssh document?

Bert

On 01/05/14 11:58, t.petch wrote:
> Kent
>
> I commented earlier that I was uncertain about s.5 of reverse-ssh.  I
> think that it has not got public key use (SSH host key) quite right.
>
> If I were asked to describe the use of public keys, then I would
> identify three steps.
>
> 1) get hold of a public key
> 2) verify that the key is tied to the identity of the other party
> 3) get the other party to demonstrate possession of the private key
>
> At that level, it is irrelevant where the key comes from, X.509
> certificate, pre-configuration, Trust On First Use, etc.  What varies is
> step 2).
>
> I can see no difference between the use of certificates with ssh and
> with TLS.  And I think that certificates are naturally associated with
> TLS, and so the place to describe that is in 5539bis.  In which case, I
> would omit any description of it from the ssh I-D and just put in a
> reference to 5539bis I-D.  Currently, reverse-ssh does have some
> suggestions that are not in 5539bis but then they seem to me equally
> appropriate to the use of certificates with TLS and so I think that they
> should be in 5539bis.
>
> By contrast, other ways of verifying the key are more associated with
> ssh, in which case, they belong in reverse-ssh and 5539bis may then want
> to reference this I-D.
>
> I would be willing to expand this into replacement text if this
> suggestion meets with approval.
>
> Tom Petch
>
> ----- Original Message -----
> From: "t.petch" <[e-mail]>
> To: "Bert Wijnen (IETF)" <[e-mail]>; "Kent Watsen"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, April 08, 2014 2:44 PM
> Subject: Re: [Netconf] WG Last Call Comments
> ondraft-ietf-netconf-reverse-ssh-03.txt
>
>
>> I do not think that this is ready to advance.  I had not intended to
>> comment but having started on netconf-server, and found I had to read
>> 5539bis to understand where it was going, I then found that
> reverse-ssh
>> was another piece of the jigsaw.
>>
>> In particular, I think that this I-D is more or less updating RFC4742
> in
>> its considerations of security.  And I think it may be confused about
>> public keys and certificates and their role in authentication.
>>
>> Taken together, and I do not think they can be considered separately,
> I
>> do not think that the three I-Ds give a coherent view of how to secure
> a
>> NETCONF session.
>>
>> I would point to the queries raised by Tadek and Bajpai which, to me
> on
>> the one hand seem spot on and on the other, seem to regard the subject
>> material of these three I-Ds as of a one - which I obviously agree
> with.
>>
>> I think that netconf-server is the one in most need of progress and
> see
>> it as a Normative, not Informative, prerequisite.
>>
>> Tom Petch
>>
>>
>> ----- Original Message -----
>> From: "Bert Wijnen (IETF)" <[e-mail]>
>> To: "Kent Watsen" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, April 03, 2014 12:36 PM
>>
>>> WGLC period ended last Tuesday (April 1st).
>>>
>>> Kent, where are we with this one?
>>>
>>> Do you expect to post a rev 04 that addresses all comments we have
>> received?
>>> Either WGLC comments or other comments? Once that is done, I would
>> like to ask:
>>> - Kent to post which comments have not been addressed and why (if
> any)
>>> - If possible, Kent to post a summary of changes (although that may
>> already be
>>>     in the document, and that is fine too).
>>> - All those that made comments to check if they are OK with the way
>> that
>>>     they have been addressed or responded to.
>>>
>>> Bert
>>>
>>> On 27/03/14 17:02, Kent Watsen wrote:
>>>>
>>>> Hi Alan,
>>>>
>>>>
>>>> Awesome comments - thanks!
>>>>
>>>>
>>>> I applied all fixes mentioned below to my working copy of what
> will
>> be
>>>> -04, so you'll have to wait until then to see the diff.  The
> reason
>> I'm
>>>> not posting -04 now is because I'm still trying to work out an
> issue
>> with
>>>> Applicability Statement and with the port's name.
>>>>
>>>> Below are my detailed responses.
>>>>
>>>> Cheers,
>>>> Kent
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Typos
>>>>> -----
>>>>>
>>>>
>>>> I fixed all the issues you found.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Section 7, Page 7, Third Paragraph:  (wording)
>>>>> ----------------------------------------------
>>>>>
>>>>> In a few places in the third paragraph, and possibly in other
>> places
>>>>> in the document, would changing "needs to" to lowercase "must",
> or
>>>>> lowercase "should", make the document a little more concise?
>> Example:
>>>>>
>>>>>     "Note that since the SSH server would have to be configured to
>> know
>>>>>      which IP address it needs to connect to,"
>>>>>                          ^^^^^^^^
>>>>
>>>>
>>>> I changed "needs to" to "is to" for this cited location and
> another
>> I
>>>> found.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks again,
>>>> Kent
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>
>