Web Services and PKI

The How and Why

Layer 7 Technologies

White Paper
Web Services and PKI

Contents

Introduction ................................................................
................................................................................................
.................................................. 3
Channel vs. Message Security ................................
................................................................................................
....................................................... 3
The Challenge with Messagee Security ................................................................................................
.......................................... 4
Web Services Security Requires PKI ................................................................................................
.............................................. 4
An Example of PKI in Web Services ................................................................................................
........................................... 4
Conclusion ................................................................
................................................................................................
..................................................... 6
About Layer 7 Technologies ................................
................................................................................................
.......................................................... 7
Contact Layer 7 Technologies ................................
................................................................................................
....................................................... 7
Legal Information ................................
................................................................................................................................
.......................................... 7

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 2
 Web Services and PKI

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. Web services promotes
promote a security model
that demands the flexibility that only an enterprise PKI deployment can offer.

Channel vs. Message Security

If one were to lump all of the existing production
production-level Web services
ervices applications together and categorize their
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
oversight.
sight. Second, the bulk
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 attacks. SSL uses
a server-side
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 man-in-the-middle attacks. While this
t feature does
rely on the integrity of the DNS system,
tem, it is often considered an acceptable risk. SSL even offers optional client-
client
side certificate
cate authentication that, though powerful, is rarely implemented.

Channel continuity is probably the most unheralded quality of SSL. Once a session is set
SSL requires a up, and the client and server mutually authenticate (with the client using a certificate
direct connection under SSL, or via HTTP authentication, or an application-level
level means such as forms), a
level of trust is established on the open socket so that it is available for multiple
between
transactions without requiring re re-authentication.
authentication. The value in such a transparently
participants, maintained security context is easy to take for granted.
which is not
always possible Of course, one of the reasons behind SSL’s success on the Web was that, although it
with Web services utilizes public key cryptography, it does not need full
full-blown
blown PKI. Most SSL-enabled
SSL Web
servers use certificates issued by the “browser cartel”. Those certification authorities are
fortunate enough to have their root cer
certificates
tificates automatically installed within the trust
store of the most popular browsers. With the exception of a few early consumer banking products that have now
been abandoned, almost nobody body provides the baroque logistics of client
client-side
side certificates on the Web. The ability
to delegate PKI to a third-party
party greatly simplified Web security. This was one of the reasons SSL became good
enough for most online transactions, even when initially cchallenged by technically cally elegant though complex
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
parties
es need to be available, multiple passes are necessary to set up a
secure context, and all information in the transaction is en
encrypted
crypted (a costly processor burden). This requirement
makes SSL an insufficient security model for Web services. Despite the namname,e, Web services is not about the Web.
Web services uses existing Web infrastructure (including HTTP transport, Web application servers, etc.), but it is
fundamentally a one-way
way messaging paradigm for computer communications composed around a simple XML
message
sage structure with an extensible header model.

Web service messages may not piggyback on HTTP at all. They might flow across a Message
Message-Oriented
Oriented Middleware
(MOM) such as IBM’s MQSeries
Series or be carried asynchronously by Simple Mail Transfer Protocol (SMTP). Similar to IP
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
cation-level protocol. A channel-based
based security model that encrypts everything
and requires synchronous responses from a receiver is not appropriate in a Web services architecture.

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 3
 Web Services and PKI

The Challenge with Message Security

According to the Organization for the Advancement of Structured Information Standards (OA (OASIS)
SIS) and the World
Wide Web Consortium (W3C) standards, the solution to the Web services security problem is to absorb security
into the message itself. That is, provide a means of authentication, integrity, and
Because Web confidentiality that is integral to the message and completely decoupled from
transport channels. This ensures message secur security
ity remains consistent and trustworthy
service messages whether it flows over regular HTTP, across a PeerPeer-to-Peer
Peer (P2P) network using pro-
pro
may flow prietary protocols, is persisted to a file, or printed onto a piece of paper. A security
asynchronously model like this that supports asynchronous mes messaging
saging has great architectural
across the network, advantages.
security must be
In the Oasis Web Services Security (WSS) standard, each SOAP message stands alone
implemented within
and can have uniquely applied security. The standard includes mechanisms for
each message encrypting any content in the message at a very fine
fine-grain
grain level. For example, rather
than applying
plying 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
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 at

attacker
tacker as it traverses potentially hostile
networks, WSS provides a mechanism
anism for signing message content with a granul
granularity
arity that is identical to
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
publicc 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
possible to build a WSS-compliant
compliant system based on shared secrets that are exchanged out-of-band band of the WSS
specification, this disqualifies a transaction from any claims to non non-repudiation,
repudiation, as well as subjecting it to a toxic
list of potential security flaws. As a result, it’s difficult to find a vendor’
vendor’ss WSS implementation that is not based on
PKI. Furthermore,
more, 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.

An Example of PKI in Web Services

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 4
Web Services and PKI

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

session-less
less scenario illustrated in Figure 1, a single
message is secured for transmission between two parties that do not share a pre pre-negotiated,
negotiated, temporary security
secu
token. Therefore, there is no shared secret, such as a key used for symmetric encryption and Hashed Message
Authentication Code (HMAC) signing ing between the producer and the consumer. Emerging standards, such as WS- WS
Secure Conversation and WS-Trust, provideovide for negotiated security tokens and define well
well-known
known key derivation
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 tthe
he certificate for the consumer.

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 two-step process
cess described in WSS. First, the producer
generates a random symmetric key with which the body content is encrypted using a symmetric algorithm like
triple-DES
DES or AES. A specialized security header describes the exact algorithm and key length. Contrast this
approach with SSL, which supports 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-
out
of-band
band agreement on cipher capabilities.

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 5
 Web Services and PKI

How does this shared secret et become shared? The producer encrypts the symmetric key with the consumer’s public
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 ththis
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
designat
receiver can decrypt it and use it to decipher the message content. Thus, no comp
complex multi-pass
pass protocol is
required to negotiate a security session key. Each message stands alone.

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

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
the message, that it was not altered in transit, and most importantly, that it was designated specifically for this
consumer.
one. As it stands, the encrypted message body is subject to substitution by a
malicious party, as are critical header field
fieldss such as the timestamp, which is
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 identify
i the author.
To address this shortcoming, the message producer takes the encrypted message
body and critical header fields and places these into yet ananother
other block in the
security header. It signs this block, aggregating the components into a single,
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.
chor. Now, the consumer can have confidence that a specific producer authored

What is important to recognize here is that all par

parties
ties in the transaction scenario have key pairs and certificates.
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 KI 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 Protocol (OCSP) can be troublesome. It is best to start
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
client-server applications,
s, Web services
depends on asynchronous messaging, which is where PKI will shine.

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 6
Web Services and PKI

About Layer 7 Technologies

With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
Technologies helps enterprises accomplish secure and cost
cost-effective
effective business integration using XML and Web
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that addresses security and
governance across a Web services integration without expensive and inflexib
inflexible
le programming. With the
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
future-proof
proof their Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
information.

Contact Layer 7 Technologies

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

Email:
info@layer7tech.com

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
owners.

Copyright © 2010 Layer 7 Technologies

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
yrights are the property of their respective owners. 7