T110 455 Network Application Frameworks and XML Security

T-110. 455 Network Application Frameworks and XML Security Basics 30. 3. 2005 Sasu Tarkoma Based on slides by Pekka Nikander

Contents n High-level view to WS security WS Application level security Standardization landscape Basic XML security Summary n Topics are continued in the next lecture n n

Need for XML security n XML document can be encrypted using SSL or IPSec u u u n n this cannot handle the different parts of the documents may be routed hop-by-hop different entities must process different parts of the document SSL/TLS/IPSec provide message integrity and privacy only when the message is in transit We also need to encrypt and authenticate the document in arbitrary sequences and to involve multiple parties

High-level view to WS security n n Security is as strong as the weakest link The options for an attacker are: u Attack the Web Service directly F u u u n Using ”unexpected” XML Attack the Web Services platform Attack a WS security tool Attack the underlying operating system or network connection Let’s have examples from different security functions’ point of view and highlight key specifications

Authentication I n n n End-users authenticate (their identity is verified) using username/password, Secur. ID or such, or biometrics u End-users do not send SOAP messages Authentication for SOAP means authenticating the sender u Authentication of an application, not a person F Client-side SSL, when HTTP is used F Digital certificates and signatures in SOAP messages Core specification: XML Signature

Authentication II n n SAML (Security Assertion Markup Language) u A XML-based framework (schemas) for the exchange of authentication and authorization information u Mainly for integration, up to relying parties to decide to what authentication authority to trust u Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources u Authentication statements merely describe acts of authentication that happened previously SAML & WS-Security allow a SOAP message to include information about the end-user’s authentication status

Authorization n Once the sender or end-user is authenticated, are they allowed to access the resource which they are requesting? XACML (XML Access Control Markup Language) defines how to represent access control rules in XML WS-Policy defines web service policies (algorithms, tokens, privacy requirements, encodings, . . ) between senders and receivers u n n Also other policies, declarative & conditional assertions SAML (Security Assertion Markup Language) Existing tools for authorization to websites u u Distinguish resources as URLs A single URL can contain many Web Services

Integrity n Has this message been tampered with? u u Checksums, digital signatures PKCS#7 signature F F u n Predates XML, ASN. 1 binary format How to sign only parts of a document (of a tree)? XML Signature Has the system been tampered with? u Intrusion detection u Tamper control

Confidentiality n Can the message be read while in transit? Transport (or below) level security: HTTPS, IPSEC u Message-level security: XML Encryption, WSSecurity Can the message be read while it is stored? u n u u n XML Database security Access control Is the data private? u u Gated access to private data Audit trails of access

Audit n Are transactions stored? u n n Does the storage alter the format? (e. g. splitting an XML message into elements in order to store it into a database) Is reporting available? Who can run / access the reports?

Availability n Preventing denial-of-service attacks u n Use of load-balancers u u n Blocking unwanted message ”storms” For XML communication platforms For XML Gateways / Firewalls Design of underlying protocols

Administration n n Ease of setting up security policies Ability to inherit from a pre-existing policy Ability to ”push” security policy to multiple Web Services, and Web Services platforms Possibility of exporting a policy, and importing it into a different system u n Plain text, SQL, XACML XKMS (XML Key Management) u PKI for XML-based security

Non-repudiation n Preventing users (and services) from denying a transaction occurred Requires a combination of the security requirements which we have seen so far Notoriously difficult to implement

Lecture outline n High-level view to WS Security u n n n WS Application-level security Standardization landscape Basic XML security Summary

Web Application Security n n n Application layer security has existed long before SOAP Application layer security for Web servers involves securing both the Web server itself, and Web applications which use the Web server as their platform Focus on attacks on Web applications rather than the platforms on which the Web applications run u n n Remember various CGI application attacks These attacks are specific to individual Web applications When bound to HTTP, SOAP itself can be seen as a Web application – albeit a more formalized one

