Mr. Abdelkrim Boujraf, Unisys

Mr. Andreas Schaad, SAP Research

Mr. Mohammad Ashiqur Rahaman, SAP Researchfunded by EU Integrated Project R4eGov

R4eGov Inter-Agency Collaboration

– Security Performance

Measurement

Evaluating WS * vs. SOAP Accounts

R4eGov Inter-agency collaboration

WS Performance Criteria

AGENDA

Evaluation Results

The problem….

The majority of eGovernment systems is and may have to remain heterogeneous.

Their configuration and definition of processes is likely to remain under local administration.

eGovernment interoperability in the EU follows an ad hoc approach and systems are only made interoperable when there is a shared purpose and some general legal guidelines.

We believe the majority of systems to require the methodologies, systems and tools for achieving the maturity level of collaborative organisations.

* Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

EU Interagency Collaboration - The reality….

During a routine check Spanish customs intercept a shipment of coffee containing cocaine in the harbour of Malaga. The container came from Caracas, Venezuela and was supposed to be transported by road to Antwerp and to be delivered to a trade company called BE. A number of persons are taken into custody, whilst investigations start….. The involved authorities (Europol and Eurojust)*

need to collaborate in a quick and efficient manner.– European Arrest Warrant– Rogatory Letter– Joint Investigation Teams– ….

They need to remain in control of their systems They need to follow local as well as EU-wide laws

and agreements

* Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

Requirements

Local case management

Exchange of documents

Access Control on documents

Traceability

Chain of evidence

European and Local Directives on Data Usage

Collaboration agreements

Can in parts be addressed by using OASIS WS* standards.

General WS Security Setup

WS-Policydescribes the capabilities and constraints on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms)

WS-SecureConversationdescribes how to manage and authenticate a series of message exchanges

Requester Web Service

Security Token

Service

Policy

Security Token Claims

Policy

Policy

Security TokenClaims

Security Token

Claims

WS-Securityattaching signature and encryption headers / security tokens to SOAP messages e.g. X.509 certificates and Kerberos tickets, to messages

WS-Trustdescribes a framework for trust models that enables Web services to trust other domains

Performance / A general Web Service invocation flow Some Performance Relevant Criteria (incomplete)

– Methods for issuing, renewing, and validating security tokens;– Establishing security contexts for a conversation of messages.– Amending, Renewing, and cancelling the security contexts.– Computing and passing derived keys and session keys.– Verify Subjects / Security Attributes

Approach to Performance Measurement

Our Problem: What can we measure performance against? No real benchmarks for WS* Performance Measurement.

Our Approach: Build our own solution for defined purpose scope Measure WS* key performance indicators against this

Our (simplified) requirements: Preservation of message confidentiality / integrity Handling of complex / large messages Focus on prevention of XML re-writing attacks

Our Proposal: SOAP Account: Keeps record of SOAP message structure / elements. Requires small component to be deployed on each SOAP processing

node.

SOAP Account: Message flow in the proposed technique

A SOAP request using a SOAP Account

<Envelope>…… <Header> <Security> <BinarySecurityToken Id=" Id-2" ValueType="...X509v3"> MIIEZzCCA9CgAwIBAgIQEmtJZc0...</BinarySecurityToken> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="..xml-exc-c14n#"/> <SignatureMethod Algorithm="...#rsa-sha1"/> <Reference URI="#Id-1"> <DigestMethod Algorithm="...#sha1"/> <DigestValue>d5AOd..=</DigestValue> </Reference> <Reference URI="#Id-2>...</Reference>

<Reference URI="#Id-3>....</Reference> </SignedInfo> <SignatureValue>e4EyW...=</SignatureValue> <KeyInfo><SecurityTokenReference><Reference URI="#Id-2" ValueType="...#X509v3" /></KeyInfo>

RST token is signed

Receiver can verify

