RE: i029 Session hijacking addressed by STR in CSR

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

Marc,

Thanks for providing this information. The attack you outlined is pretty
much the same as the one I outlined in
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508
/msg00206.html.

There is a simpler way of protecting against this threat. As you stated
"if anyone obtains the sequence ID" they can execute this attack. There
are only two ways that an attacker can obtain someone else's sequence
ID; they can guess it or they can observe it. To protect against the
first possibility the RMD simply needs to create sequence IDs that
contain enough random information as to making guessing impractical. To
protect against the second possibility the RMS and RMD simply need to
use some underlying security mechanism that provides end-to-end message
confidentiality. This could be a WS-SecureConversation context, an
SSL/TLS session, or some other mechanism.

If people agree that the above proposal protects against the threat that
you have outlined, than I think people would also agree that the above
proposal is superior to the currently specified mechanism for the
following reasons:

1.) Although this allows WS-RM and WSS to be composed it does not bind
them together.
2.) It does not require the run-time cost of performing an authorization
check on every message.

In reality the threat we are discussing is no different than the threat
faced by web applications that use session cookies to preserve state.
Common practice is to generate random cookie values and protect these
cookies with SSL. Nobody had to tightly bind HTTP and SSL to prevent web
session hijacking.

If there are additional threats that the current mechanism defends
against, I welcome the chance to discuss those as well.

- g

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> Sent: Friday, September 16, 2005 6:00 PM
> To: Gilbert Pilz
> Cc: ws-rx@lists.oasis-open.org
> Subject: i029 Session hijacking addressed by STR in CSR
> 
> Gil,
>  
> You asked for more information on what threats that including 
> the STR in the CSR mitigates against. For one it prevents 
> session hijacking. 
>  
> For example, let's say that anyone in the FOO group can 
> create an RM session, then if anyone obtains the sequence ID 
> they are likely to be authorized to use the RM session. This 
> can be mitigated by a service user establishing a security 
> context with their credentials prior to creating the RM 
> session. This security context has the claims necessary for 
> creating a sequence. This security context is only known to 
> the two parties, other users in the FOO group 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 STR of the 
> CSR that establishes the security context in this example. 
> Establishing security semantics after the resource is created 
> leaves an attack window for creation attacks that is not 
> addressed by just signing the message header and body.
>  
> Again, I believe this issue should be closed with no action. 
> The STR should not be removed from the CSR. 
>  
> Regards,
> Marc g
>  
> 
________________________________________________________________________________
BEAWorld 2005: coming to a city near you.  Everything you need for SOA and enterprise infrastructure success.


Register now at http://www.bea.com/4beaworld


Santa Clara 27-29 Sep| London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec