Web Services and PKI

W h i t e P a p e r

Web Services and PKIThe How and Why

L a y e r 7 T e c h n o l o g i e s

W h i t e P a p e r

Web Services and PKI

L a y e r 7 T e c h n o l o g i e s

W h i t e P a p e r


Copyright © 2010 Layer 7 Technologies Inc. All rights reserved.

trademarks of Layer 7 Technologies Inc.

Contents

Introduction ................................................................

Channel vs. Message Security ................................

The Challenge with Message Security

Web Services Security Requires PKI

An Example of PKI in Web Services

Conclusion ................................................................

About Layer 7 Technologies ................................

Contact Layer 7 Technologies ................................

Legal Information ................................

ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are

trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights are the property of their respective

................................................................................................

................................................................................................

e Security ................................................................................................

................................................................................................

An Example of PKI in Web Services ................................................................................................

................................................................................................

................................................................................................

................................................................................................

................................................................................................................................

SecureSpan and the Layer 7 Technologies design mark are

yrights are the property of their respective owners. 2

.................................................. 3

....................................................... 3

.......................................... 4

.............................................. 4

........................................... 4

..................................................... 6

.......................................................... 7

....................................................... 7

.......................................... 7




Introduction Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and

maintain, the technology has been plagued with criticism since it first appeared. To the dismay of many CIOs, few

applications have attempted to effectively use PKI. This may soon change.

that demands the flexibility that only an enterprise PKI deployment can offer.

Channel vs. Message SecurityIf one were to lump all of the existing production

security models, some interesting trends would arise. First, many do not address security at all. This is probably

due to the relative immaturity of the Web services technology rather than a developer over

of the remaining applications delegate security entirely to Secure Sockets Layer (SSL) or a Virtual Private Network

(VPN) connection.

SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay

a server-side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server

authentication and protecting against impersonators and most man

rely on the integrity of the DNS system, it

side certificate authentication that, though powerful, is rarely implemented.

Channel continuity is probably the most unheralded quality of SSL. Once a session is set

up, and the client and server mutually authenticate (with the client using a certificate

under SSL, or via HTTP authentication, or an

level of trust is established on the open socket so that it is available for multiple

transactions without requiring re

maintained security context is easy to take

Of course, one of the reasons behind SSL’s success on the Web was that, although it

utilizes public key cryptography, it does not need full

servers use certificates issued by the “browser cartel”. Those

fortunate enough to have their root cer

store of the most popular browsers. With the exception of a few early consumer banking products that have now

been abandoned, almost nobody provides the baroque logistics of client

to delegate PKI to a third-party greatly simplified Web security. This was one of the reasons SSL became good

enough for most online transactions, even when initially c

solutions like Secure Electronic Transaction (SET).

SSL’s greatest weakness, however, is that it is oriented toward synchronous transactions that require a direct

connection between participants. Both parti

secure context, and all information in the transaction is en

makes SSL an insufficient security model for Web services. Despite the nam

Web services uses existing Web infrastructure (including HTTP transport, Web application servers, etc.), but it is

fundamentally a one-way messaging paradigm for computer communications composed around a simple XML

message structure with an extensible header model.

Web service messages may not piggyback on HTTP at all. They might flow across a Message

(MOM) such as IBM’s MQSeries or be carried asynchronously by Simple Mail Transfer Protocol (SMTP).

packets being passed between routers, Simple Object Access Protocol (SOAP) messages are designed to flow

through a network of intermediates. Intermediates may be required to view header information to make

processing decisions based on application

and requires synchronous responses from a receiver is not appropriate in a Web services architecture.

SSL requires a direct connection

between participants, which is not

always possible with Web services



Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and


to effectively use PKI. This may soon change. Web services promote

that demands the flexibility that only an enterprise PKI deployment can offer.

Message Security If one were to lump all of the existing production-level Web services applications together and categorize their


due to the relative immaturity of the Web services technology rather than a developer oversight. Second, the bulk


SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay

side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server

authentication and protecting against impersonators and most man-in-the-middle attacks. While t

tem, it is often considered an acceptable risk. SSL even offers optional client

cate authentication that, though powerful, is rarely implemented.



under SSL, or via HTTP authentication, or an application-level means such as forms), a


