XML Web Services Security

1
XML Web Services Security

• March 27, 2003
• IIDS Group, Vrije Universiteit
• Yuri Demchenko, NLnet Labs
• ltdemch_at_NLnetLabs.nlgt

2
Outlines

• Historical
• XML Security
• Web Services Security
• OGSA Security
• XML Web Services technology for IIDS - Discussion

3
Historical How all this started (quoting Tim
Berners-Lee)

• Initial idea to create resource description
  language
• Existing technologies SGML WAIS, Gopher
  Library Catalogues
• Problems hyperlinks reference and semantic
  meaning binding
• Past steps
• WWW and HTML
• RDF and Metadata
• XML and XML Signature
• Next step Semantic Web
• Ongoing development Computer Grids -gt
  Information Grids -gt Semantic Grids

4
XML Basics DTD, Schema, XML Protocol, etc.

• DTD is document-oriented
• Like HTML
• Schema is data-oriented
• XML Signature
• SAML
• Basic XML Protocol(s)
• XML-RPC
• SOAP
• XForms, XLink, XML Query, XPath, XPointer, XSL
  and XSLT, Legal XML

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

6
XML Security - Components

• XML Signature
• XML Encryption
• Security Assertion
• SAML (Security Assertion Mark-up Language)
• XrML (XML Right Mark-up Language)
• XACML (XML Access Control Mark-up Language)
• XKMS (XML Key Management Specification)

7
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
• Provides basic functionality for state assertions

8
XML Signature structure

• ltSignature ID?gt 
• ltSignedInfogt  ltCanonicalizationMethod/gt
  ltSignatureMethod/gt  (ltReference URI?
  gt  (ltTransformsgt)?  ltDigestMethodgt  ltDigestV
  aluegt  lt/Referencegt) lt/SignedInfogt
• ltSignatureValuegt (ltKeyInfogt)? (ltObject ID?gt) 
• lt/Signaturegt 

9
XML Web Services

• A Web Service is a software system identified by
  URI, whose public interfaces and bindings are
  defied and described by XML. Other software
  systems may discover and interact with the Web
  Service in a manner prescribed by its definition,
  using XML based messages conveyed by Internet
  protocols.
• Service oriented architecture for
  application-to-application interaction
• Describing Web services WSDL
• Exchanging messages SOAP extensions
• Publishing and Discovering WS descriptions - UDDI
• Programming language-, programming model-, and
  system software-neutral
• Standard based XML/SOAP foundation
• Industry initiatives (and development platforms)
• Sun SunONE/J2EE (SunONE Studio)
• Microsoft .NET (Visual Studio .NET)
• IBM Dynamic e-Business (AlphaWorks)
• XML Spy by Altova

10
XML WS - Service Oriented Architecture

• WSDL based Service Description
• SOAP based messaging over HTTP, SMTP, TCP, etc.
• UDDI based Publishing/Discovery

11
Web services features three stacks
12
Web Service Description Language (WSDL)

• WSDL is an XML document format for describing Web
  service as a set of endpoints operating on
  messages containing either document-oriented or
  procedure-oriented (RPC) messages.
• The operations and messages are described
  abstractly and then bound to a concrete network
  protocol and message format to define an endpoint

13
WSDL Example TimeService.wsdl

• http//www.Nanonull.com/TimeService/
• http//www.Nanonull.com/TimeService/message(getUT
  CTimeSoapIn)

14
Web Services Security Model

• WS-Security model provides end-to-end security
  (as contrary to point-to-point) allowing
  intermediaries
• A Web service can require that an incoming
  message prove a set of claims (e.g., name, key,
  permission, capability, etc.).
• Set of required claims and related information is
  referred as a Policy.
• A requester can send messages with proof of the
  required claims by associating security tokens
  with the messages.
• Messages both demand a specific action and prove
  that their sender has the claim to demand the
  action.
• When a requester does not have the required
  claims, the requester or someone on its behalf
  can try to obtain the necessary claims by
  contacting other Web services.
• Security token services broker trust between
  different trust domains by issuing security
  tokens.

15
Web Services Security Model

• Security token types
• Username/password
• X.509 PKC
• SAML
• XrML
• XCBF

16
WS Security Scenarios

• All are built on SOAP based security tokens
  exchange
• Direct Trust using username/password (using
  SSL/TLS)
• Direct Trust using security token
• Security token acquisition
• Issued security token
• Enforcing business policy
• Web clients
• Mobile clients (gateway services)
• Enabling Federations
• Using trust chaining, security token exchange,
  credentials exchange
• Supporting delegation
• Access control
• Auditing

17
Web Services Security Architecture

• WS-Security describes how to attach signature
  and encryption headers to SOAP messages. In
  addition, it describes how to attach security
  tokens, including binary security tokens such as
  X.509 certificates, SAML, Kerberos tickets and
  others, to messages.
