Re: [ws-rx] New proposed issues 2/2 - 2-8

[Paul Fremantle <paul@wso2.com>]

David

I'm not sure I agree. Marc's proposed solutions to these threats are 
reversals of i029. But the primary question at this point is not "what 
is the proposed solution?" but - "are these valid issues with the spec 
as it is?".
If these are valid issues with the spec as it is, it is more valuable to 
have them as new separate issues and use the issue process to track them.

Paul

David Orchard wrote:
>
> Hi all,
>
> If you cast your mind back to i029 
> (http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i029) 
> it removed the STR from the CS. Both these issues have a resolution 
> that the STR should be added to the CS, which obviously reverses i029s 
> resolution.
>
> Given that these suggest reversing i029, these issues should probably 
> be cast as additional resolutions to i029 and we should accordingly 
> re-open i029. It may be that we don't reverse i029 and add these 
> threats to our security considerations, or that we reverse i029 and 
> add these threats. In any event, these are directly related to i029 so 
> let's keep them all together.
>
> For the record, I think the detailed treatment of these 2 threats is 
> excellent material and should be included in the spec.
>
> Cheers,
>
> Dave
>
> ------------------------------------------------------------------------
>
> *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> *Sent:* Thursday, February 09, 2006 11:17 AM
> *To:* ws-rx@lists.oasis-open.org
> *Subject:* [ws-rx] New proposed issues 2/2 - 2-8
>
> Four new proposed issues this week, let me and the list know if any were missed. – Marc g
>  
> -----------------------------
>  
> Proposed-01
>
> Title: RM Sequence Hijacking threat
>
>  
> Proposed-02
>
> Title: Signature replacement threat
>
>  
> Proposed-03
>
> Title: Scoping an RM sequence to a security context
>
>  
> Proposed-04
> Title: CloseSequenceResponse and TerminateSequenceResponse messages are 
> inconsistent wrt presence of wsrm:Identifier
>  
> -----------------------------
> Proposed-01
>
> Title: RM Sequence Hijacking threat
>
> Description:
>
> For RM to work in the full generality of the Web services security 
> model it needs to support sequence creation based on specific claims 
> not just identity (in fact no identity credentials may even be 
> present). This means that if session-specific credentials beyond the 
> initial authorizing credentials are not identified, any party with the 
> authorizing credentials can hijack the session. For example, if anyone 
> in group X can create a sequence, then Alice can use a sequence that 
> Bob created so long as both Alice and Bob are in group X.
>
> Such security relies on the confidentiality of the sequence ID 
> imposing limitations on the ID (to prevent brute force attacks and 
> guessing), risks to logging sequence information (which is a desirable 
> action), and increased complexities in allowing front-end and 
> intermediary systems to process and direct messages in intermediary 
> scenarios (the sequence header has to be added and encrypted for each 
> intermediary and signed by the originator eliminating dynamic 
> intermediaries, etc…)
>
> This can be mitigated by mechanisms such as TLS. It is important that 
> when using such mechanisms that they be bound to the RM session to 
> prevent gaps in the security through potential intermediate hops. 
> However TLS has at least two shortcomings in mitigating against this 
> threat. One is that if an RM session may run longer than the TLS 
> session, this is particularly true for mobile clients. The other is 
> that it may not be available on every transport that RM may be used 
> with. There are other problems such as end-to-end security, TLS is 
> needed at each hop and untrusted intermediaries will have access to 
> the ID without additional precautions.
>
> Therefore a richer binding of a security context to a RM session 
> should not be left undefined.
>
> This binding is accomplished as follows. A service user establishes a 
> security context with their credentials prior to creating the RM 
> session. This security context has the claims necessary for creating a 
> sequence. The keys associated with the security context are only known 
> to the two parties, other users in group X are not part of this 
> security context. This security context is used in the RM sequence 
> creation thus binding the two at creation time. With this coupling in 
> place, the RM sequence is effectively "owned" by the security context 
> identified in the sequence creation that establishes the security 
> context in this example. Establishing security semantics after the 
> resource is created leaves an attack window for creation attacks.
>
> The binding of a token to the RM sequence creation can be done by 
> including a STR to the token in the CS message.
>
> Target: core
>
> Type: design
>
> Origin: Marc Goodner
>
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00037.html
>
> Proposal:
>
> Add the threat as described in the issue description to the security 
> considerations as “Hijacking” in the list of enumerated threats after 
> line 817.
>
>  
>  
> -----------------------------
> Proposed-02
>
> Title: Signature replacement threat
>
> Description:
>
> Signature confirmation for an RM session is important so that 
> signature replacement can be quickly detected. This is important to 
> protect against the unintended processing of user data. If an attacker 
> replaces the signature on the CS message, then the signature 
> confirmation will indicate the replacement and the initiator knows not 
> to use the sequence. Assume there is an RM session initiated without 
> having its signature compromised, the associated signature has 
> specifically chosen privileges required for the service. In this case 
> the signature could be replaced with a new signature that has 
> different privileges associated with it to execute functions at the 
> service other than what the provider intends. In this case the 
> initiator would be able to detect this on confirmation (if they 
> receive it) but the service would have already processed the 
> compromised message.
>
> However, if the token (keys) were bound to the sequence during the RM 
> sequence creation the service would detect that the message was 
> altered before processing it. This is because a different token will 
> not be allowed for the entire RM session which would prevent an 
> attacker from being able to replace a signature and have the message 
> processed before the signature was confirmed by the initiator (if at all).
>
> On a related note there is also the threat of associating the wrong or 
> superset credentials in scenarios where messages require multiple 
> signatures because of other headers and message aspects. Binding a 
> token to the RM sequence at creation also disambiguates which token is 
> intended for the RM CreateSequence message if there is more than one 
> primary token.
>
> The binding of a token to the RM sequence creation can be done by 
> including a STR to the token in the CS message.
>
> Target: core
>
> Type: design
>
> Origin: Marc Goodner
>
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00038.html
>
> Proposal:
>
> Add the threat as described in the issue description to the security 
> considerations as “Signature replacement” in the list of enumerated 
> threats after line 817.
>
>  
>  
> -----------------------------
> Proposed-03
>
> Title: Scoping an RM sequence to a security context
>
> Description/Justification:
>
> There are several threats, hijacking [1] and signature replacement 
> [2], that can best be mitigated by binding the RM sequence to a 
> specific security context identified by a token. For the sake of 
> interoperability it is best that this capability be defined in the 
> protocol rather than be left to a implementation detail for 
> implementers and/or users of the protocol. Likewise it should be 
> possible for an RMD to represent that it does or does not support this 
> capability.
>
> Target: core
>
> Type: design
>
> Origin: Marc Goodner
>
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00048.html
>
> Proposal:
>
> WS-RM Changes
>
> Line numbers from WS-RM CD 02
>
> Add “An RM Destination MUST fault if it does not understand 
> information passed using this extensibility mechanism.” to the end of 
> lines 297 and 300.
>
> The above would mean prevent an RMD from silently ignoring use of the 
> extensibility points in the create sequence and would read in the spec 
> as follows:
>
> /wsrm:CreateSequence/{any}
>
> This is an extensibility mechanism to allow different (extensible) 
> types of information, based on a schema, to be passed. An RM 
> Destination MUST fault if it does not understand information passed 
> using this extensibility mechanism.
>
> /wsrm:CreateSequence/@{any}
>
> This is an extensibility mechanism to allow additional attributes, 
> based on schemas, to be added to the element. An RM Destination MUST 
> fault if it does not understand information passed using this 
> extensibility mechanism.
>
> Add the following after line 300:
>
> /wsrm:CreateSequence/wsse:SecurityTokenReference
>
> This optional element uses the extensibility mechanism defined above 
> to communicate an explicit reference to the security token to be used 
> to authorize messages for the created outbound Sequence and if offered 
> the inbound Sequence, using a <wsse:SecurityTokenReference> as 
> documented in WS-Security [WSSecurity]. All subsequent messages in the 
> outbound Sequence and if offered the inbound Sequence MUST demonstrate 
> proof-of-possession of the referenced key.
>
> WS-RM Policy Changes
>
> Line numbers from WS-RM Policy CD 02
>
> Line 96
>
> Change: “defines a single RM policy assertion”
>
> To: “defines two RM policy assertions”
>
> Add a new assertion description as follows after line 116:
>
> WS-SecurityPolicy [WS-SecurityPolicy] provides a framework and grammar 
> for expressing the security requirements and characteristics of 
> entities in a XML web services based system. The Secure Sequence 
> Binding assertion allows the expression of additional security 
> requirements particular to RM sequences to be used in conjunction with 
> WS-SecurityPolicy. Specifically it defines that an RM sequence MUST be 
> bound to an explicit token.
>
> The RM Security assertion MUST NOT be used for an endpoint that does 
> not also use the RM assertion.
>
> Add the following after line 141:
>
> The normative outline for the Secure Sequence Binding Assertion is:
>
> <wsrmp:SecureSequenceBinding
>
> [wsp:Optional="true"]? ... >
>
> </wsrmp:SecureSequenceBinding >
>
> /wsrmp:SecureSequenceBinding
>
> A policy assertion that specifies security requirements which MUST be 
> used with an RM Sequence that are particular to WS-RM and beyond what 
> can be expressed in WS-SecurityPolicy.
>
> /wsrm:SecureSequenceBinding /@wsp:Optional="true"
>
> Per WS-Policy [WS-Policy], this is compact notation for two policy 
> alternatives, one with and one without the assertion. The intuition is 
> that the behavior indicated by the assertion is optional, or in this 
> case, that the RM Sequence binding to a specific token MAY be used.
>
> Line 143
>
> Change: “Because the RM policy assertion indicates endpoint behavior 
> over an RM Sequence, the assertion has”
>
> To: “Because the RM policy assertions indicate endpoint behavior over 
> an RM Sequence, the assertions have”
>
> Assertion example and schema outline TBD
>
> Reference:
>
> 1 hijacking threat 
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00037.html
>
> 2 signature replacement threat 
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00038.html
>
>  
>  
> -----------------------------
> Proposed-04
> Title: CloseSequenceResponse and TerminateSequenceResponse messages are 
> inconsistent wrt presence of wsrm:Identifier
>  
> Description/Justification: Both the CloseSequenceResponse and 
> TerminateSequenceResponse follow a similar pattern, but the CSR message 
> does not contain the wsrm:Identifier whereas the TSR does.
>  
> Target: wsrm spec
>  
> Type: design
> Origin: Anish Karmarkar
> http://lists.oasis-open.org/archives/ws-rx/200602/msg00056.html 
>  
> Proposal: Either (1) add the wsrm:Identifier element to the 
> CloseSequenceResponse message OR (2) remove the wsrm:Identifier element 
> in the TerminateSequenceResponse message.
>
> Marc Goodner
>
> Technical Diplomat
>
> Microsoft Corporation
>
> Tel: (425) 703-1903
>
> Blog: http://spaces.msn.com/mrgoodner/
>

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com