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

[Kent Watsen <[e-mail]>]

Hi Tom,


Regarding the paragraph you quoted below, note that it's about more than
just X.509.  Specifically, there are other SSH host-key formats that can
encode a unique identifier and be signed by a common trust anchor (e.g.,
the PGP keys from RFC 4253).   I admit the text could be made better - how
about this?

   Examples of suitable public host keys are the X.509v3 keys defined in
   defined in [RFC6187] and the PGP keys defined in [RFC5253].

                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If this doesn't resolve the issue, can you also provide the text you hope
to now show up in 5539bis?  I see below what text is proposed to be
removed from draft-ietf-netconf-reverse-ssh, but it doesn't make sense to
just put that into 5539bis, what more do you hope to see in 5539bis?

Thanks,
Kent




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