840 likes | 984 Views
Building Secure Web Services Today. K. Scott Morrison Director, Architecture Layer 7 Technologies. Who Am I?. K. Scott Morrison Director, Architecture at Layer 7 Technologies Layer 7 builds security products for Web services
E N D
Building Secure Web Services Today K. Scott Morrison Director, Architecture Layer 7 Technologies
Who Am I? • K. Scott Morrison • Director, Architecture at Layer 7 Technologies • Layer 7 builds security products for Web services • Previous positions include Director at Infowave Software and Senior Architect at IBM’s Pacific Development Centre in Vancouver • Over 30 publications, including book chapters, magazines, scientific journals, etc • Including Java Web Services Unleashed (Sams) and Professional JMS (Wrox)
Today’s Goals • Make sense of the alphabet soup of Web services security standards • Impress your friends… • Understand the major technical trends in Web services security • Know what is available today to secure web services both commercially and in open source
The Disclaimer • I’m not endorsing any particular vendor’s product by mentioning it • Nor am I making any statement about a vendor’s product by omitting it from a list • It’s pretty hard to make a list comprehensive when products and technologies are moving so fast
Something To Consider • I’m presenting technical solutions that implement security technique here • However, more important may be the legal and social issues surrounding security • What does a digital signature really mean when crossing into different jurisdictions? • How do we reconcile existing contract laws? • Remember: Security is a process, not just a technology
Agenda • Security and Web services • VPN solutions • SSL solutions • What we really need • Fundamental standards • Canonicalization, signing, & encryption • WS-Security technologies
Agenda (cont.) • SAML • XACML • XKMS • XrML • P3P • XCBF • Future directions • Technology • Standards
Fundamentals of Security ISO 7498-2, 10181
Security is all about trust • Sometimes trust relationships are obvious • However, very often the are not. Implicit, unacknowledged trust can be very dangerous • The application security model does not trust client, but the OS security model does. • I trust that clocks are in sync Access to file blocked through Web server HTTP-based trust relationship HTTP, TCP port 80, basic authentication Windows domain-based trust relationship NTFS, using NTLM-based security But the underlying distributed file system provides access
Why does this matter to web services? • The fundamental model of Internet Security is the mapping of port to application. • IANA known ports, 0-1023, registered ports 1024-49151, dynamic ports 49152 to 65535 • Eg for TCP: HTTP=80, SMTP=25, FTP=20&21 • See http://www.iana.org/assignments/port-numbers for a pretty up-to-date list Incoming socket request for port (RPCs may call portmapper before this) Server Programs inetd Similar mechanism on non-UNIX systems (Port, protocol to service mapping) /etc/inetd.conf
Why does this matter to web services? Firewall passes TCP port 80 and 443 • Web services breaks this. • But SOAP on its own does not address security • OK in a trusted environment (eg: standalone, secure network) • Fortunately, the point of SOAP is that it’s extensible • Security can be added in by many parties • Contrast with the traditional, monolithic, single-source approach (CORBA, COM+, etc) Internet
Attempt #1 – The VPN IPSEC protects all protocol traffic about IP (eg: TCP, UDP) The last mile may be unprotected…. Internet ISP Web Services Server Firewall Corporate Network VPN client software
VPN Benefits • Mature and well-deployed technology • Fast • Administrative security, not programmatic security • This is more important than it sounds. It centralizes control into the hands of security professionals
VPN Issues • Complexity, manageability, cost • There are still big issues with interoperability • Not insignificant NAT traversal issues • IPSEC NAT-T is one solution, plus other proprietary solutions • The last mile may be insecure • Identity is client account oriented • No fine grained control • Really, this is just coarse authentication, confidentiality, integrity, with some simple key mgmt • What about authorization? • Simply providing general access to one group of users • Non-repudiation? • All-or-nothing encryption means we can’t audit, route effectively. Intermediates become a problem
VPNs Are Widely Available • Commercial: • Check Point • Nortel • NetScreen • Lucent • Avaya • …and many more • Bundled packages • Windows 2000 VPN server • IBM’s AIX • BSD
VPNs Are Widely Available • Open Source • FreeS/WAN http://www.freeswan.org/intro.html (linux) • OpenVPN http://openvpn.sourceforge.net/ (various Unix) • tinc http://tinc.nl.linux.org/ (various Unix) • PoPToP (PPTP implementation) http://www.poptop.org/ (linux, plus some other Unix ports) • … and many more
Attempt #1.5 – Firewall Inspection <wsse:UsernameToken wsu:Id="..."> <wsse:Username> ... </wsse:Username> <wsse:Password Type="..."> ... </wsse:Password> <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> <wsu:Created> ... </wsu:Created> </wsse:UsernameToken> Directory Server Internet Web Services Client Web Services Server Corporate Network Admin Console
FW Inspection Benefits • Logical bundle with a VPN • Builds on a well-known and understood technology • Can provide finer-grained authentication and authorization • Simple routing decisions • Capability appearing in many firewalls
FW Inspection Issues • Message parsing overhead • Deep packet inspection is not what most conventional firewalls designed for • Complexity of firewall programming • Doesn’t address other important areas of security • Non-repudiation • Doesn’t accommodate intermediates
Dshfsdkhfsl Sdfshds dsf sdf fd lsdhfsldkfhsdl Dshfsdkhfsl Sdfshds dsf sdf fd lsdhfsldkfhsdl Attempt #2 – SSL/TLS and HTTP Firewall open to TCP port 443 Internet Web Services Server Server certificate Optional client certificate Corporate Network
SSL/TLS Benefits • Mature and well-understood technology • Consistent with “borrow from the web” philosophy of Web services • Encryption can be offloaded to dedicated hardware • Key management relatively easy • Certificate distribution infrastructure • Easy to implement after clear-text testing
SSL/TLS Issues • Authentication/authorization delegated to HTTP methods • Implies possibly undesirable transport coupling • “Borrow from the Web” taken too far • This is channel encryption, not message encryption • No real non-repudiation
? ? ? ? Dshfsdkhfsl Sdfshds dsf Dshfsdkhfsl Sdfshds dsf Dshfsdkhfsl Sdfshds dsf SSL/TLS Issues (cont) • The intermediate problem. Two options: Stateful channel persistence SSL Tunneling HTTP Connect method Internet ? End-to-end encrypted channel Segmented Encrypted Channels Internet Internet Wildly unpopular. Look at WAP…
Easy To Implement • Virtually all major Web servers support it. Configuration is generally straightforward • Eg: Tomcat: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html (plus other versions) • SSL standard in JDK since 1.4 • Abstracted in URLConnection • Local truststore issues. Don’t forget to import trusted CA • Eg: keytool -import -alias tomcat -file server.cer -keystore "C:\j2sdk1.4.1\jre\lib\security\cacerts“ • Various vendors have kits for pre 1.4 Java (Baltimore Keytools, RSA BSAFE, IAIK iSaSiLk)
Easy To Implement • In C/C++ • OpenSSL (http://www.openssl.org/). SSL V2./3 and TLS v1. • Evolution of SSLeay. • ApacheSSL (http://www.apache-ssl.org/) • RSA BSAFE SSL C (http://www.rsasecurity.com/products/bsafe/sslc.html) • Baltimore Keytools (http://www.baltimore.com/keytools/ssl/index.asp) • MS .NET support is extensive
These Are OK, But What Do We Really Need? • Decoupling of security and transport • Messages may pass through multiple transports/hops • At any intermediate, certain parts of the message may need to be processed • There is value in parts of messages being in the clear. • Only encrypt what we need to support the security policy • Sign at each hop • We can’t rely on continuity of socket for state/authentication, etc • This is really hard, because so much of traditional security relies on context established through transport session continuity • This means that we can’t encrypt the channel end-to-end • Need Authenticated messages • Lots of issues, including flow order, replay issues, etc
These Are OK, But What Do We Really Need (cont.)? • Most important, we need a way of: • Signing message parts • Requires canonicalization • Encrypting message parts The Fundamental need in all security
The Fundamental Standards • W3C Canonical XML • W3C XML Digital Signature • W3C XML Encryption Note which organization these came from. It’s important to understand the shifting politics of Web services standards…
W3C Canonical XML • Consider: <A> <B> some text </B> <C a1=“v1” a0=“v0”></C> <D a2=“v1”></D> <E/> </A> <A> <B> some text </B> <C a0=“v0” a1=“v1”></C> <D a2=“v1”></D> <E a3=“Default”></E> </A> = • Two physically different, but logically identical documents • 1 canonical form • This has significance when signing documents
W3C Canonical XML • White space ambiguities • Empty element to start/end tag pair • Lexicographic ordering of attributes and namespaces • Removal of DTD • Resolution of entity references • Normalization of quotes around attribute values …etc. It’s actually a very extensive list. See the spec for details. It’s worth reading, because it really demonstrates the need for rigorous processing models for XML in the face of a number of subtle ambiguities
W3C Canonical XML BTW: C14n=Canonicalization (C+14 letters+n) • XML Canonicalization (inclusive) • Latest spec is version 1.0. It’s a W3C Recommendation, dated 15 March 2001 • http://www.w3.org/TR/xml-c14n • Exclusive Canonicalization deals with ignoring ancestor content (specifically namespaces) in subdocuments • Latest spec is version 1.0. It’s a W3C Recommendation, dated 18 July 2002 • http://www.w3.org/TR/xml-exc-c14n/
XML Digital Signatures • Need finely grained application • Sign the whole document, or only a portion • Need application across more than just XML • Binary content (images, compiled code, etc) • User-defined properties using <SignatureProperties> • Eg: timestamp, crypto metadata, etc • Can be used with public key crypto (specifically DSA and RSA) or Message Authentication Code (MAC, specifically SHA1-HMAC) • But note that MAC does not provide non-reputability! • More info on key-hashing for message authentication (HMAC): http://www.ietf.org/rfc/rfc2104.txt?number=2104
3 Types of Signatures • Enveloped • Enveloping • Detached Signature and signed content are merged into a single document Signature references external content
Enveloped Signature <Signature> is added to signed elements <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness <Signature Id=“Dr Smith”> … <DigestValue>3a21fe8… … </Signature> </Diagnosis> </Patient> <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness </Diagnosis> </Patient> Note: XML Digital Signature always outputs well formed XML documents
Enveloping Signature Signed content contained within <Signature> <Signature Id=“Dr Smith”> … <DigestValue>3a21fe8… … <Object Id=“Patient”> <Patient name=“Morrison”> <Diagnosis doctor=“…”> Madness </Diagnosis> </Patient> </Object> </Signature> <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness </Diagnosis> </Patient> Note: Need Enveloping Transform to remove <Signature> element from document when validating the signature!
Detached Signature <Signature> is a new document that references signed content as a URI <?xml version=“1.0”?> <Signature Id=“Dr Smith”> <SignedInfo> … <Reference URI=“…"> <DigestValue>3a21fe8… </Reference> </SignedInfo> … </Signature> <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness </Diagnosis> </Patient>
What’s in <Signature>? May indicate remote resource (perhaps XML, HTML, binary file, etc), the whole document, a transform applied to the document, or an Id attribute of some element <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature> For each signature (a document can contain multiple, overlapping signatures) May contain an encoded x509.v3 certificate Source: XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/
Signing Example <?xml ver…?> <Products> … </Products> • Two resources available on the Internet, addressable with URIs: • An XML document • A binary image • A detached signature will be made that references both objects products.xml logo.gif www.layer7-tech.com
Create <SignedInfo> Element <SignedInfo> <CanonicalizationMethod Algorithm="http://.../REC-xml..."/> <SignatureMethod Algorithm="http://.../xmldsig#dsa-sha1"/> </SignedInfo> <?xml ver…?> <Products> … </Products> products.xml logo.gif www.layer7-tech.com Note that some namespaces have been shortened to fit on the slide
Compute the digest of each resource to sign <SignedInfo> <CanonicalizationMethod Algorithm="http://.../REC-xml..."/> <SignatureMethod Algorithm="http://.../xmldsig#dsa-sha1"/> <Reference URI="http://www.layer7-tech.com/products.xml"> <Transforms> <Transform Algorithm="http://.../REC-xml-c14n..."/> </Transforms> <DigestMethod Algorithm="http://.../xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI="http://www.layer7-tech.com/logo.gif"> <DigestMethod Algorithm="http://.../xmldsig#sha1"/> <DigestValue>12d3fe4a</DigestValue> </Reference> </SignedInfo> <?xml ver…?> <Products> … </Products> products.xml logo.gif www.layer7-tech.com Note that the specification explicitly states that MD-5 is not recommended because recent advances in cryptography may have weakened it.
Take digest of <SignedInfo> and sign. Add <KeyInfo> <?xml version=“1.0” encoding=“UTF-8”?> <Signature Id=“ExampleSig “ xmlns="http://.../xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://.../REC-xml..."/> <SignatureMethod Algorithm="http://.../xmldsig#dsa-sha1"/> <Reference URI="http://www.layer7-tech.com/products.xml"> <Transforms> <Transform Algorithm="http://.../REC-xml-c14n..."/> </Transforms> <DigestMethod Algorithm="http://.../xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI="http://www.layer7-tech.com/logo.gif"> <DigestMethod Algorithm="http://.../xmldsig#sha1"/> <DigestValue>12d3fe4a</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> … </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> <?xml ver…?> <Products> … </Products> products.xml logo.gif www.layer7-tech.com
Transforms • Transforms are an ordered list of operations applied to the document before signing • This provides finely-grained application of signatures. Using transforms, you can isolate arbitrary content to sign, leaving the rest of the document open to change • Might include canonicalization, Base 64, Xpath filtering, XSLT transforms • Applied to octet stream residing at a reference or to the output of any previously applied transform • User-defined transforms can also be applied • Transforms also appear in XML encryption
Transforms (cont) <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> … </KeyInfo> </Signature> Original document must be canonicalized before checking signature Source: XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/
W3C XML Digital Signature • Latest spec is a W3C Recommendation dated 12 February 2002 • http://www.w3.org/TR/xmldsig-core/ • Working group’s page is at http://www.w3.org/Signature/ • JSR 105 is Java Digital Signature APIs: • http://www.jcp.org/jsr/detail/105.jsp • Careful, most packages do not yet implement this!
W3C XML Encryption • Replacement of element content with <EncryptedData> tag: <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> <EncryptedData Type=“…”> <CipherData> <CipherValue>A1B… </CipherData> </EncryptedData> </Diagnosis> </Patient> <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness </Diagnosis> </Patient> Note: XML Encryption always outputs well formed XML documents
W3C XML Encryption (cont) • Replacement of entire element with <EncryptedData> tag: • Similarly, entire documents or even arbitrary content can be encrypted • Result is always a well-formed XML document <Patient name=“Morrison”> <EncryptedData Type=“…”> <CipherData> <CipherValue>A1B32D… </CipherData> </EncryptedData> </Patient> <Patient name=“Morrison”> <Diagnosis doctor=“Smith”> Madness </Diagnosis> </Patient>
What’s in <EncryptedData>? <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> Note that this is from Digital Signature namespace. Key exchange is described in detail in this spec. Consider also relevance to XKMS discussed later Can add user-defined elements, such as timestamps If encrypted content is local to document Or, if encrypted content is to be found externally Source: XML Encryption Syntax and Processing, http://www.w3.org/TR/xmlenc-core/
W3C XML Encryption • Latest spec is XML Encryption Syntax and Processing. It’s a W3C Recommendation, dated Dec 10, 2002 • http://www.w3.org/TR/xmlenc-core/ • JSR 106 defines a standard Java API for XML encryption. • http://www.jcp.org/jsr/detail/106.jsp • Careful, most of the available Java XML encryption packages do not implement this yet.
XML Encryption Issues • Key breaking is easier if you know some of the text that was encrypted, or have repeated text strings • XML susceptible on both counts: context guesses and closing tags • Ambiguity when signatures and encrypted data are mixed. Did encryption occur before or after signing? • Resolved using processing model described in the XML Encryption Transform spec • W3C Recommendation, Dec 10, 2002 • http://www.w3c.org/TR/xmlenc-decrypt
Implementations • Apache XML Security http://xml.apache.org/security/index.html • Classes for dig sigs and canon. with encryption coming • Donated by Computer Science Institute for Data Communications Systems at the University of Siegen, Germany • IBM XML Security Suite http://www.alphaworks.ibm.com/tech/xmlsecuritysuite • Classes for dig sigs, canon. and encryption. • Very cool templating feature that simplifies implementation! • Also useful utilities: ANS.1/XML conversions for LDAP and x509.v3 certificates • Load International Components for Unicode for Java version 2.0 (not 2.1, contrary to docs!) http://www-124.ibm.com/icu4j/ • Institute for Applied Information Processing and Communications, Graz University of Technology (IAIK) XML Signature library http://jce.iaik.tugraz.at/products/04_ixsil/index.php • Classes for dig sigs and canon.