[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]