• Core Specification - Web Services Security SOAP
  Message Security
• http//www.oasis-open.org/committees/download.php/
  1043/WSS-SOAPMessageSecurity-11-0303.pdf

18
Web Service Security others specifications

• WS-Policy will describe the capabilities and
  constraints of the security (and other business)
  policies on intermediaries and endpoints (e.g.
  required security tokens, supported encryption
  algorithms, privacy rules)
• WS-Trust will describe a framework for trust
  models that enables Web services to securely
  interoperate
• WS-Privacy will describe a model for how Web
  services and requesters state privacy preferences
  and organizational privacy practice statements
• WS-SecureConversation will describe how to
  manage and authenticate message exchanges between
  parties including security context exchange and
  establishing and deriving session keys
• WS-Federation will describe how to manage and
  broker the trust relationships in a heterogeneous
  federated environment including support for
  federated identities
• WS-Authorization will describe how to manage
  authorization data and authorization policies

19
WS Security SOAP Message Security

• SOAP Message Security must support a wide variety
  of security models.
• Key driving requirements for the specification
• Multiple security tokens for authentication or
  authorization
• Multiple trust domains
• Multiple encryption technologies
• End-to-end message-level security and not just
  transport-level security
• Primary security concerns
• Protection against interception confidentiality
• XML Encryption
• Protection against illegal modification
  integrity
• XML Signature
• Security consideration Auditing
• Timestamping and message expiration
• Sequence number and Messages correlation

20
SOAP Message Security Model

• Describe abstract message security model in terms
  of security tokens combined with digital
  signatures as proof of possession of the security
  token (key).
• Security token asserts claims and signatures
  provide mechanism for proving the senders
  knowledge of key
• A claim can be either endorsed or unendorsed by a
  trusted authority
• An X.509 Cert, claiming the binding between ones
  identity and public key, is an example of a
  endorsed/signed security token
• An unendorsed claim can be trusted if there is
  trust relations between the sender and the
  receiver (usually based on historical
  relations/communications context)
• Proof-of-Possession (e.g. username/password)
  special type of unendorsed claim

21
WS-Security SOAP message structure

• URI http//schemas.xmlsoap.org/ws/2002/04/secext
• Namespaces used in WSSL
• SOAP S http//www.w3.org/2001/12/soap-envelo
  pe
• XML Digital Sign ds http//www.w3.org/2000/0
  9/xmldsig
• XML Encryption xenc http//www.w3.org/2001/04/xmle
  nc
• XML/SOAP Routing m http//schemas.xmlsoap.org
  /rp
• WSSL wsse
• http//schemas.xmlsoap.org/ws/2002/04/secext

• Security element
• Header block targets specific receiver SOAP Actor
• Multiple header blocks are allowed targeted at
  different Actors
• New header block are added/appended to existing
  ones

22
SecurityTokenReference Model

• Usage and processing models for the
  ltwsseSecurityTokenReferencegt element.
• Local Reference A security token, that is
  included in the message in the ltwsseSecuritygt
  header, is associated with an XML Signature.
• Remote Reference A security token, that is not
  included in the message but may be available at a
  specific URI, is associated with an XML
  Signature.
• Key Identifier A security token, which is
  associated with an XML Signature and identified
  using a known value that is the result of a
  well-known function of the security token
  (defined by the token format or profile).
• Key Name A security token is associated with an
  XML Signature and identified using a known value
  that represents a "name" assertion within the
  security token (defined by the token format or
  profile).
• Format- Specific References A security token is
  associated with an XML Signature and identified
  using a mechanism specific to the token
• Non-Signature References A message may contain
  XML that does not represent an XML signature, but
  may reference a security token (which may or may
  not be included in the message).

23
Computer Grids

• Originated from Distributing Supercomputing
• To become pluggable computing resource
• Computer Grids -gt Information Grids -gt Semantic
  Grids
• Current de-facto standard Globus Toolkits
• Open Grid Services Architecture was boosted by
  developing XML Web Services 2002
• Commercial Grids are starting

24
Open Grid Services Architecture (OGSA)

• WSDL extensions to describe specifics of Grid
  Services
• Defines new portType - GridService
• Provides mechanism to create Virtual Organisation
• Provides mechanism to create transient services -
  Factories
• Provides soft-state registration of GSH -
  Registry
• Grid services can maintain internal state for the
  lifetime of the service. The existence of state
  distinguishes one instance of a service from
  another that provides the same interface.
• OGSA services can be created and destroyed
  dynamically
• Grid Service is assigned globally (persistent)
  unique name, the Grid service handle (GSH)
• Grid services may be upgraded during their
  lifetime and referenced by Grid (dynamic) service
  reference (GSR)

25
Security Issues in Grid computing - Specifics

