Web Services Goodness (WS-Goodness)

April 1, 2003

Authors

Aleksander Slominski, IU Extreme! Lab (Editor)
Kenneth Chiu, IU Extreme! Lab

Copyright Notice

Copyright 2003 by Indiana University Extreme! Lab  All rights reserved.

Indiana University Extreme! Lab (collectively, the "Authors") hereby grant you permission to copy and display the WS-Goodness Specification, in any medium without fee or royalty, provided that you include the following on ALL copies of the WS-Goodness Specification, or portions thereof, that you make:

1. A link or URL to the Specification at this location

2. The copyright notice as shown in the WS-Goodness Specification.

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

THE WS-GOODNESS SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE WS-GOODNESS SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE WS-GOODNESS SPECIFICATION.

The WS-Goodness Specification may change before final release and you are cautioned against relying on the content of this specification.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the WS-Goodness Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Abstract

Since beginning SOAP has been used as a mean to bypass firewalls. However there is currently no mechanism to indicate what content is safe to pass through firewall and what content should be marked as not be allowed to pass. WS-Goodness provides a transport-neutral and Web services specific mechanisms to indicate which SOAP messages have malicious intent and which are merely unusual.

Status

WS-Goodness and related specifications are provided as-is and for review and evaluation only. IU Extreme! Lab hopes to solicit your contributions and suggestions in the near future. IU Extreme! Lab makes no warrantees or representations regarding the specifications in any manner whatsoever.

Table of Contents

1. Introduction

   1.1. Notational Conventions

   1.2. Namespaces

2. Message Header

   2.1. Message Header XML Infoset Representation

3. Processing Model

4. Security Considerations

5. Acknowledgements

6. References

1. Introduction

Since beginning SOAP has been used as a mean to bypass firewalls. However there is currently no mechanism to indicate what content is safe to pass through firewalls and what content should be stopped. WS-Goodness provides a transport-neutral and Web services specific mechanisms to indicate which SOAP messages have malicious intent and which are merely unusual. Web Services Goodness (WS-Goodness) defines a simple mechanism that can be used to indicate intent of the message. This is solves hard problem of determining which messages are malicious and which are safe to pass around.  This mechanism and WS-Goodness specification is logical extension of already mechanism of SOAP Action that is used to indicate intent of message.

Recent work related IPv4 in RFC3514 [1] addresses this issue but we think that it is necessarily to apply end-to-end principles to this problem and put appropriate header in SOAP envelope. Moreover putting it at the packet level seems to complicate intermediaries.

Specifically, this specification defines SOAP header that is known as the "evil" header. Benign messages does not have this header and those that are dangerous are required to have this header set. This header enables messaging systems to support detection of message goodness that are transmitted through multiple processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.

The following example illustrates the use of this mechanisms in a SOAP 1.2 message:
(001) <S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"
         xmlns:ge="http://www.extreme.indiana.edu/xgws/schemas/2003/04/goodness">
(002)   <S:Header>
(003)     <ge:evil S:mustUnderstand='true' />
(004)   </S:Header>
(005)   <S:Body>
(006)     ...
(007)   </S:Body>
(008) </S:Envelope>

Lines (002) to (004) represent the header of the SOAP message where the mechanisms defined in the specification are used. The body is represented by lines (005) to (008).

Line (003) contains the message information header blocks that specifies that this packet has an evil intent. Secure systems are required to defend themselves against such messages.

1.1. Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].

When describing abstract data models, this specification uses the notational convention used by the XML Infoset [3]. Specifically, abstract property names always appear in square brackets (e.g., [some property]).

1.2. Namespaces

This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

Prefix Namespace
S http://www.w3.org/2002/12/soap-envelope
ge http://www.extreme.indiana.edu/xgws/schemas/2003/04/goodness
xs http://www.w3.org/2001/XMLSchema

Table 1 Prefixes and Namespaces used in this specification

