On Mon Oct 6 00:04:49 2008, Jonathan Schleifer wrote:
Am 06.10.2008 um 00:44 schrieb Dave Cridland:
You see, there is a reasonable asusmption by the police that the
endpoints of the esession must be as you expect, since you are
continuing the session, and without that expectation on your part,
the channel could be, or is, compromised, and based on your
apparent intent to talk to the police in a secure manner, it is a
reasonable assumption to make, I think.
Yes, but unlike a key, an SAS doesn't identify you.
Not in and of itself. But the fact that you are telling the other
party that this is the SAS you wish them to check implies some form
of identity exchange at least in one direction, and typically two,
unless you use some form of broadcast mechanism.
Are you still claiming I "clearly don't get" some concept, or can
we move on?
Then I don't get why you suggest putting a SAS on a webpage - which
would be completely pointless.
It just happens to be the only channel I could immediately think of
which had the requisite properties. When you claimed that you'd
somehow been authenticated without having authenticated, how did you
do it?
Web pages are not immutable, and new web pages can be created. I
fail to see this as being a problem. Even if I were somehow
mistaken about the web - I did my first HTTP/1.1 implementation
about 11.5 years ago, but I'm hardly an expert - I don't see this
has having much to do with the question at hand, that is, the
symmetry of authentication inherent in a SAS based mechanism.
Using a web page, an attacker could also get the SAS.
Erm... Two things:
1) An attacker capable of passive observation of the traffic can
already do this. This is not a problem, which is just as well given
we assume the presence of such an attacker.
2) An attacker doesn't need to merely know the SAS, and attacker
needs to change it, effectively acting as an MITM in the flow of the
"OOB" channel. Therefore, the SAS has to be transferred over a
channel with the security property that no MITM is possible. A web
page which is itself authenticated by TLS can do this.
Actually, since in order to subvert the channel, the attacker must
act as an MITM in both the esession channel and the side-channel,
then merely using highly distinct channels is probably good enough in
practise, so I wouldn't disagree that if someone sticks the SAS code
on an ordinary, unprotected web page, that is increasing the attack
cost sufficient to offer reasonable protection for most cases.
And you can't share the SAS there in advance.
No, but shockingly, it is possible to control a webpage after the
session has been setup.
The situation of talking to the police is clearly a situation where
you want a public key, not an SAS - this is why I thought you
didn't get how SAS works.
Right, you'd ideally need a SIGMA-I, no SAS at all, and some method
for verifying the police's public key. But since the esession
protocol provides no method for doing that short of transferring the
entire public key using a side-channel, I'm not entirely convinced it
helps much beyond moving the problem about, and using a big chunk of
static data with no agreement on implementation instead of a short
variable string.
One obvious advantage of making the public key directly accessible on
a webpage is that it becomes much harder to correlate accesses via
HTTP to the user, of course, which is a whole area of identity
leakage we've not yet touched on. Good grief! You realise that'd let
the IP address get out?
Entirely changing the authentication mechanism to a PKI-based system
does indeed work much better in this scenario, which is why I
suggested that in the first place.
You mean that by continuing the conversation I tell the other side
that it matched? If it doesn't match, I could just keep on talking
with the other side, but tell useless stuff instead of the stuff I
originally intended to say
I cannot conceive of any reason to do so, but still I'll go along
with this. You're saying that if you think the session is being
actively compromised, you wouldn't tell the other party (reasonable,
you cannot), but would instead seek to delude them by continuing the
conversation?
. So this doesn't tell the other side whether it matched or not,
IMO.
So what you're saying there, then is that the SAS exchange is
worthless, because there's no way for me to prove that, once I've
given you a SAS code, whether or not it matched, irregardless of
whether or not the other party continues, and therefore whether or
not the session is secure.
That being my point, which you're failing to grasp, perhaps I should
rephrase:
Under what circumstances, in your opinion, does exchanging a SAS code
for a session prove anything at all, and what does it prove?
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
