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

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

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "t.petch" <[e-mail]>; "Bert Wijnen (IETF)"
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 08, 2014 5:24 PM

Hi Tom,

Thank you for voicing my own thoughts as well.  I had previously raised
the idea of merging the reverse-ssh draft into a 4742bis, but the WG
agreed to keep it separate for simplicity sake.  That said, I like
symmetry, and it would be more consistent for 5539bis and a 4447bis,
rather than what we have now.  Just saying  ;)

Regarding Normative vs Informative, I recently asked about this and Bert
said that it comes down to if said draft needs to be understood and/or
implemented.  If this is the condition, then I believe it swings to
being
Informative, as proprietary vendor-specific configuration could be used
alternatively.  As it is, the vendor can decide if they want to
advertise
urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their <hello>
message.  Are you suggesting that advertising this capability in the
<hello> message should be required in order for an implementation to
claim
they implement Reverse SSH for NETCONF Call Home?

<tp>

Kent,

There is a lot of inconsistency between reverse-ssh and 5539-bis and I
think the latter is the better model.

The biggest difference is that 5539-bis never talks about reverse-TLS
because TLS is not reversed; NETCONF client = TLS client, NETCONF server
= TLS server always - simple, straightforward.

So why does reverse-ssh talk about reverse-ssh when ssh is NOT reversed?
To confuse people and raise hackles?  I know, times past we - or at
least I - was really talking about SSH role reversal but now we are not.

Keeping the term reverse-ssh I think politically unwise since we know it
rings alarm bells with those who know the security properties of SSH.
It confuses those who were not around when we really were discussing it,
since the term is technically wrong.  It makes ssh call home sound
completely different to TLS call home, which will confuse even more
people.  And it leads to section 5 which, since the usage of SSH is
identical to that of RFC4742, effectively updates RFC4742.

So, make it RFC4742bis?  Could do, or have done so, but I do not think
it necessary.  Rather
- change the terminology from reverse-ssh to call home
- specify that it updates the security considerations of RFC4742 by
fleshing out what is acceptable verification and authentication in the
Security Considerations of RFC4742
- point to 5539-bis for the rules on X.509 cert checking when certs are
used for identification - I think that 5539-bis does a good job there
which reverse-ssh s.5 does not
- provide text on security checking with raw host keys (as in current
section 5), since that is SSH specific; netmod-system has something on
this but probably not enough.

The other grey area is that netconf-server introduces periodic
connections, heartbeats, reconnection, timeouts.  All good transport-ey
stuff which impacts both SSH and TLS transports and, at least for
heartbeats and probably for more than that, needs protocol specific
details.  I think reverse-ssh and 5539-bis incomplete if netconf-server
includes these features and the other two do not at least reference
them; which makes netconf-server a Normative Reference.

The rod we make for our backs is to introduce functional enhancements as
part of a data model, not something the IETF has tended to do in the
past; rather the function has been sorted out first as text, or
pseudo-code or some such, and then the data model has been created to
support it i.e. we should not be introducing new function in
netconf-server, as if having a data model is all we need.

This also means that whether or not something is optional in the data
model is irrelevant.  The question should be, does it make sense, in
future, to implement NETCONF over SSH or TLS while being completely
ignorant of periodic connections, heartbeats, reconnection, timeouts
because they are only in netconf-server which is only a passing,
Informative Reference, nothing you need to know about?  If
netconf-server progresses with something like its current contents, then
I think my answer is apparent.

Given the xml, I would be willing to edit the reverse-ssh I-D changing
all references to 'reverse-ssh' to 'call home' leaving the rest of the
text unchanged pro tem.  I feel that strongly about it.

Tom Petch


Thanks,
Kent


On 4/8/14 9:44 AM, "t.petch" <[e-mail]> wrote:

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