1. XML Security in IODEF INCH WG, IETF56 March 19, 2003 Yuri Demchenko

2. March 19, 2003. San Francisco XML Security in IODEF Slide2 _2 Outlines  XML Security Basics  XML Signature  XML Canonicalisation (reference)  XML Encryption  DonKey project at NLnet Labs: PK Management and XMLSig

3. March 19, 2003. San Francisco XML Security in IODEF Slide2 _3 XML: Schema vs DTD and XML Protocol DTD is document-oriented  Like HTML Schema is data-oriented  XML Signature  SAML Basic XML Protocol(s)  XML-RPC  SOAP

4. March 19, 2003. San Francisco XML Security in IODEF Slide2 _4 XML Security vs traditional (network) security Traditional Security:  Host-to-host or point-to-point security  Client/server oriented  Connection or connectionless oriented  Generically single/common trust domain/association XML Security  Document oriented approach u Security tokens/assertions and policies can be associated with the document or its parts  Intended to be cross-domain  Potentially for virtual and dynamic trust domains (security associations)

5. March 19, 2003. San Francisco XML Security in IODEF Slide2 _5 XML Signature: Features Fundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document.  XML document may have a long history when different component are authored by different parties at different times  Different parties may want to sign only those elements relevant to them  Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed  Allows carrying security tokens/assertions on document/data rather than on user/client  Provides security features for XML based protocols

6. March 19, 2003. San Francisco XML Security in IODEF Slide2 _6 XML Signature structure ( ( )? )+ ( )? ( )*

7. March 19, 2003. San Francisco XML Security in IODEF Slide2 _7 How to Create an XML Signature W3C REC: http://www.w3.org/TR/xmldsig-core/http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://www.ietf.org/rfc/rfc3275.txthttp://www.ietf.org/rfc/rfc3275.txt 1. Determine which resources are to be signed 2. Calculate the digest of each resource 3. Collect the Reference elements 4. Signing 5. Add key information 6. Enclose in a Signature element

8. March 19, 2003. San Francisco XML Security in IODEF Slide2 _8 Determine which resources are to be signed Resources are defined through a Uniform Resource Identifier (URI) http://www.abccompany.com/xml/po.xml#sender1 - references a specific element in an XML file on the Webhttp://www.abccompany.com/xml/po.xml#sender1 reference document with attached signature

9. March 19, 2003. San Francisco XML Security in IODEF Slide2 _9 Calculate the digest of each resource In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element. The element identifies the algorithm used to calculate the digest. j6lwx3rvEPO0vKtMup4NbeVu8nk=

10. March 19, 2003. San Francisco XML Security in IODEF Slide2 _10 Collect the Reference elements Collect the elements (with their associated digests) within a element. The element indicates the algorithm was used to canonize the element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. j6lwx3rvEPO0vKtMup4NbeVu8nk=

11. March 19, 2003. San Francisco XML Security in IODEF Slide2 _11 Signing Calculate the digest of the element, sign that digest and put the signature value in a element. Signature Algorithms  DSA  PKCS1 (RSA-SHA1) MC0E…LE=

12. March 19, 2003. San Francisco XML Security in IODEF Slide2 _12 Add key information If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, C=CA MIID5jCCA0+gA...lVN

13. March 19, 2003. San Francisco XML Security in IODEF Slide2 _13 Enclose in a Signature element Place the,, and elements into a element. The element comprises the XML signature. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be referenced by a URI within the XML signature; reside within the same resource as the XML signature (the signature is a sibling); be embedded within the XML signature (the signature is the parent); have its XML signature embedded within itself (the signature is the child).

14. March 19, 2003. San Francisco XML Security in IODEF Slide2 _14 Verifying an XML Signature Verify the signature of the element  Recalculate the digest of the element (using the digest algorithm specified in the element)  Use the public verification key to verify that the value of the element is correct for the digest of the element If this step passes  Recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element.

15. March 19, 2003. San Francisco XML Security in IODEF Slide2 _15 Canonicalisation (1) The canonical form of an XML document is physical representation of the document produced by the canonicalisation method that implies the following changes. Encoding and characters The document is encoded in UTF-8UTF-8 Line breaks normalized to #xA on input, before parsing Whitespace outside of the document element and within start and end tags is normalized All whitespace in character content is retained (excluding characters removed during line feed normalization)

16. March 19, 2003. San Francisco XML Security in IODEF Slide2 _16 Canonicalisation (2) Elements and references Character and parsed entity references are replaced CDATA sections are replaced with their character content The XML declaration and document type declaration (DTD) are removed Empty elements are converted to start-end tag pairs Attributes Attribute values are normalized, as if by a validating processor Attribute value delimiters are set to quotation marks (double quotes) Special characters in attribute values and character content are replaced by character references Superfluous namespace declarations are removed from each element Default attributes are added to each element Lexicographic order is imposed on the namespace declarations and attributes of each element