• General issues
• Traditional systems are user/client/host centric
• Grid computing is data centric
• Traditional systems
• Protect system from its users
• Protect data of one user from compromise
• In Grid systems
• Protect applications and data from system where
  computation execute
• Stronger/mutual authentication needed (for users
  and code)
• Ensure that resources and data not provided by a
  attacker
• Protect local execution from remote systems
• Different admin domains/Security policies

26
Security Issues in Grid computing - Components

• Authentication
• Password based
• Kerberos based (authentication and key
  distribution protocol)
• SSL authentication
• PKI/Cert based
• Authorisation
• Integrity and confidentiality
• Cryptography
• Assurance
• Accounting
• Audit

27
Authentication

• Traditional systems
• Authenticate user/client to protect system
• Grid systems
• Mutual authentication required
• Ensure that resources and data not provided by a
  attacker
• Delegation of Identity
• Process that grants one principal the authority
  to act as another individual
• Assume anothers identity to perform certain
  functions
• E.g., in Globus use gridmap file on a particular
  resource to map authenticated user user onto
  anothers account, with corresponding privileges
• Data origin authentication

28
Authorisation

• Traditional systems
• Determine whether a particular operation is
  allowed based on authenticated identity of
  requester and local information
• Grid systems
• Determine whether access to resource/operation is
  allowed
• Access control list associated with resources,
  principal or authorised programs
• Distributed Authorisation
• Distributed maintenance of authorisation
  information
• One approach Embed attributes in certificates
• Restricted proxy authorisation certificate that
  grants authority to perform operation on behalf
  of grantor
• Alternative separate authorisation server

29
Assurance, Accounting, Audit

• Assurance
• When service is requested, to assure that
  candidate service provider meets requirements
• Accounting
• Means of tracking, limiting or changing for
  consumption of resources
• Audit
• Record operations performed by systems and
  associate actions with principals
• Find out what went wrong typical role of
  Intrusion Detection Systems

30
OGSA Security

• Built upon WS Security

31
OGSA Security Roadmap - Specifications (1)

• Naming
• OGSA Identity Specification
• OGSA Target/Action Naming Specification
• OGSA Attribute and Group Naming Specification
• Transient Service Identity Acquisition
  Specification
• Translating between Security Realms
• Identity Mapping Service Specification
• Generic Name Mapping Specification
• Policy Mapping Service Specification
• Credential Mapping Service Specification
• Authentication Mechanism Agnostic
• Certificate Validation Service Specification
• OGSA-Kerberos Services Specifications
• Pluggable Session Security
• GSSAPI-SecureConversation Specification

32
OGSA Security Roadmap - Specifications (2)

• Pluggable Authorization Service
• OGSA-Authorization Service Specification
• Authorization Policy Management
• Coarse-grained Authorization Policy Management
  Specification
• Fine-grained Authorization Policy Management
  Specifications
• Trust Policy Management
• OGSA Trust Service Specification
• Privacy Policy Management
• Privacy Policy Framework Specification
• VO Policy Management
• VO Policy Service Specification
• Delegation
• Identity Assertion Profile Specification
• Capability Assertion Profile Specification

33
OGSA Security Roadmap - Specifications (3)

• Firewall "Friendly"
• OGSA Firewall Interoperability Specification
• Security Policy Expression and Exchange
• Grid Service Reference and Service Data Security
  Policy Decoration Specification
• Secure Service Operation
• Secure Services Policy and Processing
  Specification
• Service Data Access Control Specification
• Audit and Secure Logging
• OGSA Audit Service Specification
• OGSA Audit Policy Management Specification

34
Trust establishment process (1)

• 1. Binding an entity identity to a Distinguished
  Name (DN - the subject name in an X.509
  identity certificate)
• Trust in this step is accomplished through the
  (published and audited) policy based identity
  verification procedures of the Certification
  Authority that issues the identity certificates
• 2. Binding a public key to the DN (generating an
  X.509 certificate)
• Trust in this step is accomplished through the
  (published and audited) policy based operational
  procedures of the issuing Certification Authority
  (CA).
• 3. Assurance that the public key that is
  presented actually represents the user
• Trust in this step comes from the cryptography
  and protocols of Public Key Infrastructure.
• 4. Assurance that a message tied to the entity DN
  could only have originated with that entity
• Trust that a message signed by a private key
  could only have been signed by the private key
  corresponding to the public key (and therefore
  the named entity via X.509 certs) comes from
  public key cryptography
• Trust in this step is also through user key
  management (the mechanism by which the user
  limits the use of its identity), which is assured
  by user education, care in dealing with ones
  cyber environment, and shared understanding as to
  the significance of the private key.

35
Trust establishment process (2)

• 5. Mutual authentication, whereby two ends of a
  communication channel agree on each others
  identity
• Trust in this step is through the cryptographic
  techniques and protocols of the Transport Level
  Security (TLS) standard.
