Andrew J. Hewatt, Gayatri Swamynathan and Michael T. Wen

1
A Case Study of theWS-Security Framework

• Andrew J. Hewatt, Gayatri Swamynathan and Michael
  T. Wen
• Department of Computer Science, UC-Santa Barbara

2
Why talk about security?

• Security in the web services industry is of great
  importance and a deciding factor for many
  corporations when moving to a web services
  software architecture.
• The WS-Framework was created by a collection of
  industry leaders to be the solution to this.
• Our case study focuses on the security of the
  WS-Framework and its extensions to determine if
  they are indeed adequate.

2
06.03.2005
3
WS-Framework Defined

• The Framework and its extensions were meant to
  enable two parties to securely communicate via
  SOAP messaging.
• There are currently six extensions that reside on
  top of WS-Security and SOAP. Two of these have
  been defined but are not yet published.
• We chose to focus on the WS-Security, WS-Trust,
  WS-Policy and WS-Secure Conversation modules.
  These we feel encompass most of the security
  areas within our scenario.

3
06.03.2005
4
WS-Framework Overview
WS- Secure Conversation
WS- Federation
WS- Authorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security
XKMS
SAML
XACML
SPML
Soap Foundation
XML Encryption
XML Digital Signature
4
06.03.2005
5
Defining The Scenario

• A single client will send a request with a loan
  amount and time period to a loan bidding website.
  
• The website will then iterate this query to all
  selected banks who will then formulate a
  response.
• The website will gather all responses and display
  the corresponding interest rates to the user.

5
06.03.2005
6
Module Interactions
Client
Loan Website
Bank A
Bank Z
Bank Y
Partner A
Loan Services
Partner Interface
Partner B
Partner C
Commodity Trading
Risk Management
NYSE Trading Services
6
06.03.2005
7
Security Interactions
Client
Loan Website
Bank A
Bank Z
Bank Y
Security Module
Partner A
Loan Services
Partner Interface
Partner B
Partner C
Commodity Trading
Risk Management
NYSE Trading Services
7
06.03.2005
8
Security Requirements

• Identity Management Each entity must be able to
  identity itself to the party it wants to
  communicate with
• Policy Management Each entity enforces policies
  with other entities. E.g. message format, who has
  access to what, what one needs to process.
• Secure Messaging authentication,
  confidentiality, integrity, non-repudiation

8
06.03.2005
9
WS-Security

• Goal provide message-level security which
  addresses confidentiality, integrity, and single
  message authentication.
• Non-Goals
• Establishing a security context that requires
  multiple exchanges
• Key exchange and derived keys
• How trust is established or determined
• Two main parts encrypted message and signature.

9
06.03.2005
10
Security Message
ltS Envelope xmlnsShttp//
xmlnswssehttp// xmlnsxenchttp//
ltSHeadergt ltwsseSecuritygt ltwsseBinarySecur
ityTokengt IDMyToken lt/wsseBinaryS
ecurityTokengt ltxencEncryptedKeygt ltxe
ncReferenceListgt ltxencDataReference
URIenc/gt lt/xencReferenceListgt lt/xencE
ncryptedKeygt ltdsSignaturegt lt/dsSigna
turegt lt/wsseSecuritygt lt/SHeadergt
Key used for the signature
Key used to encrypt message
Contains signature algorithm, key info, and
signature value
10
06.03.2005
11
A Bad Example

• WS-Security alone is not enough to address the
  security issues
• Scenario An eavesdropper is listening to the
  traffic of messages between two parties. After a
  while he or she may be able to crack the
  symmetric key and hijack the traffic.
• Solution This is handled by WS-SecureConversation
  .

11
06.03.2005
12
WS-Policy

• A policy is comprised of a collection of policy
  alternatives.
• Each policy alternative is a collection of policy
  assertions that represent an individual
  requirement, capability of other property of a
  behavior.
• Example Assertions exactlyOne Kerberosv5TGT or
  X509v3
• Policy intersection (involves domain-specific
  processing!)
• Assertions should be digitally signed.

12
06.03.2005
13
WS-Trust

• Enables the issuance and dissemination of
  credentials within different trust domains
• If a message arrives without having the required
  proof of claims, the service should ignore or
  reject the message.

13
06.03.2005
14
Security Token Service

• Token issuance
• Token renewal
• Token cancellation
• Token validation

14
06.03.2005
15
WS-SecureConversation

• The WS-SecureConversation extension defines two
  main additions, namely a security context and
  derived keys.
• Establishing a security context is more
  beneficial for a series of messages between two
  parties because it is shared for the lifetime of
  the conversation.
• Derived keys allows the involved parties to keep
  security fresh during interaction instead of
  relying on just one secret.
• Possible need for further extensions

15
06.03.2005
16
Conclusions

• WS-Framework is adequate for our scenario but may
  be too flexible.
• We feel the WS-Security framework should be more
  rigid by enforcing further rules that will govern
  which parts of each extension are to be used with
  one another.
• WS-Security framework satisfies Identity
  Management, Policy Management, and Secure
  Messaging but may need extra extensions.

16
06.03.2005