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

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

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

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

Yes

The changes I made for -05 were only the one change of terminology, so
that if it were to be unacceptable for any reason, then that change
could be easily reversed.

So, my still outstanding points are

- s.5, re-arrange to dovetail better with 5539bis

- wordsmith the Abstract/Introduction (as first suggested last
November:-) where I think the first reference to 'SSH Connection' is
wrong, so make it something like

"This memo presents a technique for a NETCONF server to request that a
NETCONF client initiates a SSH connection to the NETCONF server,
a technique referred to as 'call home'."

Tom Petch

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