<SoapAccount Id=”#Id-3”> <NoChildOfEnvelope>2</> <NoOfHeader>2</> </SoapAccount>

<Body Id="Id-1"> <RequestSecurityToken> <TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct </TokenType><RequestType>http://schemas.xmlsoap.org/ ws/2004/04/security/trust/Issue </RequestType> <Base>...</Base> </RequestSecurityToken></Body>

SOAP Account added

Simulated SOAP, WS Policy, SOAP Account

<Envelope> …… <Header> <Security> <BinarySecurityToken Id=" Id-2" ..> ...</BinarySecurityToken> <Signature> <SignedInfo> …… <Reference URI="#Id-1"> …..</Reference> <Reference URI="#Id-2”> ....</Reference> </SignedInfo> <SignatureValue>e4EyW...= </SignatureValue> <KeyInfo>…</KeyInfo> <Body Id="Id-1"> <RequestSecurityToken> <TokenType>http://schemas.xmlsoap .org/ws/2005/02/sc/sct </TokenType> <RequestType>http://schemas.xml soap.org/ ws/2004/04/security /trust/Issue </RequestType.. </RequestSecurityToken>

<wsp:Policy …..> …..

<sp:SignedParts>

<sp:Body/>

</sp:SignedParts>

</wsp:Policy>

SOAP

WS Policy

<SoapAccount Id=”#Id-3”>

<NoOfHeader>2</>

</SoapAccount>

SOAP Account

2695 bytes to 51551 bytes 388 bytes

197 bytes

Performance Criteria

Requestor Soap Size VS Policy and SoapAccount size Comparison

0

10000

20000

30000

40000

50000

60000

Size

in Bytes

Request Soap With Soap Account SenderPolicy File Size SenderSoap AccountSize

Request SOAP size vs. requestor Soap Account header size and Policy file size.

SOAP Account size vs. Policy file size.

Relative comparison of signature processing in both ends.

Enforcement time of SOAP Account and Policy in sender (requestor).

Enforcement time of SOAP Account and Policy in the receiver.

XML rewriting attack detection time using SOAP Account and Policy.

Results/ChartComparison Criteria

xmlRewriting Attack Detection Time Comparison

0

5

10

15

20

25

30

35

Received Soap size With Soap Account(Bytes)

xmlRewritngAttackDetectionTimeUsing Policy xmlRewitingAttackDetectionTimeUsingSoapAccount

SOAP Size 2695 to 51551 bytes

SOAP Account 197 bytes ~0.72% of SOAP

Policy File 388 bytes ~1.42% of SOAP

Scalability.

~15% more time in the Requestor

Comparable enforcement time for both in the Requestor.

~1.50 % faster XML Rewriting Attack Detection using SOAP Account.SOAP Account is scalable.

~30% less Enforcement time using SOAP Account in the Receiver.

SOAP size > 4500 bytes..SOAP Account Enforcement Time ~ Policy Enforcement Time.

1. SOAP Account Processing. 2. Policy processing.3. Signature Processing. 4. Attacker Simulation

Summary & Conclusion

We presented a „real-world“ collaboration scenario and security requirements

WS* can be deployed to satisfy some of these requirements

WS* Security performance indicators

Measure these indicators against our own SOAP account solution

In summary, our solution is more performant due to being purpose-built for avoiding XML rewriting attacks (overly simplified).

Not really „scientific“ approach but valuable lessons learnt on: Establishing a set of Security / Web Service Performance Indicators Implementation and Setup, Memory Consumption, Processing, Key Generation,

Validation, Message Sizing etc.

Current research work is focusing on XACML testing

Overall goal is a general test tool suite for standards evaluation

Thank You & Questions

abdelkrim.boujraf@be.unisys.comandreas.schaad@sap.com

mohammad.ashiqur.rahaman@sap.com

* Europol and Eurojust are SAP EU project partners but not SAP or Unisys customers. The case study is for illustration / requirements engineering purposes only.