[anonsec] what I call leap-of-faith

[kivinen at iki.fi (Tero Kivinen)]

Michael Richardson writes:
> ssh.com ssh now stores things by the name that you type on the command
> line + port number. openssh stores by IP and name. This causes problems if
> you have ssh servers on different port numbers, such as having port 222
> portforwarded by you NAT to some host behind it --- I mention this because
> the public is bound to a name in different ways by different vendors.

The important thing there is to store AND match the identity user
indicated to the database, without doing any unsecure modifcations to
it (dns lookups, adding search path etc). There are attacks which can
be done if those are done. I.e. the database lookup should be based
only on the thing user typed in.

One of the features implementations do not yet have is to do reverse
matching of the keys, i.e. if the key is not found from the database
using the identity given by user, then search the database for the
matching public key, and instead of print "unknown host dialog", print
out "Unknown host, but the samepublic key was previous used by host
foo". This solves the problem where you ssh into your laptop in the
remote network, where it might have unknown name and ip, but you can
still find the matching public key from your database matching our
"mylaptop.mynetwork.com" entry.

Also implementations should give out the option to use make temporary
connection,i.e. not to stopre information to the database permanently. 

> When we store the key, we have to be careful about storing it by IP
> address. I would not do that, as I have no way of knowing if the IP address
> is permanent or ephermeral.

The problem with btns use of leap-of-faith is that quite often the
IP-address is the only thing we have. My application might have some
other identity (like dns-name), but when the packets finally end up to
the ipsec level there is nothing left than the IP-address. If we do
not have any specific policy for that host, then we do not have any
other ID than IP address.

Again here comes those gui-options in to important role. The user
quite often knows whether the IP address he is connecting is permanent
or not, he also knows whether he wants to insert the data to database
or not. Also doing reverse lookup based on the public key for unknown
identities will help user again to ntoice that all ip-addresses of for
example www.google.com do match to the same key, especially if when
adding to the new identity is added to the database the user is also
given option to add extra comments. 

> I see no major problem with storing the keys by other IDs, particularly
> random DN.

Where do you get that DN or other IDs? You should not really trust the
other end sending you ID claiming to be www.example.com when you are
connecting to the www.evil.org.

> The leap-of-faith would be when the admin took the key, and "locked it down",
> i.e. loaded it into the trusted-store and attached some kind of SPD entry to
> it.   I.e. the leap-of-faith takes this peer from being BTNS to being
> "normal" IPsec, with the exchanging of authentication material having been
> facilitated by BTNS in-band.
> (How the admin checked the key is by definition out of scope)
-- 
kivinen at safenet-inc.com