transactions without requiring re-authentication. The value in such a transparently

maintained security context is easy to take for granted.


utilizes public key cryptography, it does not need full-blown PKI. Most SSL

servers use certificates issued by the “browser cartel”. Those certification authorities are

fortunate enough to have their root certificates automatically installed within the trust


body provides the baroque logistics of client-side certificates on the Web. The ability

party greatly simplified Web security. This was one of the reasons SSL became good

enough for most online transactions, even when initially challenged by technically elegant though complex

solutions like Secure Electronic Transaction (SET).


connection between participants. Both parties need to be available, multiple passes are necessary to set up a

secure context, and all information in the transaction is encrypted (a costly processor burden). This requirement

makes SSL an insufficient security model for Web services. Despite the name, Web services is not about the Web.


way messaging paradigm for computer communications composed around a simple XML

sage structure with an extensible header model.

Web service messages may not piggyback on HTTP at all. They might flow across a Message-Oriented Middleware

Series or be carried asynchronously by Simple Mail Transfer Protocol (SMTP).



cation-level protocol. A channel-based security model that encrypts everything




Enterprise Public Key Infrastructure (PKI) has a bad name. Considered complex, costly, and difficult to deploy and


Web services promotes a security model

ervices applications together and categorize their


sight. Second, the bulk


SSL provides confidentiality and integrity. Automatic sequence numbering protects against replay attacks. SSL uses

side certificate that binds the server’s Domain Name Server (DNS) name to a subject, ensuring server

While this feature does

is often considered an acceptable risk. SSL even offers optional client-



level means such as forms), a


authentication. The value in such a transparently


blown PKI. Most SSL-enabled Web

certification authorities are

tificates automatically installed within the trust


side certificates on the Web. The ability

party greatly simplified Web security. This was one of the reasons SSL became good

cally elegant though complex


es need to be available, multiple passes are necessary to set up a

crypted (a costly processor burden). This requirement

e, Web services is not about the Web.


way messaging paradigm for computer communications composed around a simple XML

Oriented Middleware

Series or be carried asynchronously by Simple Mail Transfer Protocol (SMTP). Similar to IP



based security model that encrypts everything





The Challenge with Message SecurityAccording to the Organization for the Advancement of Structured Information Standards (OA

Wide Web Consortium (W3C) standards, the solution to the Web

into the message itself. That is, provide a means of authentication, integrity, and

confidentiality that is integral to the message and completely decoupled from

transport channels. This ensures message secur

whether it flows over regular HTTP, across a Peer

prietary protocols, is persisted to a file, or printed onto a piece of paper. A security

model like this that supports asynchronous mes

advantages.

In the Oasis Web Services Security (WSS) standard, each SOAP message stands alone

and can have uniquely applied security. The standard includes mechanisms for

encrypting any content in the message at a very fine

than applying a cipher to the entire message, only those parts that are deemed

necessary to cryptographically secure are encrypted. The public parts of a message (such as the header fields that

might be relevant to an intermediate in making a routing decision) can be left in the clear.

Since any part of a SOAP message is subject to modification by an at

networks, WSS provides a mechanism for signing message content with a granul

encryption. For example, not only can a message author encrypt the credit card element, but they can also sign it

to ensure that no substitution in transit goes undetected. The same protection can be extended to unencrypted

public elements, such as timestamps inserted into the header.

Web Services Security Requires PKIWSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is

possible to build a WSS-compliant system based on

specification, this disqualifies a transaction from any claims to non

list of potential security flaws. As a result, it’s difficult to find a vendor’

PKI. Furthermore, most organizations are building systems predicated on having key pairs on both sides of a

transaction: at the message producer (client) and the message consumer (server) sides, necessitating PKI.


Because Web service messages

may flow asynchronously

across the network, security must be

implemented within each message



The Challenge with Message Security According to the Organization for the Advancement of Structured Information Standards (OASIS) and the World

Wide Web Consortium (W3C) standards, the solution to the Web services security problem is to absorb security



transport channels. This ensures message security remains consistent and trustworthy

whether it flows over regular HTTP, across a Peer-to-Peer (P2P) network using pro


model like this that supports asynchronous messaging has great architectural

advantages.



encrypting any content in the message at a very fine-grain level. For example, rather

plying a cipher to the entire message, only those parts that are deemed


ermediate in making a routing decision) can be left in the clear.

