[ 
http://issues.apache.org/jira/browse/AXIS2C-263?page=comments#action_12434350 ] 
            
James Clark commented on AXIS2C-263:
------------------------------------

On further reflection I think generating the message-id is going to be a 
problem.  You can't simply hash the byte-stream, because XML signatures only 
guarantees the integrity of the canonicalized form.  You would have to 
canonicalize and then hash. That is far too expensive a way to do replay 
detection, which needs to be cheap.

Whether the timestamp is required should be a configurable matter of policy.  
(See WS-SecurityPolicy.) Reading the specs, it looks like the timestamp element 
is designed specifically to support replay detection, so I would use it as 
designed.

I would suggest the following:

1. If a server wants replay detection on a service, it must have a policy of 
requiring timestamps for that service.  (This should probably be default 
configuration.)

2. If the configured policy does not require a timestamp, then no replay 
detection is performed.

3. Otherwise, proceed as follows. Have a configurable message lifetime (say 5 
minutes by default).

4. Reject any message without a timestamp (alternatively for a message without 
a timestamp, timestamp it with the current time).

5. Reject any message with a timestamp older than the configured lifetime.

6. Keep the timestamps and message-id, if any, of all messages in a database 
until their timestamp makes them older than the configured message lifetime. 

7. Reject any message in the database with same timestamp  and with the same 
message-id element. The message-id element can be missing but two messages 
without message-ids and with the same timestamp will be treated as the same, 
and thus the second received will be rejected as a replay.   In other words, 
senders don't have to use a message-id, but if they don't and they're sending 
messages very rapidly, they run the risk of getting their messages rejected as 
replays.

You would need to fix AXIS2C-279 (fractional date-times) to make this viable.

> Replay detection needed
> -----------------------
>
>                 Key: AXIS2C-263
>                 URL: http://issues.apache.org/jira/browse/AXIS2C-263
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: rampart
>    Affects Versions: Current (Nightly)
>            Reporter: James Clark
>         Assigned To: Malinda Kaushalye Kapuruge
>            Priority: Critical
>
> You need to implement replay detection.  See section 13.2.1 of WS-Security 
> 2004.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to