On Thu Oct 2 19:02:38 2008, Jonathan Schleifer wrote:
Am 02.10.2008 um 19:58 schrieb Dave Cridland:
Assymetric authentication in esessions in only possible if the SAS
code is transferred over a channel which, itself, provides only
assymetric authentication. The SAS mechanism itself is symmetric,
but can only prove the security equivalence of the two channels,
thus if the SAS side-channel has assymetric properties, then so
with the esession itself.
This hasn't to do with asymmetric or symmetric. The other side, say
the police, could tell me their SAS. Then I can silently verify
them or not. They never know if I verified them. They never know
if the SAS matched. Thus one-side verification IS possible.
Sort of. But this would only be possible if the channel used by the
police to tell you the SAS had the property that you could be assured
it was the police who was giving you the SAS, and moreover that the
police could not tell who they were giving the SAS to.
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.
Therefore, whether or not you choose to tell the police whether the
SAS code matches, they can essentially assume any identity derivable
from the endpoints of the channel used for the SAS also applies to
the channel the SAS identifies.
In that sense, the exchange of SAS code is in effect a weak form of
channel binding, allowing the assertion that the endpoints of one
channel (the esession) are equivalent to the endpoints of another
(that used for SAS transmission).
So if you are providing other people with the SAS code for the
esession via, say, a web page, then because all they can say about
the web page is that you have some control of it, then all they
can say about the esession is it belongs to someone with control
of the webpage.
You clearly didn't get the concept of an SAS.
A SAS code is a short code essentially identifying the channel, in
this case an esession. You could make one for TLS by using some form
of cryptographically secure hash over the final two messages
exchanged by client and server - indeed, these two messages are also
used for channel binding data, and channel binding operates by
uniquely identifying a secure channel and binding the endpoints of an
authentication to them by using them as input to cryptographic
functions.
In the case of a SAS, it's intended to be transferred over some
alternate channel deemed sufficiently secure. The weaker the channel,
the weaker the resultent security. Transferring a SAS over the
channel it identifies offers no additional security. Transferring it
over a "perfect" channel results in "perfect" security - albeit given
that no security algorithm is perfect, this isn't exact, but assuming
esessions is at least as good as the state of the art, one can make
this approximation.
Are you still claiming I "clearly don't get" some concept, or can we
move on?
You can't put an SAS on a web page as that's different with every
session.
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.
To get a side-channel that proved your identity entirely without
disclosing anything about the other end would be quite tricky, and
in fact the only one that springs to my mind is using a CA
signed certificate and a TLS session, and given that
arrangement, it seems most useful to just use that for
communications.
You disclose nothing with the SAS - it's different for every
session and you don't even have to tell them if it matched or not.
Absolutely.
But...
The other party can always tell, assuming a well behaved actor, that
you did check it and it did match, because you have continued to use
the channel. If you don't care, why set up an esession?
If this is really the case that one cannot make this assertion, then
the other party has an interesting problem, because the other party
can never know if you're telling the truth when you say it matches,
and can never know if you continue to use the channel irregardless
of its security properties, and therefore a single exchange of a SAS
code is worthless.
Instead, once the SAS code is given, the session needs to be
renegotiated, you need to ensure that the key matches between
sessions, and then provide a SAS code to the other party - the other
direction to the original session.
Incidentally, a bad actor deliberately trying to lull you into
spilling your secrets is going to want to validate that they are
indeed your secrets, and will therefore be quite keen to check your
identity, so I'm not really sold on this whole idea, but it's a
logical result of your argument.
Since you cannot have it both ways, then, either I'm right, and
providing a SAS code in either direction, with or without
confirmation, results in a weak channel bind to the channel used for
passing the SAS, or else you're right and providing a SAS code gives
the provider no knowledge of the security of the esession at all.
Pick one, and please explain your choice.
If you do insist on picking both, you'll have to explain in some
detail.
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
