[anonsec] PAS issue 14 - leap of faith

[Joe Touch]

Maybe it'd be useful to pose the questions separately, i.e., what should
each of the following steps be called>

1. accepting the first unauthenticated certificate (U-C)

2. deciding to cache accepted U-Cs for future use

3. referring to the blind acceptance of cached U-Cs when matching

Where's the leap? Is it in:
	- accepting the first UC
	- assuming that matching UCs mean matching endpoints
	- somewhere else?

Joe

Yu-Shun Wang wrote:
> 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
> _______________________________________________