[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: WS-RX security
Rich, Thanks for reviewing the proposals. Replies inline . . . > -----Original Message----- > From: Richard Salz [mailto:rsalz@us.ibm.com] > Sent: Friday, May 19, 2006 1:25 PM > To: Gilbert Pilz > Cc: ws-rx@lists.oasis-open.org > Subject: WS-RX security > > 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.) In Section 5.5, requirement 3 calls for the <wsrm:Sequence> header to be bound to the message body to which it applies. By this I meant that Sequence Traffic Messages should be protected by some mechanism (signature or encryption) that lumps the sequence header and the message body together into a single entity such that you can't alter either of them without invalidating the signature or messing up the encryption. Perhaps I need to state this in different/stronger terms? BTW, I didn't think it was necessary to bind the SequenceAcknowledgment and AckRequested headers to their message bodies (although with TLS you don't get a choice). These headers don't really have anything to do with the bodies of the messages in which they appear, so its no big deal an attacker switches them around (though they should be integrity protected as per requirement 2). > 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. The problem I have with this idea is that I was thinking that, at least in the TLS cases, the CreateSequence message (which includes the SecurityComposition element) would be carried in the same security context (say a TLS session and some BasicAuth credentials) that is "indicated" by the SecurityComposition element itself. For example, when /wsmr:CreateSequence/wsrmsp:SecurityComposition/wsrmsp:Identifier has the value ".../http_auth/shared_id" (to use your name) it means that the AS and RMS are identified by the HTTP-header-level BasicAuth credentials for the HTTP request in which the SOAP envelope containing *that* CreateSequence message appears. This way, the RMS code doesn't have to have any knowledge of what "its" username is, only the fact that one will be used. This allows for the security properties (username/password) to be set via some lower-level configuration without the need for the RMS to be involved. If we go with the idea of the RMS proposing multiple profiles and the RMD picking the one it wants, then we have to allow for the fact that the RMD may pick one other than the one that carried the CreateSequence message. This means that the RMS will have to know how to switch between different profiles and I'm not sure we want to place that big of a burden on the RMS. On the other hand, it doesn't have to be an either/or situation. A simple, non-security-aware RMS can propose the only profile it is statically configured to support and go from there. A more sophisticated RMS could propose multiple profiles. I'm interested to hear what other people think . . . > In section 6, I really dislike same_node and sep_node; it's > really shared_id and nonshared_id. Agree completely (wish I had thought of those names earlier). > 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.) Agreed. Can I enlist your help on putting together such a profile? > I'd have to think > about it more, but it seems that WS-SecureConversation could > fit into this category, too. I think several members of the TC would have a problem with this. I invite Chris to explain why attempting to make the RMD (on the CreateSequence message) and the RMS (on the CreateSequenceResponse message) dynamically "discover" the fact that they are using a WS-SX context and apply authorization based on the "same entity as before" principal is not a good idea. (I get it when you explain it to me Chris - but it always escapes me shortly thereafter). > 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? I suspect that any WS-* spec that involves lifecycle management of a shared resource such as the WS-RM Sequence will have similar problems. So, for example, WS-Coordination will have similar problems protecting its coordination context. WS-Addressing, on the other, does not have these problems (although it has other security issues) since EPRs are created by a single entity and basically "read-only" by everyone else. - gp
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]