- From: Bob Freund <bob.freund@hitachisoftware.com>
- Date: Mon, 18 Jul 2005 16:02:48 -0400
- To: "'Marc Hadley'" <Marc.Hadley@Sun.COM>, <public-ws-addressing@w3.org>
- Message-ID: <E1DubpM-0004bM-KJ@maggie.w3.org>
The following should be added to introduce security the text below: No assumptions are made herein of the application level security requirement, the organization of the application, implementation of senders or receivers, or of the ways that other protocols may make use of WS-Addressing, and what security mechanisms they may employ. A holistic approach to security which considers all components of the application, other protocols utilized, the way that these protocols compose with WS-Security, and the use of other methods or additional techniques is highly recommended. -bob -----Original Message----- From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley Sent: Friday, July 15, 2005 5:05 PM To: public-ws-addressing@w3.org Subject: 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.
Received on Monday, 18 July 2005 20:35:53 UTC