Example – SQL Injection Firewall SOAP Book Lookup Message SQL IIS SOAP stack ASP. NET SQL server Windows Server 2003 <SOAP-ENV: Envelope xmlns: SOAP-ENV=”. . ”> <SOAP-ENV: Header> <SOAP-ENV: Body> <Book. Lookup: search. By. ISBN xmlns: Booklookup=”. . ”> <Book. Lookup: ISBN>1234567810</Book. Lookup: ISBN> </Book. Lookup: search. By. ISBN> </SOAP-ENV: Body></SOAP-ENV: Envelope> VB. NET code: Set my. Recordset = my. Connection. execute(”SELECT * FROM my. Books. Table WHERE ISBN=”’” & ISBN_Element_Text & ”’”) Becomes SELECT * FROM my. Books. Table WHERE ISBN = ’ 1234567810’

Firewall SOAP Book Lookup Message Attack: SQL Injection SQL IIS SOAP stack ASP. NET SQL server Windows Server 2003 <SOAP-ENV: Envelope xmlns: SOAP-ENV=”. . ”> <SOAP-ENV: Header> <SOAP-ENV: Body> <Book. Lookup: search. By. ISBN xmlns: Booklookup=”. . ”> <Book. Lookup: ISBN>’; exec master. . xp_cmdshell ’net user Joe pass /ADD’; -</Book. Lookup: ISBN></Book. Lookup: search. By. ISBN> </SOAP-ENV: Body></SOAP-ENV: Envelope> VB. NET code: Set my. Recordset = my. Connection. execute(”SELECT * FROM my. Books. Table WHERE ISBN=”’” & ISBN_Element_Text & ”’”) Becomes SELECT * FROM my. Books. Table WHERE ISBN = ’’; exec master. . xp_cmdshell ’ne user Joe pass /ADD ’; —

Solution Firewall SOAP Book Lookup Message SQL IIS SOAP stack ASP. NET SQL server Windows Server 2003 Ensure the format of incoming SOAP parameters <simple. Type name=”isbn”><restrictions base=”string”><pattern value=”[0 -9]{10}”/></restriction></simple. Type> Validate this Schema against the data isolated by the following XPath expression: /Body/Book. Lookup: search. By. ISBN/Book. Lookup: ISBN 1234567810 passes ’exec master. . xp_cmdshell ’net user Joe pass /ADD’-- fails

XML Schema Solution <xsd: schema xmlns: xsd="http: //www. w 3. org/2001/XMLSchema" target. Namespace = "https: //www. books. com/Lookup" xmlns="https: //www. books. com/Lookup" element. Form. Default="qualified"> <simple. Type name="isbn"> <restriction base="string"> <pattern value="[0 -9]{10}"/> </restriction> </simple. Type> </xsd: schema>

Content Inspection of XML n Integrity u n Schema Validation u n Verify request structure against XML Schema Content Validation u n Check integrity of data using XML Signature, WSSecurity Check content matches criteria specified in an XPath expression Schemas can be used to specify part of the content (for example ISBN) but they have limits u u XPath is more expressive Schema validation may always be applied to Body of SOAP msgs (rpc/literal vs. document/literal)

Application-layer Security n Identity-based security u n Content-based security u u n Protecting against buffer overflow and CGI-like attacks Must have knowledge about the applications to which these messages are directed Accountability or non-repudation u u n Authentication and authorization information shared across security domains Need message level security Maintain integrity, archived audit trails The standards and specifications mentioned earlier address these issues

Lecture outline n High-level view to WS Security u n n n WS Application-level security Standardization landscape Basic XML security Summary

Standardization landscape n n n Who are specifying the basic standards? Who are specifying the higher level standards? Who is implementing the standards?

Who are specifying the standards? n Joint IETF/W 3 C u n W 3 C u u n XML Signature (www. w 3. org/Signature) XML Encryption (www. w 3. org/Encryption/2001) XML Key Management (XKMS) (www. w 3. org/2001/XKMS) OASIS u WS-Security F u u u n SOAP Message Security specification etc. SAML: Security Assertion Markup Language XACML: Extensible Access Control Markup language Electronic Business XML (eb. XML) (with UN/CEFACT) Web Services Interoperability Organization (WS-I) u Basic security

