Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jun 2013 21:54:08 +0000

[Jeff accidentally didn't send his response to the list, so it's in full
below]

On 6/24/13 5:02 PM, "Jeffrey Hutzelman" <[email-masked]> wrote:

>On Mon, 2013-06-24 at 19:55 +0000, Kent Watsen wrote:
>> 
>> On 6/24/13 11:40 AM, "Jeffrey Hutzelman" <[email-masked]> wrote:
>> >Back in 2006, the ISMS working group considered a "reverse SSH"
>>approach
>> >similar in concept to what is being discussed today.  We ended up
>> >deciding against it, in part because of the security implications of a
>> >protocol that is basically a device opening a connection and saying
>>"Hi,
>> >I am a server, please tell me your password".
>> 
>> ...after verifying the devices host key - we certainly wouldn't expect
>>the
>> client to try logging into any server.  Further, we recommend the
>>host-key
>> be a certificate containing the server's identity, though
>
>... against what?
>ssh clients know a priori what host they're going to connect to, and
>thus know which keys are valid (or what name to use, depending on the
>keyex method in use).

I'm assuming you mean the first-time connection, since every time
thereafter the host-key accepted before can be used for the lookup and
verification.

For first-time connection, Network Management apps can be preconfigured to
know which IP addresses or FQDNs they're expecting.  They may even let the
end-user input the device's host-key manually. If using certificates, we
especially like the idea of putting the device's serial-number into the
Common Name field, and assume the app is preconfigured to know which
serial numbers to expect (as well as the CA's cert)

>> When it was looked at before, did anyone find an attack?
>
>That is the wrong question.  When we looked at it before, people with a
>strong understanding of how SSH works, myself included, did not manage
>to convince themselves it was safe.  Further, we discovered a number of
>issues such as the host naming problem described above, which made that
>sort of "reverse SSH" impractical, and some of which would likely apply
>to netconf as well.

It's not wrong, per se, as a single attack would prove insecurity; though
I'll grant you that it doesn't prove security either.  I was hoping that
we could construct a proof now.  I think that it would be fine even if the
solution only supported certificate-oriented host-keys - this case should
be easier to prove secure as no reference to the TCP-layer is needed, and
therefore its directionality inconsequential - yes?

For what it's worth, I FIPS-certified a similar strategy a few years back
- a device-initiated transport with a certificate proving identity and
providing a trust root.  It was fairly rigorous given the EAL level we
were going for.  I'll grant you that this isn't a proof either, but it
seemed good enough for the DoD...

>Instead, we went with a model in which a device
>"calling home" is the SSH client.  Such a device may need to be
>provisioned with credentials, but this is generally true anyway, and
>usually the sorts of credentials that would be required to operate as an
>SSH server can also be used to operate as a client.

I see.  I just read RFC 5592, the last paragraph of section 8 (Operational
Considerations) is relevant.  It basically says the device initiates the
ssh connection when needing to push traps. The makes perfect sense, of
course.  I take it that you didn't need to manage devices (set/get) behind
firewalls and thus the applications could always initiate connections to
the devices?     We started supporting device-initiated connections
primarily to support devices behind firewalls.  I get the impression that
others have this need as well.

>In the case of SNMP, the layers of the protocol just above SSH are
>fairly symmetric, so once the connection is established, the subsystem
>can be started by the SSH client, and then communication can run in
>either direction.  This will likely be somewhat different for netconf,
>but should still be mostly doable.  You may end up needing to use a
>different subsystem in the case where the SSH client is the managed
>device, if the next layer is not sufficiently symmetric.

You're right about NETCONF being fairly symmetric, but we really want the
applications to the able to open the SSH channels, since they know how
many channels want and when they want them.  For instance, an application
may open one SSH channel for NETCONF, another to receive SNMP traps via
ISMS another for `sftp`, and another to tunnel a CLI console shell.
Notice that the sftp/cli uses would be user/demand-driven - i.e. the
device wouldn't know a priori that channels for those would be needed.

You're also right that the auth could be flipped.  That is, the device
could be configured with the app's host-key, and the app could be
preconfigured to trust a CA (assuming x509 client auth).  But if we go
this route then, somehow, between the Auth Protocol (4252) and Connection
Protocol (4254), we'd need to reverse the Connection Protocol to enable to
"server" to open subsystems on the "client". This falls into the "I want
the device to be the SSH client (standard SSH)" question on the
virtual-hum survey[1], for which currently there is 0% support
for...likely because it's not immediately implementable, but that's just
my guess, it could also be because folks like idea of being able to
preserve all their key-distibution infrastructure...

[1] http://www.surveymonkey.com/s/MWVNT7M

Thanks again,
Kent

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 26 Jun 2013 15:04:12 -0400

> thereafter the host-key accepted before can be used for the lookup and

No.  The point is that before _any_ connection is ever started, an SSH
client knows who the host is supposed to be.  It uses that as a key into
its database of host keys, if you're using a keyex method that uses host
keys.  It may get used in other ways for other keyex methods (and you
cannot assume that everything will involve public keys; it's common for
enterprises to want to do something else).  You cannot discover the
host's identity from anything that appears as part of the connection;
you need to know in advance what it is supposed to be.

> serial numbers to expect (as well as the CA's cert)

Except an SSH _client_ doesn't work that way.  It doesn't open a
connection randomly out into the internet and see if whoever answers is
a host it knows about.  It opens a connection to a _specific_ host and
then verify's the server's credentials against what it is expecting for
that host.

This is why it's fairly important, in SSH, for the endpoint that
originated the connection to be the one that is the SSH client.  The
connection originator knows in advance who it thinks it is going to talk
to, which SSH requires, whereas the endpoint accepting the connection
does not -- it needs to decide whether whoever did connect is
authorized.

> therefore its directionality inconsequential - yes?

SSH really doesn't contemplate a model where you connect to a host, do a
key exchange, and then figure out which host you connected to based on
its certificate.  Among other things, SSH's default/mandatory algorithms
don't use certificates.  But yes, if you were to restrict yourselves to
non-standardized certificate-based methods, you could probably bash an
implementation into letting you do this.  I think deciding whether that
is safe would require some additional analysis.

However, I would strongly caution against specifying use of SSH only
with non-IETF algorithms.  Not supporting standard algorithms such as
RSA public keys, GSS-API, and so on will severely limit the
deployability of the resulting protocol beyond the narrow scenario
you're envisioning.

> seemed good enough for the DoD...

I'm not saying you can't have a device-initiated connection where the
device identifies itself with a certificate.  I'm saying that for SSH,
the right way to do that is for the device to act as an SSH client and
use SSH public key userauth, not to run the SSH protocol in reverse,
which has unknown security properties.

> others have this need as well.

I'm pretty sure we didn't specifically consider the scenario of a device
initiating a connection to a management station for the purpose of
receiving commands, no.  However, SNMP is basically a symmetric protocol
and we do permit reuse of SSH connections in both directions, provided
the endpoints are right.  So, while my memory on this is a bit hazy, I
believe it would work to have a device set up a connection and then have
the other end start sending it commands.

> device wouldn't know a priori that channels for those would be needed.

Once an ssh connection is established, _channels_ can be opened by
either end, at will.  In practice it generally only makes sense to open
some kinds of channels in one direction or the other, but the protocol
imposes no constraints here.

-- Jeff

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jun 2013 23:55:15 +0000

>you need to know in advance what it is supposed to be.

The SSH RFCs don't say this.  RFC 4253, section 4 just says "The client
initiates the connection.", but they could be referring to the SSH-client
(not the TCP-client).  Likewise, RFC 4251, section 9.3.4 describes
man-in-the-middle attacks, but simply says that the client should verify
the association between the server host key and the server host name - it
doesn't say anything about what inputs the client can use to derive the
host name. Just saying...  ;)

Of course, TLS has much stronger language and I think it's fair to apply
it to SSH, as you have.  Specifically, RFC 6125, section 6.2.1 defines
rules for constructing reference identifiers.  The language here provides
little wiggle-room but, at the same time, still doesn't provide rational
for why that must be the case.  For all I know, the authors felt it
common-sense it codified it.

What is particularly interesting is that, in the case of TLS, earlier RFCs
explicitly allowed this.  For instance, both RFC 2818 (section 3.1) and
RFC 5539 (section 3.1) say "If the client has external information as to
the expected identity of the server, the hostname check MAY be omitted.".

>then verify's the server's credentials against what it is expecting for

True, but that's doesn't prove that this proposal insecure either.

>does not -- it needs to decide whether whoever did connect is

I think here you come closest to putting a finger on it, but I keep coming
back to that no one can show an attack.  If it's so important, then
wouldn't it be easy to show an attack?  I'll even make it easy, assume the
bad-device is behind the same NAT as a good device:  The only attack I can
envision is one where it's a first-time connection for that device AND the
device isn't using a certificate-based hostkey AND the application blindly
accepts the presented hostkey.  But even this pathological case doesn't
prove anything because it's already known that blindly accepting host keys
is insecure...

>is safe would require some additional analysis.

Minor clarification - we're expecting to figure out the host *during*
key-exchange (not after).  All the SSH client libraries I've tested provid
a callback function for hostkey verification.  This function gets executed
during the diffie-hellman exchange, as soon as the SSH-client receives the
server's SSH_MSG_KEXDH_REPLY message - this is, for instance, the same
time openssh would check the known_hosts file.

>deployability of the resulting protocol beyond the narrow scenario

Agreed - the draft merely RECOMMENDS using certificate-based algorithms,
as the certificates very nicely provide a trust-root and a certifiable
identity.  Ultimately, the device had to have been configured to know
which IP addr/port to connect to and, at the same time, can be configured
to know what host keys algs to present.  This just shows that it's a
deployment-specific configuration to decide, not an IETF requirement.

>which has unknown security properties.

I understand perfectly.  I saw Mouse (I think) post this idea (to let the
"server" open subsystems on the "client") to the ietf-ssh list but, for
some reason, I stopped receiving messages from that list in April - and
that list's archives are practically inaccessible, so I'm not following
what's going on there (anything?).  Nonetheless, as I wrote before, I
accept that this is a viable solution - the only thing I don't like about
it is that it could be years until SSH implementations would support it,
if ever.  It's simply a case of having an immediately-implemenatable
solution with unknown security properties versus an
not-implementable-for-awhile solution with known security properties.
What do we need to do to "know" the security properties with the current
proposal? - is it a paper exercise or soak time required?

>imposes no constraints here.

True, current protocol says that either side can open a "channels" - this
is in RFC 4254, section 5.1:

	"When either side wishes to open a new channel, ...

But to open a subsystem, we need a "session" and section 6.1 says:

  "Client implementations SHOULD reject any session channel open
   requests to make it more difficult for a corrupt server to attack
   the client."

Now, I'll grant you that it's a SHOULD (not a MUST), but existing
implementations don't support it, and that's the key difference we're
spinning on here.

Thanks,
Kent