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 > _______________________________________________
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.