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: Wednesday, May 07, 2014 6:54 PM

Hi Tom,

>So, my still outstanding points are
>
>- s.5, re-arrange to dovetail better with 5539bis

My understanding is that you believe that both drafts share the issue of
the northbound management application being able to identify and verify
the [SSH/TLS] server that uses call-home to connect to it.   I agree.

And that the text in the reverse-ssh draft, while ostensibly about SSH
host keys, could similarly apply to TLS and its use of X.509
certificates.
  I agree again, there is an overlap.

Thus you think that much of the text should be moved to 5539bis and for
the reverse-ssh draft to reference it there.  I don¹t agree, for two
reasons:

1) if there is a need to define common call-home behavior, we should
have
a ³call-home² draft that covers both TLS and SSH call-home together.  I
recall this being one of the options discussed before, but the WG
decided
to move ahead with this document structure.  In lieu of that, I think
that
the reverse-ssh draft is closer to being a ³call-home² draft than
5539bis,
and so suggest putting common call-home information into it, perhaps
pulled out into a section called ³common call-home behavious² - what do
you think?

2) The text in the reverse-ssh draft is also much about the use of
legacy
host-keys versus the new X.509 based keys with SSH.  Saying that use of
legacy keys is possible and allowed, but fraught with issues that are
resolved when using X.509 keys.  Maybe this needs to be may clearer, but
I
don¹t think the information should be lost.

<tp>
Kent

No, I think I am not making myself clear.

I am not saying that we need a common call home section.

I am saying that having obtained a public key somehow, then it needs
verifying, that it is tied to the party that we are trying to
communicate with, and that that process is largely the same whether this
is call home or not.

One form of verification is using X.509 certs, and that is the usual way
for TLS.  My logic then is put everything we have to say about the use
of X.509 certs for verification in the TLS I-D and reference it from the
(reverse-)ssh I-D.  The approach is the same for SSH and TLS and call
home and not call home IMHO so put it in the one place.

Currently, reverse-ssh lacks some of the points that 5539bis makes about
the use of certs, and the base ssh RFC says nothing, but reverse-ssh has
points that 5539bis does not such as the paragraph
" Since both the identification and verification issues are addressed
   using certificates, this draft RECOMMENDS network elements use a host
   key that can encode a unique identifier (e.g., its serial number) and
   be signed by a common trust anchor (e.g., a certificate authority).
   Examples of suitable public host keys are the X.509v3 keys defined in
   defined in [RFC6187]."
5539bis would be better for having that information in it alongside what
it currently has so I would move that to 5539bis leaving behind
something like

" Since both the identification and verification issues are addressed
   using certificates, this draft RECOMMENDS network elements use them -
   more details can be found in [5539bis]."

By contrast, the use of raw public keys is rare in TLS and commonplace
in SSH, so I would keep everything about that that is currently there in
reverse-ssh - mostly it is nothing to do with call home but the base ssh
RFC does not cover it so we might as well do the job properly now.

So between them, reverse-ssh and 5539bis currently have all we need, it
is just that you have to read both in tandem to learn what you should
know.

Tom Petch

>- 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'."

I like this text, especially since we switched everything else to
"call-home" in -05.   I just updated my local copy this this change, but
will wait for resolution of the above before putting out -06

Thanks,
Kent