Extensible Rights Markup Standardization Groups Language W 3 C OASIS XML Common Biometric Xr. ML Provisioning Formate. Xtensible (XCBF) Access Control XML Key Management. Markup Language (XACML) WS-Security Biometrics XML Encryption Specification XML Signature XKMS SAML Security Assertion Markup language XACML

Standardization Groups W 3 C WS-Secure Conversation WS-Security Policy WS-Federation OASIS WS-Trust Xr. ML WS-Authoriz. WS-Privacy Provisioning WS-Security (framework) XML Encryption XML Signature WS-Security XML Signature Kerberos XKMS profile XCBF profile XML Encryption. Biometrics Xr. ML profile SAML Username profile X. 509 profile XACML SAML profile

Who are specifying the higher level standards? n Liberty Alliance u u n n n Identity-based specifications (single sign-on, identity federation) Specifications build on SAML, SOAP, WAP, and XML. Microsoft (Passport, . . ) Open Mobile Alliance (OMA) Object Management Group (OMG) European Telecommunications Standards Institute (www. etsi. org) Organization for the Advancement of Structured Information Standards (OASIS) (www. oasisopen. org)

Who are implementing the standards? n n A lot of companies / initiatives Microsoft, Sun, NEC, Fuijtsu, RSA, IBM, Entrust, HP, DSTC, IAIK, Baltimore, Apache

Lecture outline n High-level view to WS Security u n n n WS Application-level security Standardization landscape Basic XML security Summary

Basic XML Security n n XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management

to know the message, Digital Signatures Need digest, and algorithm (f. e. SHA 1) Message Digest SIGN Private key Message Signature Asymmetric Key Pair Message Digest VERIFY Public key Pass/Fail

XML Digital Signatures n n n Digests calculated and a <Reference> created <Reference (URI=)? (Id=)? (Type=)? > (Transforms)? (Digest. Method)(Digest. Value)</Ref erence> Then a <Signature> element created from <Reference>, keying information, signature algorithm, and value u n The signature is actually calculated over the Signed. Info subset of this information NOTE: This means that the actual signature algorithm is ALWAYS applied to XML

XML Digital Signatures (cont. ) <Signature ID? > <Signed. Info> <Canonicalization. Method/> <Signature. Method/> (<Reference URI? > (<Transforms>)? <Digest. Method></Digest. Method> <Digest. Value></Digest. Value> </Reference>)+ </Signed. Info> <Signaturevalue></Signaturevalue> (<Key. Info>)? (<Object ID? >)* </Signature>

detached signature of the content o Canonicalization method: the. Signature HTML 4 inwhitespaces XML algorithm: DSA specification etc. Applied to (encryption), SHA-1 (digest) Reference to HTML 4 xmlns="http: //www. w 3. org/2000/09/xmldsig#"> XML Signed. Info [s 01] <Signature Id="My. First. Signature" [s 02] <Signed. Info>spec (detached) [s 03] <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-200 [s 04] <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#dsa-sha 1"/> [s 05] <Reference URI="http: //www. w 3. org/TR/2000/REC-xhtml 1 -20000126/"> Digest value calculated over [s 06] <Transforms> the identified data after [s 07] <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> gets signed! transformations [s 08] </Transforms> This is the output of. This canonic. [s 09] <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1"/> Mandatory processes: validation of the + digest + encrypt. For [s 10] <Digest. Value>j 6 lwx 3 rv. EPO 0 v. Kt. Mup 4 Nbe. Vu 8 nk=</Digest. Value> signature over Signed. Info and validation [s 11] </Reference> Key. Info. Signed. Info indicates the key to be of each Reference digest within [s 12] </Signed. Info> used to validate the signature [s 13] <Signature. Value>MC 0 CFFr. VLt. Rlk=. . . </Signature. Value> Signed. Info. [s 14] <Key. Info> [s 15 a] <Key. Value> [s 15 b] <DSAKey. Value> [s 15 c] <P>. . . </P><Q>. . . </Q><G>. . . </G><Y>. . . </Y> [s 15 d] </DSAKey. Value> [s 15 e] </Key. Value> [s 16] </Key. Info>

