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 [EMAIL PROTECTED]

Reply via email to