xml security in iodef inch wg, ietf56 march 19, 2003 yuri demchenko

XML Security in IODEF

INCH WG, IETF56

March 19, 2003Yuri Demchenko <[email protected]>

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


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

<Signature ID?> <SignedInfo>

<CanonicalizationMethod/> <SignatureMethod/>

(<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue>

</Reference>)+ </SignedInfo><SignatureValue> (<KeyInfo>)? (<Object ID?>)*

</Signature>


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


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


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>


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>


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>


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>


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


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.


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)


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


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.


Transform Algorithms

Canonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation


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 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 informationhttp://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 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 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>


Encryption: Processing Rules

For each EncryptedData and EncryptedKey the encryptor must :1. Select the algorithm (and parameters)2. Obtain and (optionally) represent the key3. 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.


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


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/


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/


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


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 inch wg, ietf56 march 19, 2003 yuri demchenko

Documents