[13811] in cryptography@c2.net mail archive
Re: replay & integrity
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Thu Jul 10 13:58:13 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 10 Jul 2003 07:03:13 -0600
To: "Zooko" <zooko@zooko.com>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: iang@systemics.com, "EKR" <ekr@rtfm.com>,
"tom st denis" <tomstdenis@yahoo.com>, cryptography@metzdowd.com
In-Reply-To: <E19aJXk-0007bw-00@localhost>
At 02:19 PM 7/9/2003 -0400, Zooko wrote:
>I'll try to make this concrete. My thesis is different than Ian's -- rather
>than saying that those apps need less than what TLS offers, I say that they
>need more! (So that each app need no longer implement the added features
>itself.)
we did two kinds of replay countermeasures ... one for AADS RADIUS
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.asuretee.com/
and a different kinds for x9.59 (for all electronic payments in all
environments)
http://www.garlic.com/~lynn/index.html#x959
in the aads radius there is this (real-time) protocol chatter; client
contacts server, server returns message with unique value, client includes
unique value in signed message that is returned to server. server validates
the signature and makes sure the client's message returns the previously
transmitted unique value.
for x9.59 to work in all environments ... it had to operate in single round
trip (as per many of existing financial messages). the client creates a
complete signed message and sends it to the server (financial institution),
the message has some possibly unique values ... but not necessarily
guaranteed, including time. the server uses current time and message time
to bracket checking of previously processed messages for replay.
the radius implementation requires two round-trips to establish the unique
value as part of replay counter measure.
the x9.59 implementation (in order to meet one of the requirements for the
protocol; perform completely in single round trip) uses a log and a sort of
fuzzy time implementation (at the server). this is in part because the
client end can be considered somewhat unreliable ... not necessarily being
able to reliably remember previous value and/or keep synchronized time.
highly synchronized time could eliminate the log check. having reliable
client that was guaranteed to remember previous transaction could get by
with the log elimination by using a take off on the single password scheme
.... where both the server and the client reliably remembers just the
previously used value, this rmemory doesn't get out of sync ... and the
iteration to the next value is non-obvious.
and of course the overall requirement given the x9a10 working group for
x9.59 was to preserve the integrity of the financial infrastructure for all
electronic payments in all environments.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
