View
39
Download
0
Category
Tags:
Preview:
DESCRIPTION
XML Security in IODEF. INCH WG, IETF56 March 19, 2003 Yuri Demchenko . 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. - PowerPoint PPT Presentation
Citation preview
XML Security in IODEF
INCH WG, IETF56
March 19, 2003Yuri Demchenko <demch@NLnetLabs.nl>
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
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
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
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_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
March 19, 2003. San Francisco XML Security in IODEF Slide2_6
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_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
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 Web
• reference document with attached signature
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 <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_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>
March 19, 2003. San Francisco XML Security in IODEF Slide2_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>
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 <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_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).
March 19, 2003. San Francisco XML Security in IODEF Slide2_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.
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-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_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
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.
March 19, 2003. San Francisco XML Security in IODEF Slide2_18
Transform Algorithms
Canonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation
March 19, 2003. San Francisco XML Security in IODEF Slide2_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.
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 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
March 19, 2003. San Francisco XML Security in IODEF Slide2_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>
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.
<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_23
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.
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‘ 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_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/
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/
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)
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_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
Recommended