Announcements

1. T-110.5140 Network Application Frameworks and XML Web Service Security11.04.2006Sasu Tarkoma Based on slides by Pekka Nikander

2. Announcements • A list of papers to read for the final exam • Bob Braden, Architectural Principles of the Internet, IPAM Tutorial March 12, 2002. • Jukka Ylitalo and Pekka Nikander, A new Name Space for End-Points: Implementing secure Mobility and Multi-homing across the two versions of IP, in Proceedings of the Fifth European Wireless Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441, Barcelona, Spain, February 24-27, 2004. • Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. Proceedings of ACM SIGCOMM 2005. August 2005.

3. Contents • Web service security • Security contexts • Review • WS-Security Standard • SAML • XACML • Summary

4. Web Services Security Requirements • Protect messaging across domains • Convey security information in messages • Make security decisions and communicate them between parties • Tools at hand • WS-Security, XML-Signature • SAML • XACML • Digital certificate validation • Content-filtering XML • Filters based on data format (XSD) • Filters based on content (XPath) • Filters based on integrity (XML Signature)

5. XML XML Functional point of view Management Console Design and Deploy Security policies ID Management LDAP PKI Single Sign-On Authorization Authentication Content Checking Reporting Activity Alerting Secure logging Integrity Validation Routing

6. Security Contexts in Web Services • Remember Web Services goals: • Re-use existing services • Combine services from several domains • Security result: Must support several security domains • SOAP intermediaries • Reusing security tokens from one message in another message

7. Security Context II Security Context I HTTP POST SOAP Example 1: Pass subject details Web Browser Website Appl. Server Web Service Main Point: We need security within AND between security contexts!

8. Security Context II Security Context I SOAP HTTP SOAP SMTP Example 2: SOAP Routing Main Point: We need XML validation, encryption, and authentication between security contexts!

9. Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp

10. Review

11. W3C OASIS Standardization Groups XrML Provisioning WS-Security Biometrics XML Encryption XML Signature XKMS SAML XACML

12. Message Digest Message Digest SIGN VERIFY Signature Pass/Fail Private key Public key Asymmetric Key Pair Digital Signatures Need to know the message, digest, and algorithm (f.e. SHA1) Message

13. XML Digital Signatures (cont.) <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?> (<Transforms>)? <DigestMethod></DigestMethod> <DigestValue></DigestValue> </Reference>)+ </SignedInfo> <Signaturevalue></Signaturevalue> (<KeyInfo>)? (<Object ID?>)* </Signature>

14. Encrypt Decrypt Public key Private key Asymmetric Key Pair Encryption

15. XML Encryption <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:Keyname>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo> <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>

16. WS Security I • Web Services Security: SOAP Message Security • 1.0 (Oasis Standard 2004) • 1.1 (Oasis Standard 2006) • Extensions in: security token support, message attachments and rights management. • End-to-End security • Headers are decrypted and processed as needed • Selective processing • Some parts are plain text • Some are encrypted • Some are signed • How does it work? • SOAP header carries security information (and other info as well)

17. WS Security II • Ability to send security tokens as part of a message, message integrity, and message confidentiality • Security model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messages • An X.509 is an example of a signed security token endorsed by a CA. • When third party support is not available, receiver may choose to accept the claims in the token based on trust on the entity that sent the message.

18. Goals • Multiple security token formats • Multiple trust domains • Multiple signature formats • Multiple encryption technologies • End-to-end message content security and not just transport-level security

19. Non-goals • Establishing a security context or authentication mechanism • Key derivation • Advertisement and exchange of security policy • How trust is established or determined • Non-repudiation

20. Message Protection • Integrity mechanism designed to support multiple signatures • Uses XML Signature and XML Encryption • Syntax and semantics of signatures within a <wsse:Security> element • This is the security block in the SOAP header • SOAP actor/role attribute is used to target header blocks • Security element includes • Security tokens • Information about the use of XML Encryption & Signature in the SOAP header/body/combination

21. Security Header • May be present multiple times in a SOAP message • Must have different actor/role attribute values • Unrecognized extension elements or attributes should cause a fault • Receivers MAY ignore elements or extensions within the <wsse:Security> element, based on local security policy. • But they must understand them first <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap=""..." xmlns:wsu="...” xmlns:wsse="..."> <soap:Header> <wsse:Security soap:mustUnderstand=”..”>..</wsse...> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope>

