Having problems with message search?
Thanks Jan,
> As to
#2, I would rather completely remove wsse11:SignatureConfirmation from all
messages, because this has no status in any current WSS specification.
Secure RM needed a way to prevent secure
session hijack at the initiation step.
Signature confirmation is used in situations where initiator needs confirmation
that the message received was indeed generated in response to a message it
initiated in its unaltered form. This prevents certain class of man in the
middle attacks (e.g.: maliciously adding signatures, man in the middle adding
additional headers without awareness of the initiator).
The current OASIS SOAP Message security 1.1 draft [1] contains signature
confirmation (see section 8.5, starting at line 1170).
Given that we needed a way to demonstrate mitigation of the session hijack
threat, instead of introducing a custom mechanism, we re-used a pattern that is
already being worked on inside the OASIS WSS TC.
[1] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/11535/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf
From: Jan Alexander [mailto:alex@...]
Sent: Thursday, April 07, 2005
1:00 AM
To:
WS-Security-Workshops@yahoogroups.com
Subject: RE:
[WS-Security-Workshops] Proposed updates to SC+RM scenarios document
I'm posting this only to WS-Security-Workshops group, because I'm not member of WS-RM-Workshops right now. Could some forward it to the RM group?
Systinet is fine with #1 and #3.
As to #2, I would rather completely remove wsse11:SignatureConfirmation from all messages, because this has no status in any current WSS specification.
The proposal for this element was posted by Vijay Gajjala from MS in last August to the WSS mailing list and the issue around this was later marked as closed. However the spec itself does not contain this proposal in any version. It is not clear whether WSS 1.1 will even contain this mechanism. I don't see any point testing interop on something that has no clear status from the spec perspective.
What do others think about this?
Thanks,
--Jan
From: Kirill Gavrylyuk [mailto:kirillg@...]
Sent: Thursday, April 07, 2005 3:04 AM
To: WS-Security-Workshops@yahoogroups.com; WS-RM-Workshops@yahoogroups.com
Subject: RE: [WS-Security-Workshops] Proposed updates to SC+RM scenarios documentFolks, haven’t heard much feedback from participants – is everyone ok with making these changes?
thanks
From: Kirill Gavrylyuk [mailto:kirillg@...]
Sent: Tuesday, April 05, 2005 12:52 PM
To: WS-Security-Workshops@yahoogroups.com; WS-RM-Workshops@yahoogroups.com
Subject: [WS-Security-Workshops] Proposed updates to SC+RM scenarios document
Based on the comments received so far on the document, we propose the following updates to the SC+RM scenarios. What do folks think?
- Ordering elements inside Security header. An issue was raised around scenarios text prescribing specific elements order inside Security header, for example requiring Timestamp to be the first element. We believe the best way to proceed is to remove any ordering requirements text from the scenarios doc – follow what WS-Security and BSP prescribes.
- SignatureConfirmation. We introduced SignatureConfirmation on the secure session initiation (RST/RSTR handshake). Given that this is a protection mechanism applicable to the entire message exchange, it would make sense to use it on all messages.
- Encrypted Signature. Scenarios document currently prescribes encrypting signatures on RST/RSTR and app messages, but not WS-RM infrastructure messages. Similar to #2, given that encrypting signature is a protection mechanism that is applicable to the entire exchange, it would make sense to either do it for all messages or not do it for any.
Attached is the scenarios document with the proposed changes applied, marked with change bars. thanks
Offline 
Send Email