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