Updated proposal for lc87 and lc55

Attached below is an updated proposal for issues lc87 and lc55 (the  
nasty security ones ;-)). I've incorporated the feedback from Hugo  
and include two versions of the contentious "Establishing EPR Trust"  
section: one that includes a normative mechanism and one that  
includes the mechanism as an example.

Marc.

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

-- 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 validate the trustworthiness of an EPR  
before using it by considering the two following aspects:

(a) that the EPR was obtained from a trusted source
(b) that it was obtained from a source with authority to represent  
the [address] 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  
[address] 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 [address]  
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 [address] 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

<version number="1" description="with normative mechanism">
There are many mechanisms that could be used to supply proof that a  
message sender has authority to represent the [address] 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 certificate authority trusted by the  
receiver of the message (establishment of certificate authority trust  
is outside the scope of this specification) for the domain addressed  
by the [address] of the EPR. Possession of a certificate signed by a  
trusted certificate authority for the domain addressed by the  
[address] of the EPR provides a level of confidence that the message  
sender has authority to represent the [address].
</version>

<version number="2" description="without normative mechanism">
There are many mechanisms that could be used to supply proof that a  
message sender has authority to represent the [address] of EPRs  
supplied within the message. Typically such mechanisms require the  
inclusion of a WS-Security[WS-Security] header that contains XML  
digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements  
to the SOAP message using a security token issued by an authority  
trusted by the receiver of the message for the domain of the  
[address] of the EPR. Possession of a security token issued by a  
trusted  authority for the domain of the [address] of the EPR  
provides a level of confidence that the message sender has authority  
to represent the [address].

For example, a message could 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 for the domain addressed by the [address] of the EPR. If  
the certificate is issued by a certificate authority trusted by the  
receiver of the message then the receiver can can have some level of  
confidence that the message sender has authority to represent the  
[address] of the EPR.
</version>

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, soap12  
and wsa
namespaces appearing as reference parameters in an EPR as a possible
attack.

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.