WS-Goodness is defined in terms of the XML Information Set [3]. WS-Goodness is conformant to the SOAP 1.2 processing model; SOAP 1.2 is not a requirement for using the constructs defined in this specification. WS-Goodness is also designed to be able work with WSDL 1.1 described services. The examples in this specification use an XML 1.0  representation but this is not a requirement.

All information items defined by WS-Goodness are identified by the XML namespace URI [6] "http://www.extreme.indiana.edu/xgws/schemas/2003/04/goodness". A normative XML Schema document can be obtained by dereferencing the XML namespace URI.

2. Message Header

This section defines the model and syntax of a message header. The header should be processed as first header however as currently there is no mechanism in SOAP to specify order in which headers are processed RECOMMEND that "evil" header is first header as typical SOAP processors process headers in order they are present in Header information item.

The message header block provide end-to-end safety characteristics of a message. The presence of it indicates that goodness/evilness message information is present and should be used to guide how message should be processed.

2.1. Message Header XML Infoset Representation

The following describes the contents of the message information header blocks:

  <ge:evil strength='xsd:float'? S:mustUnderstand='true' />

Every evil header MUST have attribute item mustUnderstand with value of true.

We believe that just good/evil doesn't give enough flexibility. Since we are using SOAP, we have a lot more than 1 bit. We suggest more than good/evil is needed than is available only in RFC 3514 [1].  Therefore it is possible to use optional attribute strength to indicate how evil is packet. Values bigger than 100.0 are reserved and MUST NOT be used (especially "Inf" MUST NEVER be used as it may confuse SOAP processing nodes that are not a completely interoperable  implementations of SOAP processor as described in [4]). Value of zero indicates that message is not neutral and it was not yet determined whether it is good or evil. This value SHOULD not be used and it SHOULD be regarded as if message is slightly evil (as it is not good).

Value of 50.0 or more indicates that message is mischievous and SHOULD be dealt with utmost caution.

If negative value is use then packet MUST be interpreted as good and strength represent how good packet is. However this mechanism SHOULD not be overused as it is generally confusing.

3. Processing Model

Intermediaries such as firewalls and SOAP processing intermediary nodes MUST drop all inbound messages that have evil message header. If message evilness strength is greater than 50.0 it is advised to deal with message using utmost precautions and quarantine message from possibly interfering with any part of processing unit. If evil strength is negative message MUST be assumed to be good.

Messages that has no evil header MUST NOT be dropped and assumed to be good. This behavior is backward compatible with existing SOAP processors.

4. Security Considerations

Even if current SOAP processor is not recognizing evil header (and its strength) as message is marked mustUnderstand then following SOAP specification rules it MUST drop message. However due to the fact that processing order of SOAP headers is not specified it is possible that some header MAY have affected processing node therefore it is RECOMMENDED that SOAP processing nodes that does not understand evil header are not trusted and if possible isolated from processing nodes that understand evil header to preserve properly message goodness.

To enable correct and expected behavior it is critical that this header is used correctly. If faulty processing components do not set it correctly then firewalls will not be able to do their job correctly. If header is used when it shouldn't be then denial of service condition may occur.

5. Acknowledgements

Madhusudhan Govindaraju, Octav Chipara IU Extreme! Lab, and Steven M. Bellovin for writing RFC 3514 that was inspiration for this WS-spec and other authors of WS-specifications that showed how easy is to write new WS-spec..

6. References

  1. S. Bellovin, "The Security Flag in the IPv4 Header" RFC 3514, AT&T Labs Research, April 2003
  2. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997
  3. W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001 (see "http://www.w3.org/TR/2001/REC-xml-infoset-20011024/")
  4. Essay "To infinity and beyond - the quest for SOAP interoperability" written by Sam Ruby (see: http://www.intertwingly.net/stories/2002/02/01/toInfinityAndBeyondTheQuestForSoapInteroperability.html)