XML Security in IODEF
INCH WG, IETF56
March 19, 2003
Yuri Demchenko <demch@NLnetLabs.nl>
Outlines





XML Security Basics
XML Signature
XML Canonicalisation (reference)
XML Encryption
DonKey project at NLnet Labs: PK Management and XMLSig
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_2
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_3
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)
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_4
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_5
XML Signature structure
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_6
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_7
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_8
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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_9
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-xmlc14n"/>
<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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_10
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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_11
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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_12
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).
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_13
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.
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_14
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)
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_15
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_16
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.
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_17
Transform Algorithms





Canonicalisation
Base64
XPath Filtering
Envelope Signature Transform
XSLT Transformation
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_18
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.
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_19
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_20
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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_21
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>
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_22
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.

March 19, 2003. San Francisco
XML Security in IODEF
Slide2_23
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'.
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_24
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/
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_25
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/
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_26
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
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_27
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
 Body

– Payload
# Name, Owner Key> must be unique
# Application dependent (e.g., AA, Identity, SSO)
 Signatures
 Signed
March 19, 2003. San Francisco
XML Security in IODEF
Slide2_28