Export (0) Print
Expand All

Chapter 2: Message Protection Patterns

 
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 2: Message Protection Patterns

patterns & practices Developer Center

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

DownloadDownload this guide in PDF format
CommunityWeb Service Security Community Workspace [Content link no longer available, original URL:http://go.microsoft.com/fwlink/?LinkId=57044]

Web services send and receive plaintext messages over standard Internet protocols such as HTTP. Such plaintext messages can be intercepted by an attacker and potentially viewed or even modified for malicious purposes. By using message protection, you can protect sensitive data against threats such as eavesdropping and data tampering. This chapter provides design patterns for data confidentiality and data origin authentication.

This chapter provides design patterns for data confidentiality and data origin authentication. Figure 1 is a pattern map that illustrates these patterns.

Ff647375.ch2_intro_f01(en-us,PandP.10).gif

Figure 1 Message protection patterns

Note   The main factors that drive the type of message protection required are usually related to security policies within your organization and threat analysis performed for a particular application. It is strongly recommend that you perform a threat analysis to help understand your requirements. For more information about threat modeling, see Threat Modeling Web Applications on MSDN.

Data Integrity, Data Origin Authentication, and Data Confidentiality

Message protection can be divided into three main categories:

  • Data integrity is the verification that a message has not changed in transit.
  • Data origin authentication takes data integrity a step further and supports the ability to identify and validate the origin of a message.
  • Data confidentiality is the encrypting of message data so that unauthorized entities cannot view the contents of the message.

As shown in Figure 1, a pattern does not exist for data integrity. Instead of creating a separate design pattern for data integrity, many of the implementation patterns in Chapter 3, "Implementing Transport and Message Layer Security," include data integrity as a step in the process. Because you should consider data integrity issues as you determine the message protection required in your environment, the decision matrix in Table 1 includes a Data Integrity column. The other two columns are mapped to design patterns in this chapter, which is consistent with other decision matrices.

Table 1 represents a decision matrix that lists security considerations related to message protection and how each one is supported by data integrity, data origin authentication, and data confidentiality.

Table 1. Message Protection Decision Matrix

Security ConsiderationData IntegrityData Origin AuthenticationData Confidentiality
You want to verify that the contents of a message were not altered in transit. Allows verification that a message has not changed in transit.Supports the ability to verify that a message has not changed in transit and verify the origin of a message.Encryption does not prevent the contents of a message from being altered.
You want to verify that the source of the data is from the sender you are authenticating and that the contents of a message were not altered in transit. Allows verification that a message has not been changed, but this does not necessarily imply that the receiver can verify the source of the data. Supports the ability to verify that a message has not changed in transit and verify the origin of a message.Encryption does not prevent the contents of a message from being altered.
You want to restrict access to the contents of a message to authorized users only.Does not provide the ability to protect message contents from unauthorized users.Does not provide the ability to protect message contents from unauthorized users.Confidentiality can be used to encrypt the contents of a message so that only authorized users can view the message contents.
You are implementing direct authentication using a shared secret and want to prevent an attacker getting the secret.Generating signatures based on shared secrets that may have low entropy leaves the message vulnerable to offline cryptographic guessing attacks; as such, WSE 3.0 recommends you secure direct authentication using either HTTPS or UsernameForCertificate assertions.Generating signatures based on shared secrets that may have low entropy leaves the message vulnerable to offline cryptographic guessing attacks; as such, WSE 3.0 recommends you secure direct authentication using either HTTPS or UsernameForCertificate assertions.Encryption combined with data integrity and data origin authentication can be used to protect the shared secret.
You want to implement the Message Replay Protection pattern to prevent an attacker from maliciously replaying messages.

Replay detection depends on the ability to uniquely identify messages.

This option is often implemented using a hashing function that provides a unique identifier that can be used to determine if the same message is received multiple times.This option is often implemented using a hashing function or digital signature that provides a unique identifier that can be used to determine if the same message is received multiple times.Not applicable.

From the decision matrix in Table 1, you can see that data confidentiality is recommended during authentication and any time sensitive data is sent in a message.

The remainder of this chapter focuses on the following design patterns:

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Show:
© 2014 Microsoft