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: Friday, May 09, 2014 10:08 PM

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

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

<tp>

Kent

This is where we start to part company.  A host key is a host key, it is
public, it is generated for me as part of a key pair for use in public
key cryptography.  Of itself, it conveys nothing, no verification, no
validation, no identification.

It only acquires value when it can be tied into an identity or
identifier, which X.509 certificates do.  Or it can preconfigured into
the NMS (the key or a fingerprint thereof) but is the act of configuring
that gives the key some value, there is nothing inherent in the key.

You say in the I-D that this does not scale, but that is true of
(almost) everything.  If you use X.509 certificates, then they bind the
key to an identity; guess what, that identity has to be configured into
the NMS, so if configuring raw keys does not scale then neither do X.509
certificates:-(

The only thing that scales is Trust On First Use, which I think too
flaky for us to recommend.  Manual acceptance when a key is first used
is more secure, but, arguably, scales no better.

We have been here before - look at RFC5592, which basically says
'preconfigure host keys' to which I would now add 'or else use
certificates', RFC6125 etc.

So my section 5 (skating over PGP use) would be more like

"When the management system accepts a new incoming TCP connection on the
NETCONF over SSH Call Home port, it starts the SSH client protocol. As
the SSH client, it MUST authenticate the SSH server, by both identifying
the network element and verifying its SSH host key.

When not using call home, the management system initiates the TCP
connection and so may place some reliance on the fact that the device
that responds is the one that it is configured to communicate with.
With call home, the network element initiates the TCP connection and no
reliance can be placed on the source IP address of the TCP connection.
Identifying the remote peer by its source IP address, as recommended in
[RFC6187] is NOT RECOMMENDED in the case of call home, unless the
network takes steps to validate IP source addresses.

The management system may be configured with the host keys of the
network elements, or fingerprints thereof, and these MAY be used as an
identifier.

The management system MAY request manually verification of a host key or
a fingerprint thereof the first time the network element connects, and
any time the host key changes thereafter.

Digital certificates, such as those in X.509 version 3 (X.509v3) bind a
public key to a digital identity [RFC5280] and are used in many
environments for identity management.  This approach is discussed in
more detail in [5539bis]; this approach is RECOMMENDED."

Tom Petch

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.