Correct.
It's considered bad form to design systems which have known replay attacks when it's just as easy to design systems which don't. If there were some overriding reason why it was impractical to mount a defense, then it might be worth living with a replay attack. However, since it would have only a very minimal effect on offered load to the network and--in most cases--only a marginal effect on latency, it's not worth doing.
-Ekr
-- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
so, lets look at the alternatives for servers that are worried about server replay attacks:
client has public key & crypto-preferred info (dns or cached), generates random secret key, encrypts request, encrypts random secret key, single transmission
server gets request ... application has opened the connection with or w/o server replay attack. if the application, higher level protocol has its own repeat checking .... it has opened the connection w/o server replay attack. and the server sends the request up the stack to the application. If the application has opened the connection with server replay attack, the protocol sends back some random data (aka its own secret)... that happens to be encrypted with the random key.
The client is expecting either the actual response or the replay attack check. If the client gets the actual response, everything is done. If the clients gets back the replay attack check .... it combines it with something .... and returns to the server.
The difference is basic two packet exchange (within setup/teardown packet exchange overhead) plus an additional replay prevention two packet exchange (if the higher level protocol doesn't have its own repeat handling protocol). The decision as to whether it is two packet exchange or four packet exchange is not made by client ... nor the server ... but by the server application.
Simple example for e-commerce is sending a P.O. along with payment authorization ... the transmitted P.O. form is guaranteed to have a unique identifier. The P.O. processing system has logic for handling repeat POs ... for numerous reasons (not limited to replay attacks).
Single round-trip transaction:
ClientHello/Trans->
<- ServerResponse/FinishTransaction w/replay challenge:
ClientHello/Trans->
<-Server replay challenge
ClientResp->
<-ServerResponse/FinishNow, ClientHello/Trans can indicate whether the client is expecting a single round-trip or additional data.
Also, the ServerResponse can indicate whether it is a piggy-backed finish or not.
So, the vulnerability analysis is what is the object of the replay attack and what needs to be protected. I would contend that the object of the replay attack isn't directly the protocol, server, or the system .... but the specific server application. Problem of course, is that with generic webserver (making the connection) there might be a couple levels of indirection between the webserver specifying the connection parameters and the actual server application (leading to webservers always specifying replay challenge option).
--
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]
