[anonsec] what I call leap-of-faith

[yushunwa at ISI.EDU (Yu-Shun Wang)]

Hi, Michael,

Comments below.

Michael Richardson wrote:
> When you SSH to a host the server sends it's public key inline.
> 
> The client checks against a local database it has (~/.ssh/known_hosts for ssh
> 1 and openssh, ~/ssh2/hostkeys/key_PORT_NAME for ssh.com ssh2). You can
> populate these yourself if you want.
> 
> If the entry is not found, the user is presented with a finger print (hex and
> bubble-babble are common), and asked if they want to check it. The user types
> "y" or "n". Some users call up the admin and ask for the fingerprint, others
> just make a leap-of-faith: that they are not being MITM attacked at that
> moment.
> 
> 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 leap-of-faith is that the user is consulted as an oracle to make the hard
> decision.  Modern SSH implementations will now for instance, turn off password
> authentication when the host is not yet known, to avoid disclosing the
> password to a MITM.
> 
> If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active
> user that can be contacted, then I'd accept to create the PARENT SA, and then
> limit the CHILD SA to what would otherwise be permitted as plaintext.

If channel binding is to be used, I thought CB doesn't
or shouldn't send passwords in cleartext?

> 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.
> 
> I see no major problem with storing the keys by other IDs, particularly
> random DN.
> 
> 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)

Disagree on the last point, though it's subtle and not sure
how significant it'll be. When SSH stores the key from the
LoF, it means two thing:

- It's a leap of faith for _this_ connection.
- By storing the key for future use, one is extending the
   leap of faith for future connections until noted otherwise.

This is similar to answering "Accepting this CA cert
permanently" when prompted by web browsers.

For both cases, they are still leap of faith, and are still
unauthenticated (if no channel binding). It should not be
treated or converted to _normal_ (authenticated) IPsec just
because the leap of faith is extended. Bottom line: the
auth credential is still unauthenticated in PAD, so IMO
presenting it otherwise would be dangerous. I admit that
in doing so, the applications, SSH & browsers, are essentially
treating such extended LoF as "normal" by bypassing the
prompts. But it's different to do so in protocols. Actually,
now that I think about it, adding SPD probably doesn't make
it "normal" (non-BTNS) IPsec because it's PAD that matters.
Steve will know for sure.

Finally, I am not sure if adding SPD entries because of BTNS is
a good idea or not. Although it seems like the actual policy
regarding authentication is in PAD in 4301 now, SPD is
still part of the policy database and I've always thought
BTNS should be specified by policy but not creating policy?
Maybe this is related to Sam's comments re: API or interfaces
to SPD? But I thought that's from _outside_ of IPsec such as
other protocols or apps.

yushun