[anonsec] what I call leap-of-faith
nwnetworks at dial.pipex.com
Fri Mar 24 10:24:49 PST 2006
Not sure what gave rise to this thread but the security glossary draft
now contains a definition which I would regard as a starting point
$ leap of faith
1. (I) /general security/ Operating a system as though it began
operation in a secure state, even though it cannot be proven that
such a state was established (i.e., even though a security
compromise might have occurred at or before the time when
2. (I) /COMSEC/ The initial part, i.e., the first communication
step or steps, of a protocol that is vulnerable to attack
(especially a man-in-the-middle attack) during that part but, if
that part is completed without being attacked, is subsequently not
vulnerable in later steps (i.e., results in a secure communication
association for which no man-in-the-middle attack is possible).
Usage: This term is listed in English dictionaries, but their
definitions are broad and can be interpreted in many ways in
Internet contexts. Similarly, the definition stated here can be
interpreted in several ways. Therefore, ISDs that use this term
(especially ISDs that are protocol specifications) SHOULD state a
more specific definition for it.
Tutorial: In a protocol, a leap of faith typically consists of
accepting a claim of peer identity, data origin, or data integrity
without authenticating that claim. When a protocol includes such a
step, the protocol might also be designed so that if a man-in-the-
middle attack succeeds during the vulnerable first part, then the
attacker must remain in the middle for all subsequent exchanges or
else one of the legitimate parties will be able to detect the
----- Original Message -----
From: "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
To: <anonsec at postel.org>
Sent: Monday, March 20, 2006 10:59 PM
Subject: [anonsec] what I call leap-of-faith
> 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
> 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.
> 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)
> ] ON HUMILITY: to err is human. To moo, bovine. | firewalls
> ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net
> ] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy");
More information about the ANONSEC