XML Security in IODEF

1
XML Security in IODEF

• INCH WG, IETF56
• March 19, 2003
• Yuri Demchenko ltdemch_at_NLnetLabs.nlgt

2
Outlines

• XML Security Basics
• XML Signature
• XML Canonicalisation (reference)
• XML Encryption
• DonKey project at NLnet Labs PK Management and
  XMLSig

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
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)

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
XML Signature structure

• ltSignature ID?gt 
• ltSignedInfogt  ltCanonicalizationMethod/gt
  ltSignatureMethod/gt  (ltReference URI?
  gt  (ltTransformsgt)?  ltDigestMethodgt  ltDigestV
  aluegt  lt/Referencegt) lt/SignedInfogt
• ltSignatureValuegt (ltKeyInfogt)? (ltObject ID?gt) 
• lt/Signaturegt 

7
How to Create an XML Signature

• W3C REC http//www.w3.org/TR/xmldsig-core/
• IETF Draft Standard http//www.ietf.org/rfc/rfc32
  75.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
Determine which resources are to be signed

• Resources are defined through a Uniform Resource
  Identifier (URI)
• http//www.abccompany.com/xml/po.xmlsender1 -
  references a specific element in an XML file on
  the Web
• reference document with attached signature

9
Calculate the digest of each resource

• In XML signatures, each referenced resource is
  specified through a ltReferencegt element and its
  digest (calculated on the identified resource and
  not the ltReferencegt element itself) is placed in
  a ltDigestValuegt child element.
• The ltDigestMethodgt element identifies the
  algorithm used to calculate the digest.
• ltReference URI"http//www.abccompany.com/news/200
  0/03_27_00.htm"gt ltDigestMethod Algorithm"http//w
  ww.w3.org/2000/09/xmldsigsha1" /gt
  ltDigestValuegtj6lwx3rvEPO0vKtMup4NbeVu8nklt/DigestV
  aluegt
• lt/Referencegt

10
Collect the Reference elements

• Collect the ltReferencegt elements (with their
  associated digests) within a ltSignedInfogt
  element.
• The ltCanonicalizationMethodgt element indicates
  the algorithm was used to canonize the
  ltSignedInfogt element. To help prevent inaccurate
  verification results, XML information sets must
  first be canonized before extracting their bit
  representation for signature processing.
• The ltSignatureMethodgt element identifies the
  algorithm used to produce the signature value.
• ltSignedInfo Id"foobar"gt
• ltCanonicalizationMethod algorithm"http//www.w3.
  org/TR/2001/REC-xml-c14n"/gt
• ltSignatureMethod Algorithm"http//www.w3.org/2000
  /09/xmldsigdsa-sha1" /gt ltReference
  URI"http//www.abccompany.com/news/2000/03_27_00.
  htm"gt ltDigestMethod Algorithm"http//www.w3.org
  /2000/09/xmldsigsha1" /gt ltDigestValuegtj6lwx3rvE
  PO0vKtMup4NbeVu8nklt/DigestValuegt
• lt/Referencegt
• lt/SignedInfogt

11
Signing

• Calculate the digest of the ltSignedInfogt element,
  sign that digest and put the signature value in a
  ltSignatureValuegt element.
• Signature Algorithms
• DSA
• PKCS1 (RSA-SHA1)
• ltSignatureValuegtMC0ELElt/SignatureValuegt

12
Add key information

• If keying information is to be included, place it
  in a ltKeyInfogt element. Here the keying
  information contains the X.509 certificate for
  the sender, which would include the public key
  needed for signature verification.
• lt!ELEMENT KeyInfo (PCDATA KeyName KeyValue
  RetrievalMethod X509Data PGPData SPKIData
  MgmtData )gt
• ltKeyInfogt
• ltX509Datagt
• ltX509SubjectNamegtCNEd Simon, OXMLSec Inc.,
  STOTTAWA,
• CCAlt/X509SubjectNamegt
• ltX509CertificategtMIID5jCCA0gA...lVNlt/X509Certif
  icategt
• lt/X509Datagt
• lt/KeyInfogt

13
Enclose in a Signature element

• lt!ELEMENT Signature (SignedInfo, SignatureValue,
  KeyInfo?, Object)gt
• lt!ELEMENT SignedInfo (CanonicalizationMethod,
  SignatureMethod, Reference)gt
• Place the ltSignedInfogt, ltSignatureValuegt, and
  ltKeyInfogt elements into a ltSignaturegt element.
  The ltSignaturegt 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
Verifying an XML Signature

• Verify the signature of the ltSignedInfogt element
• Recalculate the digest of the ltSignedInfogt
  element (using the digest algorithm specified in
  the ltSignatureMethodgt element)
• Use the public verification key to verify that
  the value of the ltSignatureValuegt element is
  correct for the digest of the ltSignedInfogt
  element
• If this step passes
• Recalculate the digests of the references
  contained within the ltSignedInfogt element and
  compare them to the digest values expressed in
  each ltReferencegt element's corresponding
  ltDigestValuegt element.

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)

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
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
Transform Algorithms

• Canonicalisation
• Base64
• XPath Filtering
• Envelope Signature Transform
• XSLT Transformation

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.

20
XML Encryption

• Encrypt an XML Element, XML Elements content
  (Elements), XML Elements 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
XML Encryption Data Model

• ltEncryptedData Id? Type? MimeType? Encoding?gt
• ltEncryptionMethod/gt?
• ltdsKeyInfogt
• ltEncryptedKeygt? extension to XMLSig KeyInfo
• ltAgreementMethodgt?
• ltdsKeyNamegt?
• ltdsRetrievalMethodgt?
• ltdsgt?
• lt/dsKeyInfogt?
• ltCipherDatagt envelopes or references the
  raw encrypted data
• ltCipherValuegt?
• ltCipherReference URI?gt? points to the
  location of the raw encrypted data
• lt/CipherDatagt
• ltEncryptionPropertiesgt? e.g., timestamp
• lt/EncryptedDatagt

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.
• ltelement name'CipherData' type'xencCipherDataTy
  pe'/gt
• ltcomplexType name'CipherDataType'gt
• ltchoicegt
• ltelement name'CipherValue' type'base64Binary'
  /gt
• ltelement ref'xencCipherReference'/gt
• lt/choicegt
• lt/complexTypegt

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., MimeTypetext/xml or
  MimeTypeimage/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
Decryption Processing Rules

• 1. Process the element to determine the
  algorithm, parameters and dsKeyInfo element to
  be used. If some information is omitted, the
  application MUST supply it.
• 2. Locate the data encryption key according to
  the dsKeyInfo 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'.

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/

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
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

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 Keygt must be
  unique
• Body
• Payload Application dependent (e.g., AA,
  Identity, SSO)
• Signatures
• Signed