XML Digital Signatures (cont. ) n n The data being signed can be inside the <Signature>, within an <Object> element (enveloping), or external to the <Signature> in the same document or elsewhere (detached), or surrounding the <Signature> (enveloped), or any combination of these.

Signed. Info refers to object (sig is Enveloping Signature parent), object digested & thus in Signature. Value. Can be useful for Signature SOAP messages Signed. Info Reference Object Signed Data

Detached Signatures Signed data can be anywhere in the Local document XML Document Signed Data Signature Signed. Info Reference Or in some other location. Note that this Signed. Info refers to multiple docs.

The sig is in the Enveloped Signature signed document Signed Document Signature Signed. Info Reference as a child. For example: insert data to SOAP msgs

XML Signatures (cont. ) n To verify an XML digital signature u u n Verify the digests in each Reference, and Verify the signature value over the Signed. Info with the appropriate key and given signature algorithm Note that transformations are symmetric for creation / verification! (different from transformations for encryption)

What about <Transforms>? n A way to specify a sequence of algorithmic processing steps to apply u u to the results retrieved from a URI to Produce the data to be signed, verified, or decrypted. Can include compression, encoding, subset extraction, etc. For example using XPath Not needed in simple cases, but essential in complex cases

Basic XML Security n n XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management

Encryption Encrypt Public key Decrypt Asymmetric Key Pair Private key

XML Encryption n Provides two similar elements: u n n n <Encrypted. Data> and <Encrypted. Key> Such elements provide the encryption algorithm, keying information, and either the ciphertext or a URL to the ciphertext Default ciphers: symmetric block ciphers 3 DES, AES Key sharing (Retrieval. Method) u u u application context using Key. Name using Encrypted. Key F n Include the symmetric key by encrypting it using recipient’s public key Diffie-Hellman may also be used (Agreement method)

XML Encryption <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? <ds: Key. Info> <Encrypted. Key>? <Agreement. Method>? <ds: Keyname>? <ds: Retrieval. Method>? <ds: *>? </ds: Key. Info> <Cipher. Data> <Cipher. Value>? <Cipher. Reference URI? >? </Cipher. Data> <Encryption. Properties>? </Encrypted. Data>

Example: Element <? xml version='1. 0'? > <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> <Credit. Card Limit='5, 000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </Credit. Card> </Payment. Info> <? xml version='1. 0'? > <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> <Encrypted. Data Type='http: //www. w 3. org/2001/04/xmlenc#Element' xmlns='http: //www. w 3. org/2001/04/xmlenc#'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> </Payment. Info>

Example: Element Contents <? xml version='1. 0'? > <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> <Credit. Card Limit='5, 000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </Credit. Card> </Payment. Info> <? xml version='1. 0'? > <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> <Credit. Card Limit='5, 000' Currency='USD'> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. w 3. org/2001/04/xmlenc#Content'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> </Credit. Card> </Payment. Info>

Why Encryption is Easier than Signature n Ways are the same: u u Communicating the keying / algorithm / protocol information Communicate some ”random” binary information F u The encrypted data or the signature These are not too hard

Why Encryption is Easier than Signature n For signature only, you must communicate the original data that was signed u This data is usually changed as it is stored, transmitted, parsed, and processed e. g. F F n Character set and encoding Numeric / data / time representation Line endings XML Namespace prefixes Requirement for canonical representation of XML

Basic XML Security n n XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management

Why Canonicalization is Hard n Exactly the same sequence of data bytes must be used for signing as for verifying u u Problem of DTDs & Schemas Problem of white space Curse of namespaces The usual: F F F Encodings & character sets (UTF-8, . . ) Representations (<foo/>, <foo></foo>) Reordering of attributes

