Key establishment is essential for many applications of cryptography. Its purpose is to negotiate keys for other cryptographic schemes, usually for encryption and authentication. In a web services context, WS-SecureConversation has been speci ed to make use of negotiated keys. The most popular key establishment scheme in the Internet is the (handshake protocol of the) Secure Socket Layer or Transport Layer Security protocol (SSL/TLS). However, SSL/TLS has primarily been designed to secure HTTP, by encrypting and authenticating TCP connections. It is thus not usable to negotiate keys in SOAP connections with intermediaries. We propose SSL-over-SOAP, a family of key establishment protocols for Web services. It is based the design of the SSL handshake, so security analysis results for standard SSL/TLS apply to our new proposal. We have implemented this protocol in the framework of WS-Trust and WS-SecureConversation.
1.1
Security is important for any distributed computing environment: Many passive and active attacks have been described against such systems. Particularly challenging are service-oriented environments where the architecture is implemented based on a range of technologies, and where applications are created as loosely coupled and interoperable services. The Internet and its underlying infrastructure is the most pervasive IT system ever built|accordingly, more and more applications are implemented as Web services. Thus, preserving the privacy and integrity of these messages in service-oriented architectures becomes a challenging part of business integration, and secure message exchange a requirement for the proliferation of Web services.
Because of the complexity of XML based security standards, the well-known Secure Socket Layer (SSL) or Transport Layer Security (TLS)1 protocol has 1 TLS is the o cial name for the more recent protocol versions in the SSL/TLS family.
We use the traditional name SSL as an umbrella term since our ultimate goal is to move the protocol ideas away from the transport layer. become a de facto security standard for Web services. SSL provides a protected TCP channel that can be used by higher order protocols, such as e.g. SOAP over HTTP for Web Services. Because of its eminent role for the Web (as well as for other Internet protocols), the SSL protocol has been examined intensely [13{15], without nding any severe security aws.
However, classical SSL has some shortcomings when deployed in the context of Web Services. First, SSL is a point-to-point security protocol. Web Services, by contrast, are loosely coupled applications: that is, messages may pass through multiple intermediary nodes, and the bindings to service endpoints may change. In order to establish a secure SSL channel between two service endpoints, each intermediary connection must be protected by SSL, and the application must be able to decide which of the intermediary SSL certi cates are trustworthy. Second, SSL is a transport layer security protocol: SSL-protected messages are secured while in transit on the network; after reception, the message plaintext (as recovered by the SSL layer) is forwarded to the application logic. Third, SSL is not aware of the message structure, so messages are protected in an allor-nothing fashion. Higher layers do not directly bene t from SSL session keys. One bene t of XML security technologies, in contrast, is to provide element-wise signing and encryption: intermediaries can read and alter information only as they are permitted to. 1.2
Consider an example where a business ow requires passing an invoice through multiple parties. The invoice contains some vital information that only the ultimate receiver is allowed read; however, certain parts of the invoice are to be processed by intermediary parties. SSL fails because intermediaries have access to the complete invoice in plaintext (or they would not be able to examine the invoice at all). By contrast, SSL-over-SOAP allows for establishing a session key between sender and ultimate receiver. This key can be used to authenticate and encrypt the invoice information to protect it from intermediaries. The sender can choose which pieces of information to encrypt. 1.3
The WS-* family of security schemes [
In this work, we close this gap by re-specifying the SSL handshake protocol and the SSL record layer at the SOAP level, creating a new cryptographic protocol to be used with WS-SecureConversation. We thus do not need the \classical" SSL at TCP level any more. Instead, we are able to provide all security services o ered by SSL (con dentiality, authentication, security of key establishment) at SOAP level.
Incorporating the practically proven SSL protocol technology into the WS-* family of security scheme allows us to design a protocol framework that bene ts from both technologies.
The main contribution of the SSL protocol to the web services world is
security. In SSL, key agreement and authentication are closely connected, and
explicit key con rmation is provided by the Finished messages at the end of
the handshake protocol. By contrast, it is easy to show the the authenticated
variant of the Di e-Hellman key exchange [
We propose SSL-over-SOAP as the rst member of a family of practical Web Services key establishment protocols. SSL-over-SOAP provides su cient protocol exibility for the security requirements of today's business models. As a rst step, we have implemented the following: { The SSL-over-SOAP handshake protocol is a key transport protocol based on
X.509 binary security tokens. It is implemented in the WS-Trust framework. { The SSL-over-SOAP record layer protects the complete body of SOAP messages, and the Finished messages. It provides con dentiality (XML encryption) and authentication (HMAC from XML signature) within the framework of WS-SecureConversation. 1.4
Hada and Maruyam [
The paper is structured as follows. We shortly review the relevant Web Services technologies in Section 2. Then, we present our proposal by rst formulating SSL in terms of SOAP message exchanges in Section 3, and subsequently describing a concrete instantiation of this framework in Section 4. We discuss the protocol's security in Section 5. Finally, we conclude our work in Section 6. 2 2.1
We use the following XML syntax style: { Instead of writing an element <AAA></AAA>, we drop the tag from the closing bracket and write <AAA></> or <AAA/>. { When writing an element that spans several lines, we rely on indentation to delimit the body, omitting the closing bracket. For example, <AAA><BBB></BBB></AAA> is written as <AAA>
<BBB /> { We omit the namespace de nition in the messages and use the following pre xes:
xenc Pre x
ds soap
tls wsse
Namespace http://www.w3.org/2000/09/xmldsig# http://schemas.xmlsoap.org/soap/envelope/ http://www.example.org/tls# http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd wst http://schemas.xmlsoap.org/ws/2005/02/trust wsc http://schemas.xmlsoap.org/ws/2005/02/sc wsu http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd http://www.w3.org/2001/04/xmlenc# 2.2
SOAP is a mechanism for inter-application communication between systems across the Internet, where system implementations can be written in arbitrary languages. SOAP messages are in XML to allow the exchange of structured information.
WS-Security [
<w s s e : S e c u r i t y /> <s o a p : Body> 2.3
WS-SecureConversation (the Web Services Secure Conversation Language) speci es secure communication between services. It de nes the message structure for establishing and sharing security contexts, and for deriving keys from security contexts. As with WS-Security, WS-SecureConversation is only a building block and does not provide a complete security solution.
The core element of WS-SecureConversation is the <wsc:SecurityContextToken> element. It consists of the mandatory child element <wsc: Identi er > and several optional elements. The security context is addressed by a UUID speci ed in <wsc: Identi er >. 2.4
WS-Trust enables applications to construct trusted SOAP message exchanges, which is determined by security tokens. A typical security token request consists of: <wst : R e q u e s t S e c u r i t y T o k e n Context ? . . . > <wst : TokenType/>? <wst : RequestType/> . . .
The optional element <wst:TokenType> describes the requested token type. The mandatory element <wst:RequestType> speci es the class of function. It allows to add additional elements for the special purpose. The <wst:RequestSecurityTokenResponse> speci es the response to a security token request and is used to retrieve a security token. 3 3.1
We lift the SSL framework from the transport layer to the world of Web Services,
using the WS-* framework. We use SOAP instead of TCP for handshake
messages transfer. WS-Trust and WS-SecureConversation provide the framework to
describe handshake protocol messages, and WS-Security allows us to put
security related metadata into the <Security> header element. Our speci cation of
SSL-over-SOAP complies with the recent version of SSL, namely TLS 1.1 [
For the handshake protocol, we put the handshake messages into payloads of the SOAP exchange, such that all elements are contained in the body part of the SOAP message|never in the header. This is important to allow us to duplicate the renegotiation feature of the original SSL protocol: An SSL handshake can also be carried out over a connection that is already protected using SSL/TLS (for example, to transfer client certi cates in encrypted form). In the case of SSLover-SOAP, this means that we want to be able to apply WS-Security and WSSecureConversation even to those SOAP messages constituting a new handshake. In such a situation, the cryptographic parameters used in the WS-Security header stem from the original session, while the parameters of the next session are negotiated using the handshake protocol.
Additionally, we de ne how the Finished message is generated. In the SSL/TLS standards, this is done by computing a pseudorandom function taking as input the exchanged secret and a concatenation of all message bytes exchanged for the current handshake, and then sending this message over the new cryptographically secured channel. Such authentication is important to thwart man-in-the-middle attacks: If an attacker has modi ed some handshake message to in uence parameter negotiation, then verifying the peer's Finished messages will reveal that something is wrong (assuming that only ciphersuites providing reasonably strong authentication are ever negotiated).
In SSL-over-SOAP, we use the same pseudorandom function for the Finished message. Its inputs are the new master secret and the concatenation of the (serialized canonicalized) bodies of the SOAP messages for the handshake. Putting parts of the handshake messages into the SOAP header instead of the body might make the protocol vulnerable to attacks, or could lead to a much more complex computation of the Finished message (see Section 5 for more discussions). 3.2
For convenience, we will refer to the initiating service as \client" and to the responding service as \server", thus adopting SSL terminology. In SSL-over-SOAP, the initial message is the ClientHello (Fig. 1). Using the framework of WSTrust, we embed the messages into the <wst:KeyExchangeToken> within the <wst:RequestSecurityToken> element. The <wst:RequestKET> indicates that an additional message from the server is required to complete the key establishment. The <wst:RequestSecurityToken> has an attribute @tls:Id with a UUID value so that we can reference to this message later.
The <tls: ClientHello> speci es the SSL version of the client (<tls:Version>), the ciphersuites (<tls:CipherSuites>) and compression methods (<tls:CompressionMethods>) as well as the client's nonce (<wst:Entropy>). The version number 3.2 indicates that TLS version 1.1 is used [6, Section 6.2.1]. While the ciphersuite in SSL is identi ed by two bytes, it is identi ed here by a URI. For example, the ciphersuite TLS RSA WITH AES 256 CBC SHA-1 is identi ed by http://www.example.org/tls#tls RSA with AES256 SHA-1. The second message is the server's response to the security token request (Fig. 2). The response contains mandatory and optional elements. As with SSL, the choice of elements depends on the ciphersuite selected (<tls:ServerKeyExchange>) and on whether the server requests client authentication (<tls:CertRequest>).
<tls:ServerHello> contains the SSL protocol version of the server (<tls:Version>), the session ID (<tls:SessionID>), the ciphersuite selected by the server (<tls:CipherSuite>), the compression method (<tls:CompressionMethod>), and the server nonce (<wst:Entropy>). The session ID is adopted from SSL to manage the session and used to execute the abbreviated handshake.
Fig. 2 illustrates an example message where client and server are mutually authenticated on the basis of X.509v3 Certi cates. Such certi cates are handled by including a <wsse:BinarySecurityToken> into the <tls: Certi cates > element. The type X509PKIPathv1 indicates that this token speci es a certi cate chain.
<tls:ServerKeyExchange> would contain key material for DH key exchange. In Fig. 2, client and server opt for key transport based on RSA where the server's public key is provided by the certi cate. Hence, <tls:ServerKeyExchange> is an empty tag, and could be omitted.
The <tls:Certi cateRequest> element is used to signal the client that is has to authenticate using a X.509 security token. The tag contains security policies which specify the client certi cate's requirements. In Fig. 2, the server requires client authentication and opts for a client certi cate that is issued for RSA signatures from the Certi cate Authority Test Root CA.
The SSL/TLS message ServerHelloDone serves only as a delimiter. We omit ServerHelloDone in SSL-over-SOAP, since we combine multiple SSL elements into one <wst:KeyExchangeToken>.
Here the message structure becomes a little more complicated, since we have to combine unprotected parts (ClientKeyExchange, Certificate, CertificateVerify) and protected parts (Finished) into one SOAP message in order to comply with the SSL protocol speci cation (Fig. 3).
The <tls:PreMasterSecret> (lines 34{37) within <tls:ClientKeyExchange> (lines 33{37) contains the encrypted premaster secret (recall that client and server negotiated the RSA ciphersuite). The premaster secret is encrypted with the server's public key. Since client authentication has been requested in the previous message, the client makes use of the <tls: Certi cates > element (lines 38{40) to send a certi cate chain containing its certi cate and the certi cation authority's certi cates. The <tls: Certi cateVerify > (lines 41{50) has only one child element, <ds:Signature> (lines 42{50). For more details, see Section 4. The <ds:Reference> elements in lines 46{47 reference the exchanged messages (messages 1 and 2) via the @URI with the pre x urn:uuid. The last two <ds:Reference> elements in lines 48{48 reference the <tls:ClientKeyExchange> (lines 33{37) and the <tls: Certi cates > (lines 38{40) in the same message. The <wst:SecurityContextToken> (lines 28{29) speci es that the master secret should be addressed by the UUID speci ed, UUID-sct.
After choosing a premaster secret, the client computes the master secret and derives the session keys. In order to con rm the correct generation of session keys, it computes the content Finished message as follows: client nished = PRFmaster secret \client finished";
MD5 (exchanged messages) jj SHA1 (exchanged messages) [0:::11] In the SSL framework, the exchanged messages are those visible at the handshake layer and do not include record layer headers. Hence in SSL-over-SOAP, the exchanged messages are the SOAP bodies in messages 1 and 2, and the SOAP body except the <tls:Finished> in this message. The SOAP bodies are rst canonicalized with the algorithm Exclusive C14N and then concatenated. The result is then used as the input of the hash algorithms MD5 and SHA-1.
The client then constructs the Finished message by encoding the result of the TLS PRF: <tls:Finished>Base64(client nished)</>. The <tls:Finished> is then encrypted and signed in the following way:
The client inserts a <wsse:Security> (lines 3{23) into the SOAP header <soap:Header>. Then, the client adds a <wst:SecurityContextToken> (lines 4{ 5) to <wsse:Security>. This token has the same properties as the token within the SOAP body (lines 28{29). However, we may not move this security token to the body, since only if it is located in the SOAP header, the token can be used for decryption and signature veri cation. Then, the client computes a derived key token <wsc:DerivedKeyToken> that speci es the client write key, and is used to encrypt the content of <tls:Finished> (lines 51{56).The <wsc:DerivedKeyToken> (lines 17{21) and a new <xenc:ReferenceList> (lines 22{23) that locates the encrypted <tls:Finished> are then added to the <wsse:Security> element. Finally, the client computes a derived key token <wsc:DerivedKeyToken> (lines 6{10) that speci es the client write MAC secret used to sign the encrypted <tls:Finished> with the client MAC secret. The signature is represented by a <ds:Signature> (lines 11{16). Both elements are then added to the <wsse:Security>.
Note that in message 3 and in message 4 (see Sect. 3.5), the session ID is added to the <wst:KeyExchangeToken> so that the receivers (the server in message 3 and the client in message 4) can chain the messages. 3.5
The server's <wst:RequestSecurityTokenResponse> contains the <tls:Finished> message (see Fig. 4). To compute the content of the Finished message, the server uses the same PRF function as the client except the following di erences: 1) the label is \server nished"; 2) for the exchanged message, we refer to the SOAP bodies in messages 1, 2 and 3. In the SSL framework, the headers in the record layer are not considered, hence we rst decrypt the message 3 and use the decrypted SOAP body (namely the <tls:Finished> is not encrypted).
The message allows the client to verify that the server has received all the previous messages from the client. As with the previous message, the server's Finished has the same SOAP header structure, but di ers in the keys used, i.e. the server uses server write MAC secret for the HMAC and server write key for the encryption.
1 <s o a p : E n v e l o p e>
2 <s o a p : H e a d e r>( S i m i l a r as i n Message 3 )</>
3 <soap:Body>
4 <w s t : R e q u e s t S e c u r i t y T o k e n R e s p o n s e>
5 <wst:TokenType> . . . / t r u s t /KET</>
6 <w s t : R e q u e s t e d S e c u r i t y T o k e n>
7 <wst:KeyExchangeToken>
8 <t l s : S e s s i o n I D>Vz2e . . . 4WU=</>
9 < t l s : F i n i s h e d w s u : I d= ' Id F i n i s h e d 2 '>
10 <xenc:EncryptedData Id= ' Id EncFinished2 ' />
We present additional details for a concrete Web Services protocol that
instantiates the framework described in the previous section. Speci cally, we show a
protocol variant using X.509 certi cates as security tokens. The framework can
similarly be instantiated using other security token types, requiring other
protocol variants: for example, password-based authenticated key exchange using a
scheme such as \SOKE" [
The X.509v3 binary token authentication protocol is illustrated in Fig. 5. The protocol's goal is to negotiate a tuple of session keys between two services W1 and W1, while the services authenticate on the basis of X.509v3 binary tokens. Assuming that in a setup stage the tokens have been stored in credential stores. We denote the certi ed public pairs of W1 and W2 by (pk1; sk1) and (pk2; sk2), respectively.
W1 initiates the handshake. It randomly chooses a client nonce N1 and forwards this parameter to W2. Then, W1 chooses a nonce N2 and appends to the nonce its certi ed public key pk2. Upon receiving the message, W1 randomly chooses a premaster secret kPMK and encrypts the premaster secret with the public key pk2 from W2. The premaster secret kPMK is used to derive the master secret kMSK, using the pseudo-random function PRF parameterized by the services' nonces and the labeling string \master secret", abbreviated with \1" in the protocol description. This is the pseudorandom function as speci ed by SSL. (Other PRF constructions could be used.)
W1 applies the master secret kMSK to compute the tuple of session keys kENC; kMAC; k2ENC; k2MACg. Here kiENC and kiMAC are encryption and authentication keys, f 1 1 respectively. W1 feeds the pseudorandom function PRF with the labeling string \key expansion" and the concatenation of the services' nonces N1 and N2. In addition, W1 proves its identity by signing the digest of previously negotiated messages SIG1 using its certi ed private key sk1. Finally, W1 con rms the session key generation, using the pseudorandom function PRF that takes as input the master secret kMSK, the string \client finish" and the hash value H1 of all previous messages. It then authenticates and encrypts the output F1 with the session keys fk1ENC; k1MACg.
Upon receiving the message, W1 decrypts the premaster secret and veri es SIG1, using the client's certi ed public key pk1. It ensures that it is connected to W1, i.e. it checks that W1 is a valid endpoint. Otherwise W2 aborts the session. In the positive case, W2 derives in analogy to W1 the same master secret kMSK and the same tuple of session keys fk1ENC; k1MAC; k2ENC; k2MACg. Then, W2 decrypts EkENC (F1; t1) and veri es that tag t1 := HMACkMAC (F1), where F1 is the hash over 1 1 all previous messages. If this veri cation fails, W2 aborts the protocol. Otherwise, W2 con rms the negotiated session keys using the pseudorandom function PRF that takes as input the master key kMSK, the labeling string \server nish", and the hash value over all previous messages H2. It then authenticates and encrypts the output F2 with the session keys fk2ENC; k2MACg.
Finally, when W1 receives the message EkENC (F2; t2), it decrypts the message 2 and veri es that tag t2 := HMACkMAC (F2), where F2 is the hash value of all pre2 viously received messages. If the veri cation fails, W1 aborts the session. OthkENC; k1MAC; k2ENC; k2MACg for erwise, W1 and W2 start to use the negotiated keys f 1 symmetric cryptography. 5
Although our SSL-over-SOAP protocol on the outside looks very di erent from standard transport-layer SSL/TLS, the handshake quite closely follows the original protocol. We have replaced the SSL/TLS data formats using an XML-based approach, but without changing the cryptographic essence. Thus, previous analyses of the SSL/TLS handshake as appearing in [13{15] apply similarly: the long experience with SSL/TLS provides evidence that our proposal is cryptographically sound as well.
To get a feel for the cryptographic approach in these protocols (both the original SSL/TLS and our SSL-over-SOAP), observe that most of the handshake negotiation is not cryptographically authenticated immediately. Besides signatures in certi cates, authentication appears only in the form of digital signatures if either a ServerKeyExchange message is used (the server signs its key share along with the client and server random nonces, thus binding the key share to the current handshake), or if a CertificateVerify message is used (in which the client presents a signature on the handshake so far to authenticate itself to the server).
Many typical scenarios involve neither message. An attacker can manipulate the handshake protocol messages being exchanged to in uence the handshake outcome: For example, if the client o ers multiple ciphersuites in the ClientHello message, an attacker could remove the client's preferred ciphersuites from the list, leaving the server with fewer ciphersuites to choose from| such as just those ciphersuites that are the easiest to break. This changes only in the moment when the Finished messages are exchanged. These messages cover the complete handshake as well as the resulting master secret, thus retroactively authenticating everything in the current handshake, provided that the master secret could only be known to the legitimate protocol participants. (For example, in an RSA-based handshake, the client encrypts the premaster secret for the server's certi ed public key, thus ensuring that the premaster secret and thus the master secret remains secret from any attacker.) Accordingly, it is a fundamental security requirement the any party engaging in a handshake only be willing to negotiate ciphersuites that can be assumed to provide security in this sense. Any further security properties, notably those of application data encryption, rely on this.
The Finished message is the rst piece of data to be encrypted and authenticated under the newly negotiated keys and algorithms, thus also providing a veri cation that negotiation succeeded as intended and that both parties now are indeed using compatible cryptography. Once the Finished messages have been veri ed, application data is encrypted and authenticated the same way. In the standard SSL/TLS protocol, symmetric authentication is added to the plaintext before encryption.
This is done di erently in our SSL-over-SOAP setting (see Fig. 3), where
symmetric authentication (following the XML Digital Signatures speci cation)
is applied to the ciphertext. This change is not cryptographically trivial, but
does not harm the protocol. The combination of symmetric authentication with
encryption can be considered authenticated encryption [
The SSL-over-SOAP approach provides a practical framework for key establishment for Web Services. We use the experience with the practically proven SSL/TLS protocol family for this purpose. This allows us to transfer SSL/TLS protocol ideas to reuse them for Web Services, while giving us much more exibility and security than direct use of SSL/TLS at the transport layer. Our prototype implementation has shown the feasibility of implementing complex cryptographic protocols within the WS-* framework.
In this paper, we only looked at one basic form of an SSL handshake as an
example|an RSA-based handshake (involving an encrypted premaster secret).
The SSL-over-SOAP approach applies to many more protocol variants. For
example, we can directly transfer the work that has been done in [
Our experiences with SSL-over-SOAP should be considered as a starting point for the de nition of other key agreement protocols, e.g., the IPsec OAKLEY protocol, or group key agreement protocols. However, security analyses of such protocols can not be directly transferred to the web services world, e.g. considering XML wrapping attacks. Necessary conditions for key agreement protocols to be secure in an XML context (e.g. explicit key con rmation) have to be researched.