From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Donnerstag, 22. Juni 2006 18:00
To: Raepple, Martin
Cc: Marc Goodner; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issues 121 - 124 RM + SP Assertions
The STR in the CreateSequence is needed as there is no way to indicate
which token is being used otherwise
Anthony Nadalin | Work 512.838.0085
| Cell 512.289.4122
"Raepple, Martin"
<martin.raepple@sap.com>
06/22/2006 09:49 AM |
|
Marc, thanks for the clarification. So the use case for the explicit token reference could be this: RMS and RMD agreed upon a shared security context token to sign/encrypt the messages (which maybe used beyond the scope/lifetime of the sequence) but actually use a second token to associate it with the CreateSequence and to authenticate all subsequent messages belonging to this sequence. My observation is as follows: As long as this second token is also associated with a signature in the security header used to authenticate the peers, there is no need to put an additional STR in the body of the CreateSequence message. For other token types (e.g. Username, SAML), this could be different. They are usually not used to calculate a signature and thus need to be referenced explicitly in the CreateSequence body. An example for CreateSequente using a UsernameToken to authenticate the sequence and a Security Context Token to secure (sign) the message could look like this (enhancing my earlier example):
<s:Envelope>
<s:Header>
<wss:Security>
<!-- This UNT is used to authenticate the messages of the sequence -->
<wsse:UsernameToken wsu:Id="username">
<xenc:EncryptedData>...</xenc:EncryptedData>
</wsse:UsernameToken>
<!-- This SCT is used to protect the messages -->
<wsc:SecurityContextToken wsu:id='CS_SCT'>
<wsc:Identifier>ABC123</wsc:Identifier>
</wsc:SecurityContextToken>
<!-- all <xenc:EncryptedKey> used to encrypt the UNT left out for simplification -->
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI='#CS'>
...
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>
<wss:SecurityTokenReference>
<wss:Reference URI='#CS_SCT' ValueType='.../sc'/>
</wss:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wss:Security>
</s:Header>
<s:Body>
<wsrm:CreateSequence wsu:id='CS'>
<wsrm:AcksTo>
<wsa:Address>http://abc</wsa:Address>
</wsrm:AcksTo>
<wss:SecurityTokenReference>
<wss:Reference URI='#username' ValueType='.../UsernameToken'/>
</wss:SecurityTokenReference>
</wsrm:CreateSequence>
</s:Body>
</s:Envelope>
For me, this sounds like a valid use case. But my guess is that in many cases either (a) the token used to sign the CreateSequence message is also used to authenticate the peers or (b) the second token is also associated with a signature in the security header. I want to make clear that I am happy with the inclusion of an STR in the body. My only concern is that we should not replicate information that is already in the message for certain (maybe the majority of) use cases and that a composition of RM with security protocols should take this into consideration.
-- Martin
>-----Original Message-----
>From: Marc Goodner [mailto:mgoodner@microsoft.com]
>Sent: Mittwoch, 21. Juni 2006 23:39
>To: Raepple, Martin; drsecure@us.ibm.com
>Cc: ws-rx@lists.oasis-open.org
>Subject: RE: [ws-rx] Issues 121 - 124 RM + SP Assertions
>
>I can't pretend to speak for Tony but here is my take on this.
>
>I understand what you are proposing but the implicit model
>does not work if there is more than one token in the CS
>message. For example, there may be one token that is used to
>sign the message and a separate token intended to secure the
>sequence. Explicitly identifying the token via the STR in the
>CS itself makes it clear which token is intended to secure the
>sequence. Of course this works when there is only a single
>token in the message as well and simplifies things in
>comparison to defining two ways to do it when one can cover
>both use cases.
>
>I can add a something to the proposal to try to clarify this,
>and the WSS faults we've previously discussed, and get it back
>to the list soon.
>
>-----Original Message-----
>From: Raepple, Martin [mailto:martin.raepple@sap.com]
>Sent: Wednesday, June 21, 2006 1:41 PM
>To: drsecure@us.ibm.com
>Cc: ws-rx@lists.oasis-open.org
>Subject: RE: [ws-rx] Issues 121 - 124 RM + SP Assertions
>
>Tony,
>
>let my clarifiy my concern regarding the STR as part of the
>body: In the proposal, the STR is used to <Quote> "establishes
>an association between the created Sequence and the referenced
>security token, such that the RM Source and Destination MUST
>use the security token to authorize all subsequent
>interactions related to the Sequence(s)" </Quote>. Given that,
>I think the following sample message (without an STR in the
>body) also fulfills this requirement. The STR as part of the
>Signature/KeyInfo points to an Security Context Token in the
>security header which is used to calculate the signature over
>the CreateSequence message:
>
><s:Envelope>
> <s:Header>
> <wss:Security>
> <wsc:SecurityContextToken wsu:id='CS_SCT'>
> <wsc:Identifier>ABC123</wsc:Identifier>
> </wsc:SecurityContextToken>
> <ds:Signature>
> <ds:SignedInfo>
> ...
> <ds:Reference URI='#CS'>
> ...
> </ds:Reference>
> </ds:SignedInfo>
>
><ds:SignatureValue>...</ds:SignatureValue>
> <ds:KeyInfo>
> <wss:SecurityTokenReference>
> <wss:Reference
>URI='#CS_SCT' ValueType='.../sc'/>
>
></wss:SecurityTokenReference>
> </ds:KeyInfo>
> </ds:Signature>
> </wss:Security>
> </s:Header>
> <s:Body>
> <wsrm:CreateSequence wsu:id='CS'>
> <wsrm:AcksTo>
> <wsa:Address>http://abc</wsa:Address>
> </wsrm:AcksTo>
> </wsrm:CreateSequence>
> </s:Body>
></s:Envelope>
>
>Thereby the SCT is implicitly associated with the
>CreateSequence due to the signature that references this SCT
>and the RMD can authenticate the RMS. I am proposing that an
>RMD should use the token referenced by the STR in the security
>header / signature to authenticate the RMS, given the
>advantage of this implicit approach that it does not require
>any change to the RM messages.
>
>- Martin
>
>________________________________
>
> From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
> Sent: Mittwoch, 14. Juni 2006 20:47
> To: Raepple, Martin
> Cc: Christopher B Ferris; Marc Goodner;
>ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Issues 121 - 124 RM + SP Assertions
>
>
>
> >I believe that it is necessary to add a dedicated
>section that provides (normative) advice how SSL/TLS should be
>used in the context of RM
>
> This is what the assertion points out, the RM document
>should not become a security document (which it seem its
>becoming, there are other orgs and specifications that working
>on security), so I suggest that RM describe the assertions and
>point to the security specs used and to WS-I BSP for best
>practices for SSL/TLS.
>
> > I was wondering why the STR is actually defined as a
>child element of the CreateSequence instead of using it in the
>security header of the CreateSequence message. I believe the
>reason is that RM cannot rely on WSS (which probably does
>processing of the SOAP message first and then passes the data
>to the RM protocol) to understand the semantics of a sequence.
>In other words, WSS can only verify that the signature (using
>whatever token is referenced by the STR) is valid on a
>message-by-message basis, but cannot guarantee that message a
>(e.g. CreateSequence) used the same token than message B
>(using the sequence) to sign the body. If this is the reason
>(and may be there are more to mention), I think some language
>to explain this more explicitly in the proposal should be
>added as well.
>
> So I'm not following your concern here, as the STR as a
>child element of the CreateSequence is to bind the token to
>the CreateSequence as the wsse:Security header is per entire
>message (as there is only one wsse:Security header per target
>per message).
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> Inactive hide details for "Raepple, Martin"
><martin.raepple@sap.com>"Raepple, Martin" <martin.raepple@sap.com>
>
>
>
>
> "Raepple, Martin"
><martin.raepple@sap.com>
>
> 06/14/2006 06:42 AM
>
>
>
> To
>
> "Marc Goodner" <mgoodner@microsoft.com>
>
>
> cc
>
> Christopher B Ferris/Waltham/IBM@IBMUS,
><ws-rx@lists.oasis-open.org>
>
>
> Subject
>
> RE: [ws-rx] Issues 121 - 124 RM + SP Assertions
>
>
> Marc,
>
> thanks for the policy examples - they help a lot in
>understanding how WS-SP can be used to support RM to configure
>security. However, I think they also demonstrate that the
>current proposal requires an update in some key areas:
>
> - Use of SSL/TLS: Although the current proposal refers
>to WS-SP which can be used to configure HTTPS for an RMD, I
>believe that it is necessary to add a dedicated section that
>provides (normative) advice how SSL/TLS should be used in the
>context of RM. Things to mention here are for example the
>relationship and proper management of SSL/TLS session lifetime
>and RM sequence lifetime (according to Gil's comments in
>http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archiv
es/200606/msg00069.html <http://www.oasis-open.org/apps/org/workgroup/ws->rx/email/archives/200606/msg00069.html> ), CreateSequence
>message format (I believe without and STR in the SSL/TLS
>case), need for two SSL connections in an asynchronous scenario etc.
>
> - Composititon of WS-SP and RM policy assertions: The
>examples are a good starting point and should be used to
>include a more normative section on this issue, may be based
>on a (new) structure that separates transport and message
>security throughout the proposal in a more obvious way.
>
> - Clarification of the requirement to add the STR in
>the body of the message: While rereading the proposal(s)
>again, I was wondering why the STR is actually defined as a
>child element of the CreateSequence instead of using it in the
>security header of the CreateSequence message. I believe the
>reason is that RM cannot rely on WSS (which probably does
>processing of the SOAP message first and then passes the data
>to the RM protocol) to understand the semantics of a sequence.
>In other words, WSS can only verify that the signature (using
>whatever token is referenced by the STR) is valid on a
>message-by-message basis, but cannot guarantee that message a
>(e.g. CreateSequence) used the same token than message B
>(using the sequence) to sign the body. If this is the reason
>(and may be there are more to mention), I think some language
>to explain this more explicitly in the proposal should be
>added as well.
>
> - Faulting behaviour: The proposal should clarify how
>the RMD responds when it supports the STR but is not able to
>understand the (semantics of the) security token referenced by
>the STR (see
>http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archiv
es/200606/msg00063.html <http://www.oasis-open.org/apps/org/workgroup/ws->rx/email/archives/200606/msg00063.html> )
>
> A more general problem is the maturity of the current
>WS-SP spec draft since most discussion in SX is around WS-SP
>issues. To mitigate this issue, I recommend that the proposal
>specifies the referenced version of SP. I am wondering how
>other members in this TC feel on that?
>
> -- Martin
>
> Martin Raepple
> Platform Ecosystem Industry Standards
> SAP AG
> Dietmar-Hopp-Allee 16
> 69190 Walldorf, Germany
> T +49/6227/7-60365
> F +49/6227/78-44724
> mailto: martin.raepple@sap.com
> http://www.sap.com <http://www.sap.com/>
>
>________________________________
>
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Dienstag, 13. Juni 2006 01:28
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] Issues 121 - 124 RM + SP Assertions
>
> All,
>
> I've attached three examples of combining the RM
>assertion, including the proposed SequenceSTR assertion, with SP.
>
> · RMSC.xml - This shows the RM and
>SequenceSTR assertions with the SP assertions indicating that
>SecureConversation is to be used.
> · RMX509.xml - This shows the RM and
>SequenceSTR assertions with the SP assertions indicating that
>X.509 is to be used.
> · RMHttps.xml - This shows the RM
>assertion with the SP assertion indicating HTTPS is to be
>used. Note there is no SequenceSTR assertion in this example
>as the STR would not be used. Also I included in the comments
>here an alternate HTTPS binding showing additional options
>that are currently being considered in the SX TC. I believe
>this supports Gil's current proposal for issue 121.
>
>
> Regards,
> Marc g
>
>
>
>