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


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]