[NEW ISSUE] RM Sequence Hijacking threat

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

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.

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/mrgoodner/

ws-rx message