22. Security Element: enclosing information • UsernameToken block • Defines how username-and-password info is enclosed in SOAP • Password must be protected against eavesdroppers (enc) and replay (timestamp/nonce) • BinarySecurityToken block • Encloses binary data • An X.509 certificate or a Kerberos ticket • Has an identifier (Id), a value (ValueType), and an encoding (EncodingType) • XML Signature KeyInfo may point to a certificate used in signing using a Reference to its Id. • Similar for XML Encryption. • So we can sign/encrypt data with a certificate in the header.

23. ID References • A new global attribute: wsu:Id attribute • <anyElement wsu:id=”..”>..</anyElement> • Note that the SOAP processor needs to support this • wsu:id a WS-Security namespace (wssecurity-secext-1.0.xsd) • Recipients do not need to understand the full schema of the message for processing the security elements • Two wsu:Id attributes within an XML document MUST NO have the same value • Recommended that wsu:Id is used instead of a more general transformation, especially XPath

24. Signatures • Does not use the Enveloped Signature Transform • So sig does not envelope signed data • Due to mutability of SOAP header • Does not use the Enveloping Signature • So sig is not appended as a child to the document • The sig is appended to the security block • Explicitly include the elements to be signed • Allows for extensions, multiple signatures, etc.

25. Canonicalization • XML Canonicalization and Exclusive XML Canonicalization • Problems • XML tools change documents, e.g. duplicate namespace declarations can be removed or created • Signature simply covers something like xx:foo, its meaning may change if xx is redefined • There are mechanisms like XPath, which consider xx=”http://example.com”; to be different from yy=”http://example.com/”

26. Canonicalization • <example b=”22” a=11></example> <example b=”22” a=11></example> <example a=”11” b=22></example> • <example a=”11” b=22/>

27. Inclusive Canonicalization • Copies all the declarations that are currently in force • Useful in the typical case of signing part or all of the SOAP body • Causes problems for signatures when the context changes (for example by intermediaries)

28. Exclusive Canonicalization • Tries to figure out what namespaces are actually used and just copies those • Does not look into attribute values or element content • Can happen implicitly because XML processing tools will add xsi:type if schema subtypes are used • Useful when you have an XML document that you wish to insert into another XML document • Example: signed SAML assertion • Should be used with WS-Security: SOAP Message Security (recommended)

29. Signing Messages • Multiple signature entries MAY be added into a single SOAP Envelope within one <wsse:Security> header block • MUST be prepended to the existing content • <ds:Reference> elements contained in the signature should refer to a resource within the enclosing SOAP envelope • <wsse:SecurityTokenreference> • How to locate a key in a security token? • Extensible mechanism that provides an open content model for referencing security tokens • Specification considers only use in a header block • New reference option for XML signature • STR Deference Transform • Applied to a SecurityTokenreference • Means that the output is the token referenced by the element, not the element itself • You can conveniently locate and sign security tokens anywhere in the header

30. Example • SOAP Envelope • SOAP Header • WS Security • Security token (a certificate) • Encryption key (passing symmetric key) • Signature • SOAP Body • Encrypted content

31. Security block Overall message structure <?xml version="1.0" encoding="utf-8"?> <soap:Envelope> <soap:Header> <wsse:Security> <wsse:BinarySecurityToken>...</wsse:Binary...> <xenc:EncryptedKey>...</xenc:EncryptedKey> <ds:Signature> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo>...</ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="body"> <xenc:EncryptedData>...</xenc:EncryptedData> </soap:Body> </soap:Envelope> 1. 2. 3. 4.

32. 1. Binary security token <wsse:Security> <wsu:Timestamp wsu:Id="T0"> <wsu:Created> 2001-09-13T08:42:00Z </wsu:Created> </wsu:Timestamp> <wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token" EncodingType="...#Base64Binary"> ABCDEF.... </wsse:BinarySecurityToken> <xenc:EncryptedKey>...</xenc:EncryptedKey> <ds:Signature>...</ds:Signature> </wsse:Security>

33. 2. Passing encryption key We are using another certificate for asymmetric crypto. This one is for symmetric <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="...#rsa-1_5"/> <ds:KeyInfo> <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509v3"> ABCDEF.... </wsse:KeyIdentifier> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#enc1"> </xenc:ReferenceList> </xenc:EncryptedKey> Encrypted symmetric key Reference to cipher data

34. 3. Actual signature <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod algorithm="http://...-exc-c14n#"/> <ds:SignatureMethod algorithm="http://...#rsa-sha1"/> <ds:Reference URI="#T0">...</ds:Reference> <ds:Reference URI="#body">...</ds:Reference> …. </ds:SignedInfo> <ds:SignatureValue> ..... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> Exclusive canonicalization References & digests to data Reference to certificate.

