On Mon Oct 6 15:25:53 2008, Jonathan Schleifer wrote:
This is where your previous assertions appear to be in conflict.
How does he know you weren't lying when you said it matched?
When you verify the SAS through the telephone, you hear each other
and recognize each others voice.
Right - and that voiceprint identification, as it were, carries
through to the esession channel.
If I'd tell him then it matches though it didn't, I would have
just allowed a MITM, nothing more.
I don't see why, in practise, you'd do this, but for the sake of
argument you've confirmed there is an MITM, and then proceeded
anyway, which seems odd.
Additionally, he could ask me to re-negotiate and tell him my SAS
and compare it.
Right, this works.
I don't believe it's needed, since if you distrusted each other so
much that you had to go this route, why would you trust them with
whatever you're saying?
If you still assert that your authentication was only one way,
could you now explain how this was achieved, and in particular,
what the side-channel used for SAS was, what its security
properties were, and what the resultant security properties of
the esession were?
They just knew from other things that I was I and trusted their
server that there is no MITM and verified - which is why I didn't
verify them.
Ah...
So basically, they didn't authenticate you as such at all, they just
took the (often quite sensible) route of using a "leap of faith".
(Oddly, not described at all in Wikipædia).
For those that don't know the term, that's trusting an initial
key-exchange as being "probably okay", recording the public key of
the peer, and then only worrying about changes. If the first key
exchange wasn't compromised, then it's proof against further
compromise.
Lots of real-world cases of this exist - like SSH - and it's probably
fine for a lot of cases, such as verifying your roster. One might
envision a client which internally performs leap-of-faith, and merely
records whether a "proper" verification has ever been done.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
