[anonsec] what I call leap-of-faith

[Tom Petch]

Not sure what gave rise to this thread but the security glossary draft
 <draft-shirey-secgloss-v2-04.txt>
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
      operation began).

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

Tom Petch


----- 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
> 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.
>
> 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
architect[
> ] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device
driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy");
[
>
> --=-=-=
>