Since any part of a SOAP message is subject to modification by an attacker as it traverses potentially hostile

anism for signing message content with a granularity that is identical to



c elements, such as timestamps inserted into the header.

Web Services Security Requires PKI WSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is

compliant system based on shared secrets that are exchanged out-of-band of the WSS

specification, this disqualifies a transaction from any claims to non-repudiation, as well as subjecting it to a toxic

list of potential security flaws. As a result, it’s difficult to find a vendor’s WSS implementation that is not based on

more, most organizations are building systems predicated on having key pairs on both sides of a





SIS) and the World

services security problem is to absorb security



ity remains consistent and trustworthy

Peer (P2P) network using pro-


saging has great architectural



grain level. For example, rather

plying a cipher to the entire message, only those parts that are deemed


tacker as it traverses potentially hostile

arity that is identical to



WSS goes to great lengths to remain flexible with potential encryption/signing technologies. But even though it is

band of the WSS

repudiation, as well as subjecting it to a toxic

s WSS implementation that is not based on

more, most organizations are building systems predicated on having key pairs on both sides of a





PKI is essential to a typical WSS implementation. In the session

message is secured for transmission between two parties that do not share a pre

token. Therefore, there is no shared secret, such as a key used for symmetric encryption and Hashed Message

Authentication Code (HMAC) signing between the producer and the consumer. Emerging standards, such as WS

Secure Conversation and WS-Trust, provide for negotiated security tokens and define well

mechanisms similar to SSL’s session key scheme. In the current scenario, however, a message can be secured

directly using only the key pair and certificate held by the producer and t

In the second scenario illustrated in Figure 2, a simplified message is exchanged between the producer and the

consumer. The message body has been encrypted using a two

generates a random symmetric key with which the body content is encrypted using a symmetric algorithm like

triple-DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this

approach with SSL, which supports negotiation of cipher suites and key lengths in order to accommodate a

diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out

of-band agreement on cipher capabilities.



PKI is essential to a typical WSS implementation. In the session-less scenario illustrated in Figure 1, a single

message is secured for transmission between two parties that do not share a pre-negotiated, temporary secu


ing between the producer and the consumer. Emerging standards, such as WS

ovide for negotiated security tokens and define well-known key derivation


directly using only the key pair and certificate held by the producer and the certificate for the consumer.


consumer. The message body has been encrypted using a two-step process described in WSS. First, the


DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this

ts negotiation of cipher suites and key lengths in order to accommodate a

diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out

band agreement on cipher capabilities.



less scenario illustrated in Figure 1, a single

negotiated, temporary security


ing between the producer and the consumer. Emerging standards, such as WS-

known key derivation


he certificate for the consumer.


cess described in WSS. First, the producer


DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this

ts negotiation of cipher suites and key lengths in order to accommodate a

diversity of clients, any of whom may be subject to cryptography export restrictions. Here, we assume a prior out-




How does this shared secret become shared? The producer encrypts the symmetric key with

key, ensuring only that party can decrypt the message. This encrypted key is embedded in the security header with

