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

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

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