replay & integrity

[Anne & Lynn Wheeler]

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 at metzdowd.com