RE: [ws-rx] Issues 121 - 124 RM + SP Assertions

["Marc Goodner" <mgoodner@microsoft.com>]

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/archives/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/archives/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