SOAP Security Extensions

1 Introduction

2 Why Message Layer Security?

First of all, one may ask: "Why do we need the SOAP layer security? Don't we already have transport layer security mechanisms such as SSL/TLS and IPSec? Or should applications be responsible for security?" This section describes several scenarios in which the security provided by the transport layer security is not sufficient or the SOAP layer security is useful for application developers.

1. End-to-end Security

   SOAP can be used in combination with a variety of transport protocols such as HTTP and SMTP. Regardless of the protocol to which SOAP is bound, a SOAP message travels from the originator to the ultimate destination, potentially by passing through a set of intermediaries along the message path (Figure 1). An intermediary is an application that is capable of both receiving and forwarding SOAP messages. When an intermediary receives a SOAP message, it processes header entries intended for it and must remove them before forwarding the message. It may also insert a similar header entry intended for another intermediary. The "actor" attribute of a header entry can be used to indicate the URI of an intermediary who will process the header entry.

   Secure transport protocols such as SSL/TLS can assure the security of messages during transmission. However, since messages are received and processed by intermediaries, secure end-to-end communication is not possible if these intermediaries are not completely trusted even though the communication links between them are trusted. End-to-end security is also compromised if any one of the communication links is not secured.

2. Application Independence

   End-to-end security ultimately needs to be achieved at the application level. This is because if there is any point between the communicating parties where messages are in plain text, it can be a potential point of attack. However, it is not an easy task to integrate cryptographic functionality into an application without introducing additional security vulnerabilities. It is true that a number of commercial cryptographic libraries are available, but usually they are extremely flexible to meet many different levels of security requirements, and using them properly may require good understanding of cryptographic technologies. A standardized, application-independent security layer will provide good protection without worrying about cryptographic details. It is thus desirable, in most cases, to have security functionality as close to the application level as possible but not built into the application itself.

3. Transport Independence

   Consider Case II of Figure 1, in which not all of the connections are via HTTP. One of the intended uses of SOAP intermediaries is to forward messages to different networks, often using different transport protocols. Even if all the communication links are secured and the intermediaries can be trusted, security information such as the authenticity of the originator of the message needs to be translated to the next secure transport protocol along the message path, which could be tedious and complex, which may lead to security breaches. Therefore, it is important to deal with the security issues at the message layer independently of the transport layers.

   
   Figure 1. When intermediaries are present

4. Security of Stored Messages

   Transport layer security is to secure data when it is traveling on communication links. It has no effect on stored data. Once a transmission is received and decrypted, transport layer security does not help much in protecting the data from illicit accesses and alterations. In situations where messages are stored and then forwarded, message layer security is necessary. Note that in real business-to-business applications messages are often stored for logging and auditing purposes. Having cryptographic protection on such persistent data may be necessary anyway, and the SOAP security extensions proposed here can be used for this purpose as well.

In the next two subsections, we describe two business-to-business scenarios where security at intermediaries makes sense.

Receiver-Oriented Scenario

In this scenario, we suppose that the ultimate destination does not want to take responsibility for security issues, but wants to guarantee that the originator is authorized and that the message is not modified in transit. For this purpose, an intermediary may process all security-related data. The originator simply asks the intermediary to forward the message to an appropriate destination. The dispatching mechanism, i.e., which message should be sent to which destination, may depend on the content of the SOAP Body. Note that the originator does not need to know the ultimate destination (the ultimate destination 1, 2, or 3). The intermediary can check, (1) whether the originator is authorized to send the message or to benefit from a specific service, and (2) whether or not the message modified in transit.

The SOAP layer security mechanism would help programmers develop such an intermediary rapidly and securely. If such a system is not available, application developers must program some security mechanism by themselves, which will result in bugs and security holes.

Figure 2. Receiver-Oriented Scenario

Sender-Oriented Scenario

This is the opposite of a receiver-oriented scenario, where the originator does not have to handle the security issues. As in the previous scenario, the originator simply asks an intermediary to process its security information and forward the message to the ultimate destination. The intermediary may encrypt or sign the SOAP message. Again, the SOAP layer security would help programmers develop such an intermediary rapidly and securely.

Figure 3. Sender-Oriented Scenario

3 Security Requirements

Our goal is to secure the entire SOAP message including the SOAP Headers and the SOAP Body.

In general, we have five security requirements for message transmission:

• Confidentiality guarantees that an eavesdropper can not read the message.
• Authorization guarantees that the sender is authorized to send a message.
• Data integrity refers to assurance that the message was not modified accidentally or deliberately in transit.
• Message origin authentication guarantees that the message was transmitted by a properly identified sender and is not a replay of a previously transmitted message.
• Non-repudiation guarantees that the sender of the message can not deny that he/she has sent it.

4 Defining SOAP SecTags

In order to satisfy the five security requirements described at the beginning of Section 3, we discuss three technologies (encryption, digital signature and authorization) in more detail from the perspective of SOAP.

4.1 Encryption

4.2 Digital Signature

Theses examples show how to add a MAC or a digital signature to a SOAP message. A signer who is either an originator or an intermediary may perform the signature generation process.