XML Canonicalization: DTDs and Schemas n XML provides for DTDs which can define abbreviations (”entities”), insert default attribute values, and change the normalization of attributes u n XML Schemas do similar things DTDs and Schemas can be internal or external and the same DTD/Schema processing must be done at both signing and verification

XML Canonicalization: White Space n n Indenting of XML makes it look free form With secure XML, this is an illusion u u u n You can never tell if white space in element content is significant, so it must be preserved <e>stuff and nonsense</e> <f>foo</f> <g/> </e> White space in start and end tags is not significant: <e z=”v ” a =’v 2’ >foo</e>

XML Canonicalization: Namespaces n Element and attribute names can be qualified with a ”namespace” prefix u n URIs are bound to arbitrary prefix names u n The prefix represents a URI tag For brevity and because namespace prefixes are separated by a colon This binding effects all nested XML, until overridden u When using signatures, namespace prefixes are signed also, if signature is inserted into another document the namespace definitions may change verification problem, for instance with SOAP

XML Canonicalization: Namespaces Example <e xmlns="http: //a. test" xmlns: foo="ftp: //b. example"> <default id="mumble"> <foo: bar q="value"> abc efg hijklmn opqrstuv </foo: bar> </default> <barbar foo: r="value">. . </barbar> </e>

XML Canonicalization: Namespaces Solution n Canonical XML specification imports ancestor namespace declaration u u n Protects against moving XML to a different context Changes in namespace binding invalidates signature Exclusive XML Canonicalization excludes, as much as practical, ancestor namespace declarations u u Permits XML to be encapsulated and decapsulated without breaking signatures W 3 C Recommendation F http: //www. w 3. org/TR/2002/REC-xml-exc-c 14 n 20020718/

XML URI Format n Before XML Security, there was no standard way of serializing URIs with miscellaneous UNICODE in them u u n %xx hex espace only espaces bytes, not characters Conversion to UTF-8 octets, which are hex escaped Canonicalization must specify a particular encoding (UTF-8) and exactly how to handle every special character on serializing and parsing URIs

Basic XML Security n n XML Digital Signatures (XMLDSIG) XML Encryption XML Canonicalization XML Key Management

XML Key Management (XKMS) n A Web Service that provides an interface to a PKI u u n Designed to manage the sharing of public keys u u n n Veri. Sign, Microsoft, web. Methods XKMS 1. 0 u n Managing includes verifying signatures Also includes encrypting messages XKMS takes complexity from the applications Originally from u n Abstracts PKI certificates Towards centralized PKI management (an enterprise resource vs. configured by end-clients) W 3 C Note 30 March 2001 XKMS 2. 0 u W 3 C Candidate Recommendation 5 April 2004

XML Key Management (XKMS) n The XML Key Management Specification (XKMS) comprises two parts u the XML Key Information Service Specification (X-KISS), and F u the XML Key Registration Service Specification (X-KRSS). F n n Retrieval of information about keys Store of information about keys Uses the SOAP 1. 1 protocol for communication, XML Schema, WSDL 1. 0 Based on XML Signatures

XKMS: XKRSS n XKRSS – XML Key Registration Service Specification u The X-KRSS specification defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including XKISS. u Allows registering key pairs u Saves the key pairs as <Key. Binding> elements u Supports backing up & restoring keys u Four services: register, recover, reissue, revoke

XKMS: XKISS n XKISS – XML Key Information Service Specification u defines a protocol for a Trust service that resolves public key information contained in XML-SIGelements. u The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds: Key. Info> elements u Enables clients to request <Key. Binding>’s associated with <Key. Info> elements u LOCATE operation – locates a requested key u VALIDATE operation – validates <Key. Binding>s u The underlying PKI may be based upon a different specification such as X. 509/PKIX, SPKI or PGP.

XKMS Key Concepts n Messages to & from a trusted server u n n Uses XML Signatures for key ownership Allows users to request a reply format u n These messages are bound to the SOAP protocol <Respond. With> Can specify what key is used for u <Use. Key. With>

Lecture Summary n n Topic to be continued next time XML security vs. security in general Application level security Basic standards u XML Signatures, XML Encryption