a reference to the key pair needed to unlock it (often th

the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designat

receiver can decrypt it and use it to decipher the message content. Thus, no comp

required to negotiate a security session key. Each message stands alone.

Encryption, however, is only a component of the security story, albeit an important

one. As it stands, the encrypted message body is subject to substitution by a

malicious party, as are critical header field

necessary for servers to uniquely identify messages and apply an effective replay

defense. Furthermore, the consumer has no means to authenticate the message

producer because encryption for a particular receiver does not i

To address this shortcoming, the message producer takes the encrypted message

body and critical header fields and places these into yet an

security header. It signs this block, aggregating the components into a singl

simultaneous integrity/origin authentication statement. The producer includes its

certificate (or a reference to it) in the security header so that the receiver can

validate the signature and follow any certificate chain in the certificate to a trust

anchor. Now, the consumer can have confidence that a specific producer authored

the message, that it was not altered in transit, and most importantly, that it was designated specifically for this

consumer.

What is important to recognize here is that all par

Without PKI, the model does not work.

Conclusion Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague

coupling to commercial PKI systems. As always, it is what the standards loosely describe that becomes the source

of problems. Interfacing to a particular key store type or location and coercing servers to check Certificate

Revocation Lists (CRLs) or use Online Certificate Status

proactively, rolling out your PKI system before its services are demanded by a Web services application. The

demand will come because, while SSL is sufficient for synchronous client

depends on asynchronous messaging, which is where PKI will shine.

With PKI, the encrypted key and reference to its key pair is embedded in

each Web service message’s security

header, allowing each message to be

validated individually by a new class of XML

firewalls



et become shared? The producer encrypts the symmetric key with the consumer’s public


a reference to the key pair needed to unlock it (often this is implemented using the subject key identifier field from

the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designat

receiver can decrypt it and use it to decipher the message content. Thus, no complex multi-pass protocol is

required to negotiate a security session key. Each message stands alone.



malicious party, as are critical header fields such as the timestamp, which is



producer because encryption for a particular receiver does not i


body and critical header fields and places these into yet another block in the

security header. It signs this block, aggregating the components into a singl




chor. Now, the consumer can have confidence that a specific producer authored


What is important to recognize here is that all parties in the transaction scenario have key pairs and certificates.

Without PKI, the model does not work.

Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague

KI systems. As always, it is what the standards loosely describe that becomes the source


Revocation Lists (CRLs) or use Online Certificate Status Protocol (OCSP) can be troublesome. It is best to start


demand will come because, while SSL is sufficient for synchronous client-server applications, Web services

on asynchronous messaging, which is where PKI will shine.



the consumer’s public


is is implemented using the subject key identifier field from

the receiver’s certificate). In the security header, anyone can read the encrypted key, but only the designated

pass protocol is



s such as the timestamp, which is



producer because encryption for a particular receiver does not identify the author.


other block in the

security header. It signs this block, aggregating the components into a single,




chor. Now, the consumer can have confidence that a specific producer authored


ties in the transaction scenario have key pairs and certificates.

Web services is a great opportunity for PKI and a great challenge. Most vendors’ toolkits have a deliberately vague

KI systems. As always, it is what the standards loosely describe that becomes the source


Protocol (OCSP) can be troublesome. It is best to start


s, Web services




About Layer 7 TechnologiesWith offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7

Technologies helps enterprises accomplish secure and cost

services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and

governance across a Web services integration without expensive and inflexib

SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to

future-proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more

information.

Contact Layer 7 TechnologiesLayer 7 Technologies welcomes your questions, comments, and general feedback.

Email: [email protected]

Web Site: www.layer7tech.com

Phone: 604-681-9377

1-800-681-9377 (toll free)

Fax: 604-681-9387

Address: US Office

1200 G Street, NW, Suite 800

Washington, DC 20005

Canada Office

Suite 405-1100 Melville Street

Vancouver, BC

V6E 4A6 Canada

Legal Information Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.

SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or

trademarks are the property of their respective owne



About Layer 7 Technologies With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7

accomplish secure and cost-effective business integration using XML and Web


governance across a Web services integration without expensive and inflexible programming. With the


proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more

Contact Layer 7 Technologies Layer 7 Technologies welcomes your questions, comments, and general feedback.

by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.


trademarks are the property of their respective owners.



With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7

effective business integration using XML and Web


le programming. With the


proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more

by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.


Documents

Web Services and PKI