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 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]