4.3 Authorization

Attribute certificates may be added within the SOAP envelope by either an originator or an intermediary.

The following is an example for authorization.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Authorization 
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/" 
      SOAP-ENV:actor="a URI of an actor"
      SOAP-ENV:mustUnderstand="1">
      <AttributeCert 
        xmlns="http://schemas.xmlsoap.org/soap/security/AttributeCert">
        A BASE64 encoded attribute certificate is here.
        If necessary, it should be encrypted using the specified actor's public key.
      </AttributeCert>
     </SOAP-SEC:Authorization>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
     <m:GetLastTradePrice xmlns:m="some-URI">
       <symbol>DIS</symbol>
     </m:GetLastTradePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4. 4 Notes

The key management for these SecTags is an important issue, but is not mentioned in this document.

The SOAP layer security does not depend on any transport layer, nor on higher any application layer. However, it is still true that more secure and practical solutions are possible by combining the SOAP layer security with some transport layer security and some application layer security.

When an originator and several intermediaries will add several SecTags to the same message, problems may appear. Below we give a few scenarios. Application designers should be careful about these problems at design time.

Consider a connection in which two intermediaries A and B forward messages in order. Assume that the originator and B shares a secret key K1 and that A and the ulitimate destination shares a secret key K2. The originator encrypts an element by K1 and sends it to A. A encrypts the encrypted element by K2 and sends it to B. In this case, the ultimate destination cannot retrieve the original element unless it knows the secret key K1.

The order of signature generation and encryption processes matters when the originator and several intermediaries will add both encryption and signature SecTags. If they are processed in an inappropriate order, the signature validation may fail. For example, the following order is inappropriate: The originator first adds a MAC intended for an intermediary and then encrypts the body using a secret key shared between the originator and the ultimate destination. In this case, the intermediary cannot validate the MAC because the body cannot be decrypted except by the ultimate destination.

Another example of failure is the case where the originator signs a header entry. The originator signs a header entry intended for an intermediary and adds the signature as a separate header entry intended for the ultimate destination. If the intermediary receives the message, processes the header entry, and remove it, the ultimate destination cannot validate the signature.

For authorization, anyone can add any number of attribute certificates regardless of any other already added SecTags. This is because the authorization SecTags have no effect on other SecTags.

5 Sample Application

In this section, we give a sample application using the signature SecTags. We will consider the following scenario: A client of Company A sends a purchase order to Shop-IBM. In this transaction, they want their respective gateways to generate (or validate) a signature.

Figure 4. Purchase Order: From Company A to IBM

1. An originator in the Company A requests the security gateway to sign the body and forward it to Shop-IBM (the IBM Gateway). The <SignatureRequest> element indicates the id of the element which is to be signed.

   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <delivery> <send-to>IBM Corp., Shop-IBM internet shop</send-to> <URL>http://www.ibm.com/shop/</URL> </delivery> <SignatureRequest actor="http://company-A.com/Gateway/"> <Reference URI="#Body"/> </SignatureRequest> </SOAP-ENV:Header> <SOAP-ENV:Body id="Body"> <PurchaseOrder> <PurchaseLineItems> <Order> <Product>Think Pad 560</Product> <Quantity>100</Quantity> </Order> </PurchaseLineItems> </PurchaseOrder> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

2. The Company A Gateway, the actor specified in the <SignatureRequest> element, signs the body and send it to the gateway of IBM.

   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <delivery> <send-to>IBM Corp., Shop-IBM internet shop</send-to> <URL>http://www.ibm.com/Gateway/</URL> </delivery> <!-- Signature request is replaced by signature SecTag. --> <!-- The details are omitted. --> <SOAP-SEC:Signature actor="http://www.ibm.com/Gateway/"> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:Reference URI="#Body"> </ds:SignedInfo> <ds:SignatureValue>E739AK3KD3..</ds:SignatureValue> </ds:Signature> </SOAP-SEC:Signature> </SOAP-ENV:Header> <SOAP-ENV:Body id="Body"> <PurchaseOrder> <PurchaseLineItems> <Order> <Product>Think Pad 560</Product> <Quantity>100</Quantity> </Order> </PurchaseLineItems> </PurchaseOrder> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

3. At the IBM gateway, the signature is verified and the certification information (e.g., originator id) is extracted and added within the SOAP message.

   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <delivery> <send-to>IBM Corp., Shop-IBM internet shop</send-to> <URL>http://www.ibm.com/shop/</URL> </delivery> <SignatureVerified> <CertificationInfo> <SubjectName>Company A, Inc.</SubjectName> <IssuedBy>Verisign Inc. Class 3 CA</IssuedBy> <ExpirationDate>20030503</ExpirationDate> </CertificateInfo> <CustomerInfo class="Premier-A"/> <CRLChecked>yes</CRLChecked> </SignatureVerified> </SOAP-ENV:Header> <SOAP-ENV:Body id="Body"> <PurchaseOrder> <PurchaseLineItems> <Order> <Product>Think Pad 560</Product> <Quantity>100</Quantity> </Order> </PurchaseLineItems> </PurchaseOrder> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

6 References