You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "James Clark (JIRA)" <ji...@apache.org> on 2006/09/09 08:57:22 UTC
[jira] Created: (AXIS2C-263) Replay detection needed
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
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "James Clark (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-263?page=comments#action_12434351 ]
James Clark commented on AXIS2C-263:
------------------------------------
Copy and paste error in the above:
4. Reject any message without a timestamp (alternatively for a message without a timestamp, timestamp it with the current time).
should be
4. Reject any message without a timestamp
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485429 ]
Malinda Kaushalye Kapuruge commented on AXIS2C-263:
---------------------------------------------------
For the replay detection I have this idea to give user an interface.
The interface has following methods.
status = Load(env, rd_module);
status = Is_Replayed(env, rd_module, msg_ctx);
status = Close(env, rd_module);
Note: Rd_module is the replay detection module.
Summary:-
Load(): Loads the data source, which can be a database, flat file etc.
Is_Replayed() : Check if the current message is replayed with the existing records.
Close(): Free resources allocated. Close data connections etc.
In this way the user can have his own logic to check whether the message is replayed or not. He may use the wsa:Message-ID, Timestamps, Nonce or even the digest of the message. User can configure the time frame or the message count frame for the replay detection.
We have to implement a sample replay detection module based to set an example for Rampart/C users.
Thoughts please.
Cheers,
Kau
> Replay detection needed
> -----------------------
>
> Key: AXIS2C-263
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "James Clark (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-263?page=comments#action_12433842 ]
James Clark commented on AXIS2C-263:
------------------------------------
For the purpose of designing replay detection, we should assume message integrity (from either transport-level security or digital signatures). If an attacker can modify the message, then they don't need to rely on replay, they can just send whatever message they want!
Have a configurable message lifetime (say 5 minutes by default).
Reject any message without a message id (alternatively we could generate a message-id for any message that lacks one, by using the message's sha-1 hash).
Reject any message without a timestamp (alternatively for a message without a timestamp, timestamp it with the current time).
Reject any message with a timestamp older than the configured lifetime.
Keep the message id of all messages in a database until their timestamp makes them older than the configured message lifetime.
Reject any message with a message id the same as any stored message.
The message store needs to be able to be on-disk and persistent. Applications should be able to plugin their storage technology of choice (eg sqlite, bdb, mysql). We can supply a default in-memory implementation, for now.
Does this make sense?
We should research how other technologies deal with replay detection (eg SSL, Kerberos 5).
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-263?page=comments#action_12433835 ]
Malinda Kaushalye Kapuruge commented on AXIS2C-263:
---------------------------------------------------
To prevent replay attacks we might need to cache the Username with the created time for a given period.
In this way we can throw an error if the same user sends two(or more) messages at the same time. But this is not that effective as one can send messages with different time stamps.
A better approach would be using digitally signed timestamps. But right now rampart does not support digital signatures. Do you have any other ideas to prevent replay attacks without using digitally signed timestamps?
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-263?page=comments#action_12434111 ]
Malinda Kaushalye Kapuruge commented on AXIS2C-263:
---------------------------------------------------
Sounds fine. :)
If I summarize the scenario.
- Generate message-ID by SHA-1(Serialized envelope of incoming message)
- Generate Timestamp on message arrival.
- Keep the message-ID + Timestamp for a specific time period(default is 5 minutes).
- Remove records if expired.
- On message arrival check if there is already a similar message-ID in the database.(or in memory hash table)
Suggestions:
1. At the beginning I'd like to keep message-ID + Timestamps in the hash table. One possibility of doing this is to keep the hash table as a property in conf context.
2. I do not like the idea of
Rejecting any message without a message id
Rejecting any message without a timestamp.
Instead we should generate message-IDs and Timestamps on arrival (like you have mentioned in alternatives) always.
3. It should be posisble to configure (to enable/disable) this protection mechanism.
This can be done in using an additional inflow security parameter.
Any comments?
PS: Also I'm wondering why this issue is reported as a bug ;-)
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-263) Replay detection needed
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-263?page=all ]
Malinda Kaushalye Kapuruge reassigned AXIS2C-263:
-------------------------------------------------
Assignee: Malinda Kaushalye Kapuruge
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-263) Replay detection needed
Posted by "James Clark (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org