WS-RX security

[Richard Salz <rsalz@us.ibm.com>]

I've been reading through the four documents you posted...  very 
interesting.

Section 5 seems pretty reasonable, but I think it's missing something. 
What's the mechanism to tie the WS-RM elements to the message itself? In 
other words, what prevents an adversary from intercepting messages two and 
three, and exchanging the WS-RM headers and then sending them along as 
three and two? (This is the same problem that WS-Security kerberos profile 
had in early drafts, and what the SAML holder-of-key SubjectConfirmation 
element does.)

You might want to think about restructuring the protocol of section 7 to 
that it looks more like SSL.  One side provides an ordered list of 
mechanisms, and the other side picks one of them:
        <wsrmsp:SecurityMechanisms ...>
                   <wsrmsp:Mechanism wsrmsp:type="xs:anyuri">
                        ... *
                    </wsrmsp:Mechanism> *
                 </wsrmsp:SecurityMechanisms>
If a mechanism is repeated multiple times, an xml:id attribute is used to 
uniquely identify them.  Then the SecurityMechanismResponse can contain 
either the URI of the type, or the ID of the element.

In section 6, I really dislike same_node and sep_node; it's really 
shared_id and nonshared_id.  Also, I think you need a TLS/unauth profile. 
If an RMS always uses SSL, point-to-point link over fiber, etc., when 
talking to an RMD, then there doesn't seem to be any need for the RMS and 
RMD to have any concept of identity at all. If both sides use IPsec, then 
RMS and RMD can verify "yes, same entity as before" by just looking at the 
IP addresses, for example.  (This would argue that it should just be 
'transport' and not TLS/unauth.)  I'd have to think about it more, but it 
seems that WS-SecureConversation could fit into this category, too.

Overall, tho, I wonder if this work is unique to WS-RM, or if it addresses 
problems that other WS-xxx (will) have as well?

        /r$

--
SOA Appliances
Application Integration Middleware