RE: Issue 089 - WS-Discovery - Namespace of a Type can be alteredin a se

I have further refined proposal for issue 87, 88 and 89 based on the feedback from Tony Nadalin (IBM). I plan to discuss this tomorrow during F2F.

Thanks,

Vipul

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Monday, December 01, 2008 2:27 PM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Issue 089 - WS-Discovery - Namespace of a Type can be altered in a secure discovery message.

This issue is assigned the number 089. For further discussions on this issue, please refer to this issue number or use this thread.

From: Vipul Modi
Sent: Monday, December 01, 2008 12:40 PM
To: Ram Jeyaraman
Subject: New Issue: WS-Discovery - Namespace of a Type can be altered in a secure discovery message.

Specification: WS-Discovery

Version: Working Draft 04

Issue Description:

The compact signature is used for signing the discovery messages to protect their Integrity. The compact signature uses exclusive canonicalization mechanism. This form of canonicalization excludes all of the namespaces that are not visibly utilized (see Section 1.3 Limitations of Exclusive XML Canonicalization). For Discovery messages this means that all of the namespace used for Types will not be included in the canonical XML. Since the canonical XML does not include the namespace declaration for the Types, an attacker can easily redefine the prefix to be bound to a different namespace.

To understand this, consider the example below. Here a service is responding to a secure from the client by signing the body, discovery headers and addressing headers of the ProbeMatch message using compact signature mechanism. The ProbeMatch contains two Types, “i:PrintBasic” and “i:PrintAdvanced”. The prefix “i” is defined as “http://printer.example.org/2003/imaging”. Now even though the body is signed an attacker (man in the middle) can modify the message and redefine prefix “i” to point to “http://malicious.printer.org”. This is because the compact signature uses exclusive canonicalization scheme that excludes the prefixes that are not visible such as ones used by Types element.

Following is the original ProbeMatch message whose body, discovery headers and addressing headers needs to be signed.

<s:Envelope

xmlns:a="http://www.w3.org/2005/08/addressing"

xmlns:d="http://docs.oasis-open.org/ws-dd/discovery/2008/09"

xmlns:s="http://www.w3.org/2003/05/soap-envelope" >

<s:Header>

<a:Action>

http://docs.oasis-open.org/ws-dd/discovery/2008/09/ProbeMatches

</a:Action>

<a:MessageID>

urn:uuid:e32e6863-ea5e-4ee4-997e-69539d1ff2cc

</a:MessageID>

<a:RelatesTo>

urn:uuid:0a6dc791-2be6-4991-9af1-454778a1917a

</a:RelatesTo>

<a:To>

http://www.w3.org/2005/08/addressing/anonymous

</a:To>

<d:AppSequence InstanceId="1077004800" MessageNumber="2" />

</s:Header>

<s:Body>

<d:ProbeMatches>

<d:ProbeMatch>

<a:EndpointReference>

<a:Address>

urn:uuid:98190dc2-0890-4ef8-ac9a-5940995e6119

</a:Address>

</a:EndpointReference>

<d:Types xmlns:i="http://printer.example.org/2003/imaging">i:PrintBasic i:PrintAdvanced</d:Types>

<d:Scopes>

ldap:///ou=engineering,o=examplecom,c=us

ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us

http://itdept/imaging/deployment/2004-12-04

</d:Scopes>

<d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>

<d:MetadataVersion>75965</d:MetadataVersion>

</d:ProbeMatch>

</d:ProbeMatches>

</s:Body>

</s:Envelope>

Following is the exclusive canonicalization form of the body of the above ProbeMatch message without the InclusiveNamespaces PrefixList parameter. As you can see the namespace bound to prefix “i” is not included in the canonical form.

<s:Body xmlns:s="http://www.w3.org/2003/05/soap-envelope"><d:ProbeMatches xmlns:d="http://docs.oasis-open.org/ws-dd/discovery/2008/09">

<d:ProbeMatch>

<a:EndpointReference xmlns:a="http://www.w3.org/2005/08/addressing">

<a:Address>

urn:uuid:98190dc2-0890-4ef8-ac9a-5940995e6119

</a:Address>

</a:EndpointReference>

<d:Types>i:PrintBasic i:PrintAdvanced</d:Types>

<d:Scopes>

ldap:///ou=engineering,o=examplecom,c=us

ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us

http://itdept/imaging/deployment/2004-12-04

</d:Scopes>

<d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>

<d:MetadataVersion>75965</d:MetadataVersion>

</d:ProbeMatch>

</d:ProbeMatches>

</s:Body>

Following is the exclusive canonicalization form of the body of the above ProbeMatch message with the InclusiveNamespaces PrefixList parameter. The namespace bound to prefix “i” is declared here. Thus this namespace declaration will be used in the signature computation and cannot be altered.

<s:Body xmlns:s="http://www.w3.org/2003/05/soap-envelope"><d:ProbeMatches xmlns:d="http://docs.oasis-open.org/ws-dd/discovery/2008/09">

<d:ProbeMatch>

<a:EndpointReference xmlns:a="http://www.w3.org/2005/08/addressing">

<a:Address>

urn:uuid:98190dc2-0890-4ef8-ac9a-5940995e6119

</a:Address>

</a:EndpointReference>

<d:Types xmlns:i="http://printer.example.org/2003/imaging">i:PrintBasic i:PrintAdvanced</d:Types>

<d:Scopes>

ldap:///ou=engineering,o=examplecom,c=us

ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us

http://itdept/imaging/deployment/2004-12-04

</d:Scopes>

<d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>

<d:MetadataVersion>75965</d:MetadataVersion>

</d:ProbeMatch>

</d:ProbeMatches>

</s:Body>

Proposed Resolution:

The prefixes used by the Types should be included as part of the canonicalization process by supplying them as the InclusiveNamesapces PrefixList parameter of the canonicalization processor. These prefixes should be communicated in the compact signature block so that the receiver can include them in the canonicalization process as well.

See the attached document for normative changes.

ws-dd message