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

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

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