Proposal for lc87 and lc55

In fulfillment of my action item to make a concrete proposal for  
issue lc87[1], please find attached replacement text for section 4 of  
WS-Addr Core and section 6 of WS-Addr SOAP Binding. This was  
developed in collaboration with Gudge and Jonathan.

I believe this new text will also address lc55[2], I checked with Tim  
(issue lc55 originator) and he indicated that he was happy with the  
text as it stands but that a concrete example might help to  
illustrate the possible attacks.

There is an open question identified by an ednote in the 'Additional  
Security Considerations' section of the SOAP Binding section, I think  
this warrants further discussion.

Marc.

[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc87
[2] http://www.w3.org/2002/ws/addr/lc-issues/#lc55

-- cut here --

X. Security Considerations (Core)

Conformance to this specification does not require a message receiver  
to honor the WS-Addressing constructs within a message if the  
receiver is not satisfied that the message is safe to process.

WS-Addressing supports capabilities that allow a message sender to  
instruct a message receiver to send additional unsolicited messages  
to other receivers of their choice. To an extent the content of such  
unsolicted messages can also be controlled using reference parameters  
supplied by the initial message sender. Because of these capabilities  
it is essential that communications using WS-Addressing are  
adequately secured and that a sufficient level of trust is  
established between the communicating parties before a receiver  
processes WS-Addressing constructs within a message. There are  
several aspects to securing a message:

(i) EPRs and message addressing properties should be integrity- 
protected to prevent tampering. Such integrity protection might be  
provided by the transport, a message level signature, or use of an  
XML digital signature within EPRs.

(ii) Users of EPRs should only use EPRs from sources they trust. The  
required trust has two aspects:

(a) that the EPR was obtained from a trusted source
(b) that it was obtained from a source with authority to represent  
the [destination] of that EPR.

For example, the receiver of a message might rely on the presence of  
a verifiable signature by a trusted party over the message addressing  
properties to determine that the message originated from a trusted  
source and further require that the [reply endpoint] and [fault  
endpoint] are signed by a principle with authority to represent the  
[destination] of those EPRs to ensure that unsolicted messages are  
not sent. Alternatively an out-of-band means of establishing trust  
might be used to determine whether a particular EPR is trustworthy.

X.X. Additional Security Considerations

To prevent information disclosure, EPR issuers should not put  
sensitive information into the [address] or [reference parameters]  
properties.

Some processors may use [message id] as part of a uniqueness metric  
in order to detect message replay. Care should be taken to ensure  
that, for purposes of replay detection, [message id] is composed from  
data, such as a timestamp, such that a legitimate retransmission of  
the message is not confused with a replay attack. It is also  
advisable to use a [message id] that is not predictable, to prevent  
attackers from constructing and sending an unsolicited reply to a  
message without having to see the actual message.



X. Security Considerations (SOAP Binding)

As discussed in Web Services Addressing 1.0 - Core[WS-ADDR-CORE], WS- 
Addressing supports capabilities that allow a message sender to  
instruct a message receiver to send additional unsolicited messages  
to other receivers of their choice and to control the contents of  
those messages to an extent using reference parameters. The SOAP  
binding of WS-Addressing transforms EPR reference parameters into  
SOAP headers and this allows a message sender to request a message  
receiver to send additional unsolicited SOAP messages to other  
receivers of their choice and to specify a set of SOAP headers that  
must be included in such messages.

SOAP headers are a powerful extension mechanism and therefore great  
care should be taken before honoring a [reply endopoint] or [fault  
endpoint] to avoid inadvertant participation in the activities of  
malicious SOAP message senders.

WS-Addressing message addressing properties serialized as SOAP  
headers (wsa:To, wsa:Action et al.) including those headers present  
as a result of the [reference parameters] property should be  
integrity protected as explained in Web Services Addressing 1.0 - Core 
[WS-Addressing-Core].

Messages that use wsa:ReplyTo or wsa:FaultTo headers whose  
[destination] is not the predefined anonymous URI should include  
claims that allow a receiver to confirm that the EPR was issued by a  
principle with authority to represent the [destination] of the EPR.

When receiving a SOAP message, certain SOAP headers may have resulted  
from the serialization of an EPR's [reference parameters] property. A  
SOAP message receiver should perform additional security and sanity  
checks to prevent unintended actions.

X.X Establishing EPR Trust

There are many mechanisms that could be used to supply proof that a  
message sender has authority to represent the [destination] of EPRs  
supplied within the message. This section defines one such mechanism  
that SHOULD be supported.

When using this mechanism, a message MUST include a WS-Security[WS- 
Security] header that contains XML digital signatures binding the  
wsa:ReplyTo and wsa:FaultTo elements to the SOAP message using an X. 
509 certificate issued by a mutually trusted certificate authority  
(establishment of certificate authority trust is outside the scope of  
this specification) for the domain addressed by the [destination] of  
the EPR. Possession of a certificate signed by a trusted certificate  
authority for the domain addressed by the [destination] of the EPR  
provides a level of confidence that the message sender has authority  
to represent the [destination].

X.X Additional Security Considerations

The wsa:isReferenceParameter attribute is only meaningful on SOAP
headers. Message processors should consider its appearance elsewhere in
a SOAP message as a possible attack.

Message processors should consider elements from the soap11 and soap12
namespace appearing as reference parameters in an EPR as a possible
attack.

<ednote>We should discuss whether WS-Addr elements as reference  
parameters also pose a risk. Certainly being able to include an  
Action, ReplyTo or FaultTo as a ref param seems to open up some  
interesting avenues for attack.</ednote>

There are known XML ID and re-structuring attacks which should be
considered by message processors [ref OASIS WSS 1.1 Plain Brown Wrapper
Attack].

X.X Additional Considerations for SOAP Intermediaries

To avoid breaking signatures, intermediaries MUST NOT change the XML  
representation of WS-Addressing headers when relaying those headers.  
Specifically, intermediaries MUST NOT remove XML content that  
explicitly indicates otherwise-implied content, and intermediaries  
MUST NOT insert XML content to make implied values explicit. For  
instance, if a RelationshipType attribute is present with a value of  
"http://www.w3.org/@@@@/@@/addressing/reply", an intermediary MUST  
NOT remove it; similarly, if there is no RelationshipType attribute,  
an intermediary MUST NOT add one.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.