17. March 19, 2003. San Francisco XML Security in IODEF Slide2 _17 XPath Data Model for Canonicalisation XML canonicalization is defined in terms of the XPath definition of a node-set. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order:  normalize line feeds  normalize attribute values  replace CDATA sections with their character content  resolve character and parsed entity references The input octet stream MUST contain a well-formed XML document, but the input need not be validated. The declarations in the document type declaration are used to help create the canonical form.

18. March 19, 2003. San Francisco XML Security in IODEF Slide2 _18 Transform Algorithms  Canonicalisation  Base64  XPath Filtering  Envelope Signature Transform  XSLT Transformation

19. March 19, 2003. San Francisco XML Security in IODEF Slide2 _19 XML Signature: Security Consideration  Transforms u Only What is Signed is Secure u Only What is “Seen” is Secure u “See” What is Signed  Check the Security Model  Algorithms, Key Length, Certificates, etc.

20. March 19, 2003. San Francisco XML Security in IODEF Slide2 _20 XML Encryption  Encrypt an XML Element, XML Element’s content (Elements), XML Element’s content (Character Data), or arbitrary data ad documents  Can be used for Key transport  Can be used in combination with XML Signature More information http://www.w3c.org/TR/xmlenc-core/ http://www.w3.org/TR/xmlenc-decrypt/ http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-04.txt

21. March 19, 2003. San Francisco XML Security in IODEF Slide2 _21 XML Encryption – Data Model ? ? # extension to XMLSig KeyInfo ? ? # ? # envelopes or references the raw encrypted data ? ? # points to the location of the raw encrypted data ? # e.g., timestamp

22. March 19, 2003. San Francisco XML Security in IODEF Slide2 _22 XML Encryption: CipherData Element Contains the encrypted octet sequence as base64 encoded text of the CipherValue element, or provides a reference to an external location containing the encrypted octet sequence via the CipherReference element.

23. March 19, 2003. San Francisco XML Security in IODEF Slide2 _23 Encryption: Processing Rules For each EncryptedData and EncryptedKey the encryptor must : 1. Select the algorithm (and parameters) 2. Obtain and (optionally) represent the key 3. Encrypt the data u If the data is an ”element” or element “content”, obtain the octets by serialising the data in UTF-8; any other data must be serialised as octets u Encrypt the octets using the algorithm and key from steps 1 and 2 u Provide type of presentation to indicate how to obtain and interpret the plaintext octets after decryption (e.g., MimeType=“text/xml” or MimeType=“image/png”) 4. Build the EncryptedType ( EncryptedData or EncryptedKey) 5. Process EncryptedData  If the Type of the encrypted data is ”element” or element “content”, then encryptor SHOULD be able to replace the unencrypted “element” or “content” with the EncryptedData element.  If the Type of the encrypted data is ”element” or element “content”, then encryptor MUST always be able to return the EncryptedData to the application.

24. March 19, 2003. San Francisco XML Security in IODEF Slide2 _24 Decryption: Processing Rules 1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it. 2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. 3. Decrypt the data contained in the CipherData element – depending on existence of CipherValue or CipherReference child elements 4. Process decrypted data of Type 'element' or element 'content‘elementcontent  The cleartext octet sequence (from step 3) is interpreted as UTF-8 encoded character data  The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. Validation on the serialized XML is NOT REQUIRED.  The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted 'element' or element 'content' represented by the UTF-8 encoded characterselementcontent 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'.elementcontent

25. March 19, 2003. San Francisco XML Security in IODEF Slide2 _25 Available tools  Not many OpenSource, especially for Windows u Java based u Refer to –http://www.w3.org/Signature/#Code –http://www.w3.org/Encryption/2001/#Code  Commercial u MS Visual Studio u IBM AlphaWorks  Coming soon - DonKey client by NLnet Labs http://www.nlnetlabs.nl/donkey/

26. March 19, 2003. San Francisco XML Security in IODEF Slide2 _26 DonKey Project Goal(s) Open extendable system for public key and Identity management Initial stage Open global distributed system for publishing and retrieving named, signed public keys together with associated/bound information Intended development Identity management for federated cross-domain AuthN and AuthZ Donkey website: http://www.nlnetlabs.nl/donkey/

27. March 19, 2003. San Francisco XML Security in IODEF Slide2 _27 DonKey functionality  DonKey allows anyone to publish a named key, together with optional data (Donkey package) u Key MUST be signed, and Package MAY be signed by Owner u Donkey is NOT a permanent storage: key must be republished to remain available u Donkey does NOT define a policy for key/payload usage –This is an application specific function u Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match  Donkey allows anyone to query for a published key, based on the key's name (required) and signers (optional)  Donkey allows anyone to sign a published key

28. March 19, 2003. San Francisco XML Security in IODEF Slide2 _28 DonKey design issues: Package structure (Proprietary) Internal format (currently: Python data object) but XML based exchange format  Package ID  Content u Header –Flags –Names u Owner Public Key # Name, Owner Key> must be unique u Body –Payload# Application dependent (e.g., AA, Identity, SSO)  Signatures  Signed