• 6. Delegation of identity to remote Grid systems
• Trust in this step is through the cryptographic
  techniques and protocols for generating,
  managing, and using proxy certificates that are
  directly derived from the CA issued identity
  certificates.

36
Remote Authentication, Delegation, and Secure
Communication in GRID

• Remote authentication is accomplished by
  techniques that verify a cryptographic identity
  in a way that establishes trust in an unbroken
  chain from the relying party back to a named
  human, system, or service identity. This is
  accomplished in a sequence of trusted steps, each
  one of which is essential in order to get from
  accepting a remote user on a Grid resource back
  to a named entity.
• Delegation involves generating and sending a
  proxy certificate and its private key to a remote
  Grid system so that remote system may act on
  behalf of the user. This is the essence of the
  single sing-on provided by the Grid A user /
  entity proves its identity once, and then
  delegates its authority to remote systems for
  subsequent processing steps.
• A secure communication channel is derived from
  the Public Key Infrastructure process and the
  IETF Transport Level Security protocol.

37
Globus Grid Security Infrastructure (GSI)

• Operational solution providing security
  infrastructure for Globus Toolkits
• Targeted problems
• Thousands of users thousands of Certs many of
  CAs (with different policies)
• Grid-wide user group and roles are needed
• No grid-wide logging or auditing
• Need for anonymous users
• Intended to evolve into OGSA Security
• GSI Components
• Proxy Certificate Profile
• Provides proxy credentials to allow for single
  sign-on and to provide delegated credentials for
  use by agent and servers
• Online Credential Retrieval to create and manage
  proxy certificates
• Impersonation certificate and restricted
  delegation certificate

38
Proxy Certificate Profile

• Impersonation used for Single-Sign-On and
  Delegation
• Unrestricted Impersonation
• Restricted Impersonation defined by policy
• Proxy with Unique Name
• Allows using in conjunction with Attribute Cert
• Used when proxy identity is referenced to 3rd
  party, or interact with VO policy
• Proxy Certificate (PC) properties
• It is signed by either an X.509 End Entity
  Certificate (EEC), or by another PC. This EEC or
  PC is referred to as the Proxy Issuer (PI).
• It can sign only another PC. It cannot sign an
  EEC.
• It has its own public and private key pair,
  distinct from any other EEC or PC.
• It has an identity derived from the identity of
  the EEC that signed the PC.
• Although its identity is derived from the EEC's
  identity, it is also unique.
• It contains a new X.509 extension to identify it
  as a PC and to place policies on the use of the
  PC. This new extension, along with other X.509
  fields and extensions, are used to enable proper
  path validation and use of the PC.

39
Reference PKC vs AC Purposes

• X.509 PKC binds an identity and a public key
• AC is a component of X.509 Role-based PMI
• AC contains no public key
• AC may contain attributes that specify group
  membership, role, security clearance, or other
  authorisation information associated with the AC
  holder
• Analogy PKC is like passport, and AC is like
  entry visa
• PKC is used for Authentication and AC is used for
  Authorisation
• AC may be included into Authentication message
• PKC relies on Certification Authority and AC
  requires Attribute Authority (AA)

40
PKC vs AC Certificates structure

• X.509 PKC
• Version
• Serial number
• Signature
• Issuer
• Validity
• Subject
• Subject Public key info
• Issuer unique identifier
• Extensions

• AC
• Version
• Holder
• Issuer
• Signature
• Serial number
• Validity
• Attributes
• Issuer unique ID
• Extensions

41
X.509 PKC Fields and Extensions RFC 3280

• X.509 PKC Fields
• Serial Number
• Subject
• Subject Public Key
• Issuer Unique ID
• Subject Unique ID

• X.509 PKC Extensions
• Standard Extensions
• Authority Key Identifier
• Subject Key Identifier
• Key Usage
• Extended Key Usage
• CRL Distribution List
• Private Key Usage Period
• Certificate Policies
• Policy Mappings
• Subject Alternative Name
• Issuer Alternative Name
• Subject Directory Attributes
• Basic Constraints
• Name Constraints

• X.509 PKC Fields
• Private Extensions
• Authority Information Access
• Subject Information Access
• Custom Extensions

42
AC Attribute Types and AC Extensions

• AC Attribute Types
• Service Authentication Information
• Access Identity
• Charging Identity
• Group
• Role
• Clearance
• Profile of AC

• AC Extensions
• Audit Identity
• To protect privacy and provide anonymity
• May be traceable via AC issuer
• AC Targeting
• Authority Key Identifier
• Authority Information Access
• CRL Distribution Points

43
Other Technologies to look for IIDS

• SIP (Session Initiation Protocol) based
  technologies
• Instant Messaging and Presence Protocol SIP
  based

44
XML Web Services technologies for IIDS

• Discussion