OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Additionally, both proposed-01 and proposed-02 have this sentence in its 
description:

"The binding of a token to the RM sequence creation can be done by 
including a STR to the token in the CS message."

-Anish
--

Gilbert Pilz wrote:
> Proposed-01 and Proposed-02 may be separate issues, but Proposed-03 is
> clearly just i029 with the actions reveresed.
> 
> - gp 
> 
> 
>>-----Original Message-----
>>From: Paul Fremantle [mailto:paul@wso2.com] 
>>Sent: Thursday, February 09, 2006 12:52 PM
>>To: David Orchard
>>Cc: ws-rx@lists.oasis-open.org
>>Subject: Re: [ws-rx] New proposed issues 2/2 - 2-8
>>
>>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#i
>>
>>>029) 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
>>
>>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]