XML Security in IODEF

1. XML Security in IODEF INCH WG, IETF56 March 19, 2003 Yuri Demchenko <demch@NLnetLabs.nl>

2. Outlines • XML Security Basics • XML Signature • XML Canonicalisation (reference) • XML Encryption • DonKey project at NLnet Labs: PK Management and XMLSig XML Security in IODEF

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 XML Security in IODEF

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 • 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) XML Security in IODEF

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 XML Security in IODEF

6. XML Signature structure • <Signature ID?>  • <SignedInfo>  <CanonicalizationMethod/> <SignatureMethod/>  (<Reference URI? >  (<Transforms>)?  <DigestMethod>  <DigestValue>  </Reference>)+ </SignedInfo> • <SignatureValue> (<KeyInfo>)? (<Object ID?>)*  • </Signature>  XML Security in IODEF

7. How to Create an XML Signature W3C REC: http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://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 XML Security in IODEF

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 Web • reference document with attached signature XML Security in IODEF

9. Calculate the digest of each resource • In XML signatures, each referenced resource is specified through a <Reference> element and its digest (calculated on the identified resource and not the <Reference> element itself) is placed in a <DigestValue> child element. • The <DigestMethod> element identifies the algorithm used to calculate the digest. • <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> • </Reference> XML Security in IODEF

10. Collect the Reference elements • Collect the <Reference> elements (with their associated digests) within a <SignedInfo> element. • The <CanonicalizationMethod> element indicates the algorithm was used to canonize the <SignedInfo> element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. • The <SignatureMethod> element identifies the algorithm used to produce the signature value. • <SignedInfo Id="foobar"> • <CanonicalizationMethod algorithm="http://www.w3.org/TR/2001/REC-xml-c14n"/> • <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> • </Reference> • </SignedInfo> XML Security in IODEF

11. Signing • Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element. • Signature Algorithms • DSA • PKCS1 (RSA-SHA1) • <SignatureValue>MC0E…LE=</SignatureValue> XML Security in IODEF

12. Add key information • If keying information is to be included, place it in a <KeyInfo> element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. • <!ELEMENT KeyInfo (#PCDATA | KeyName | KeyValue | RetrievalMethod | X509Data | PGPData | SPKIData | MgmtData | )*> • <KeyInfo> • <X509Data> • <X509SubjectName>CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, • C=CA</X509SubjectName> • <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate> • </X509Data> • </KeyInfo> XML Security in IODEF

13. Enclose in a Signature element • <!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)> • <!ELEMENT SignedInfo (CanonicalizationMethod, SignatureMethod, Reference+)> • Place the <SignedInfo>, <SignatureValue>, and <KeyInfo> elements into a <Signature> element. The <Signature> 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). XML Security in IODEF

14. Verifying an XML Signature • Verify the signature of the <SignedInfo> element • Recalculate the digest of the <SignedInfo> element (using the digest algorithm specified in the <SignatureMethod> element) • Use the public verification key to verify that the value of the <SignatureValue> element is correct for the digest of the <SignedInfo> element • If this step passes • Recalculate the digests of the references contained within the <SignedInfo> element and compare them to the digest values expressed in each <Reference> element's corresponding <DigestValue> element. XML Security in IODEF

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-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) XML Security in IODEF

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 XML Security in IODEF

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. XML Security in IODEF

18. Transform Algorithms • Canonicalisation • Base64 • XPath Filtering • Envelope Signature Transform • XSLT Transformation XML Security in IODEF

19. XML Signature: Security Consideration • Transforms • Only What is Signed is Secure • Only What is “Seen” is Secure • “See” What is Signed • Check the Security Model • Algorithms, Key Length, Certificates, etc. XML Security in IODEF

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 XML Security in IODEF

21. XML Encryption – Data Model • <EncryptedData Id? Type? MimeType? Encoding?> • <EncryptionMethod/>? • <ds:KeyInfo> • <EncryptedKey>? # extension to XMLSig KeyInfo • <AgreementMethod>? • <ds:KeyName>? • <ds:RetrievalMethod>? • <ds:*>? # • </ds:KeyInfo>? • <CipherData> # envelopes or references the raw encrypted data • <CipherValue>? • <CipherReference URI?>? # points to the location of the raw encrypted data • </CipherData> • <EncryptionProperties>? # e.g., timestamp • </EncryptedData> XML Security in IODEF

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. • <element name='CipherData' type='xenc:CipherDataType'/> • <complexType name='CipherDataType'> • <choice> • <element name='CipherValue' type='base64Binary'/> • <element ref='xenc:CipherReference'/> • </choice> • </complexType> XML Security in IODEF

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 • 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 • Encrypt the octets using the algorithm and key from steps 1 and 2 • 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. XML Security in IODEF

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‘ • 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 characters • 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'. XML Security in IODEF

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

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/ XML Security in IODEF

27. DonKey functionality • DonKey allows anyone to publish a named key, together with optional data (Donkey package) • Key MUST be signed, and Package MAY be signed by Owner • Donkey is NOT a permanent storage: key must be republished to remain available • Donkey does NOT define a policy for key/payload usage • This is an application specific function • 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 XML Security in IODEF

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