35. 3. SignedInfo in more detail <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://...-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://...#rsa-sha1"/> <ds:Reference URI="#T0"> <ds:Transforms> <ds:Transform Algorithm="http://...exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://...#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> <ds:Reference URI="#body"> <ds:Transforms> <ds:Transform Algorithm="http://...exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://...#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> </ds:SignedInfo>

36. 4. Actual message body <soap:Body wsu:Id="body"> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" wsu:Id="enc1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soap:Body> </soap:Envelope>

37. Error Handling • SOAP Faults are used to indicate faults • Error scenarios • Security token type unsupported • Note: WS-Policy may be used to convey what security tokens can be understood by different parties • Fault code: InvalidSecurity (if contents of the header block cannot be processed) • Invalid security token • For example: security token corrupted or has invalid signature • Fault code: InvalidSecurityToken • Security token cannot be authenticated • For example: given certificate cannot be validated • Fault code: FailedAuthentication • Security token unavailable • For example: a certificate was referenced that could not be located • Fault code: wsse:SecurityTokenUnavailable

38. Extensions in 1.1 • Builds on 1.0 • WS-Security 1.1 extensions include • EncryptedKeyToken security token • Represents a security token for an encrypted symmetric key. • EncryptedHeader block • Protect any header block, also nested • Digital signature confirmation • A digital signature confirmation is a SOAP message that a Web service sends to a client that confirms that it verified the client's digital signature.

39. SAML • SAML (Security Assertion Markup Language) • A XML-based framework (schemas) for the exchange of authentication and authorization information • A standard message exchange protocol • How you ask and receive information • Mainly for integration, up to relying parties to decide to what authentication authority to trust • Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources • Authentication statements merely describe acts of authentication that happened previously • Specified by OASIS

40. SAML in a nutshell • XML-based framework for exchanging security information • XML-encoded security assertions • XML-encoded request/response protocol • Rules on using assertions with standard transport and messaging frameworks • SAML & WS-Security allow a SOAP message to include information about the end-user’s authentication status

41. Domain A Domain B User User Service Service Authentication server A Authentication server B SAML Motivation: Portable Trust Using services in B from A? Authentication at B? Not acceptable!

42. Domain A Domain B User User Service Service Authentication server A Authentication server B Timed updates Timed updates Authentication server C

43. SAML assertions • An assertion is a declaration of fact about a subject, e.g. a user • According to some assertion issues • SAML has three kinds, all related to security: • Authentication • Attribute • Authorization decision • You can extend SAML to make you own kinds of assertions • Assertions can be digitally signed

44. All assertions have some common information • Issuer and issuance timestamp • Assertion ID • Subject • Name plus the security domain • Optional subject information, e.g. public key • ”Conditions” under which assertion is valid • SAML clients must reject assertions containing unsupported conditions • Special kind of condition: assertion validity period • Additional ”advice” • E.g. to explain how the assertion was made

45. Authentication assertion • An issuing authority asserts that: • Subject S • was authenticated by means M • at time T • Caution: actually checking or revoking of credentials is not in the scope of SAML! • Password exchange • Challenge-response • Etc. • It merely lets you link back to acts of authentication that took place previously

46. Example authentication assertion <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="127.0.0.1.1234567" Issuer="Example Corp" IssueInstant="2005-04-04T09:00:00Z"> <saml:Conditions NotBefore="2005-04-04T09:00:00Z" NotAfter=""2005-04-04T09:05:00Z"/> <saml:AuthenticationStatement AuthenticationMethod="password" AuthenticationInstant="2005-04-04T09:01:00Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe"/> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

47. Attribute assertion • An issuing authority asserts that: • subject S • is associated with attributes A,B,.. • with values ”a”,”b”,… • Typically this would be gotten from an LDAP repository • ”john.doe” in ”example.com” • is associated with attribute ”Department” • with value ”Human Resources”

48. Example attribute assertion <saml:Assertion ...> <saml: Conditions .../> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" /> </saml:Subject> <saml:Attribute AttributeName="PaidStatus" AttributeNameSpace="http://example.com"> <saml:AttributeValue> PaidUp </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

49. Authorization decision assertion • An issuing authority decides whether to grant the request • by subject S • for access type A • to resource R • given evidence E • The subject could be a human or a program • The resource could be a web page or a web service, for example

50. Example authorization decision assertion <saml:Assertion ...> <saml:Conditions .../> <saml:AuthorizationStatement Decision="Permit" Resource="http://example.com/res123"> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" /> </saml:Subject> </saml:AuthorizationStatement> </saml:Assertion>