Donkey Project Technologies and Target applications March 6

Donkey Project Technologies and Target applications March 6, 2003, Vrije Universiteit Yuri Demchenko February 21, 2003. Amsterdam. Donkey Project Slide 2_

Outlines · · · Problems in traditional PKI and Identity Management Donkey goals and functionality Design issues Timetable and Next steps Discussion: u Using and extending Donkey functionality u Possible applications · Reference information ©February 21, 2003. Amsterdam. Donkey Project 2

Donkey 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 Intended development Identity management for federated cross-domain Auth. N and Auth. Z Donkey website: http: //www. nlnetlabs. nl/donkey/ ©February 21, 2003. Amsterdam. Donkey Project 3

What is Donkey: Donkey functionality · Donkey allows anyone to publish a named key, together with optional data (Donkey package) u Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match u Donkey is NOT a permanent storage: key must be republished to remain available u Donkey does NOT define a policy for key/payload usage – This is an application specific function · 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 ©February 21, 2003. Amsterdam. Donkey Project 4

Design issues: Package structure (Proprietary) Internal format (Python data object) but XML based exchange format · Package ID · Content u Header – Flags – Names u Owner Public Key – must be unique u Body – Payload • Application dependent content and format • Intended for AA and Identity management • May include specific format definition (e. g. , embedded XML Schema) · Signatures ©February 21, 2003. Amsterdam. Donkey Project 5

Design considerations Build upon existing solutions and standards · But still capable to do a low start Gradual development · Build up upon key storage/management engine XML for package extensibility and exchange · Including prospective use of the XML Protocol ©February 21, 2003. Amsterdam. Donkey Project 6

Donkey Project milestones · Overview and inventory/planning - current stage u Selected basic technologies and development environment u Overview document · March-April: Prospective applications area overview u Requirements (common and specific for applications) u Draft Protocol description/definition · April-May: API(s) definition and Donkey prototyping u API requirements · June-August: Development and pilot implementation for 1 -2 applications ©February 21, 2003. Amsterdam. Donkey Project 7

Donkey current status Just started work on Donkey prototype · · Key generation (DSA or RSA keys) Creating a new Donkey package Add and verify signature to/of an existing Donkey package Data model and XML DTD/Schema for Donkey packages Goal: Create a base for experiments with application specific payloads ©February 21, 2003. Amsterdam. Donkey Project 8

Some specific next tasks · Overview of existing solutions for AA and Identity management · Analysis of applications specific requirements Open. PGP Keyserver u Attribute/Privilege storage u Identity/Credentials Storage u · Trust analysis · Threats analysis ©February 21, 2003. Amsterdam. Donkey Project 9

Donkey functionality for Auth. N/Auth. Z Donkey will be built upon existing PKI and AA applications: • PGP Key Server • Internet 2 Pub. Cookie/Web. ISO and Shibboleth/AA • PAPI (Auth. Z and Web SSO) • A-Select (Auth. Z and Web SSO) • PERMIS (Privil. Ege and Role Management Infrastructure Standards Validation Project) • Akenti (cross-domain AA for Grid applications) ©February 21, 2003. Amsterdam. Donkey Project 10

Standards for security assertions • • • PGP X. 509 Public Key Certificate (PKC) X. 509 Attribute Certificate (AC) for Privilege Management SAML (Security Assertion Mark-up Language) Liberty Alliance Network Identity (XML and SAML based) Web Services Security (SOAP Extensions) ©February 21, 2003. Amsterdam. Donkey Project 11

Problems in PKI and Identity Management X. 509 PKI is a heavy-weight solution and usually enterprise oriented: · Requires Certificate Authority (CA) to create and trust a certificate (PKC) · Certificate creation/revocation mechanism is complex, slow and expensive · LDAP as a standard mechanism to publish X. 509 Certs is not easily extensible and (generically) not globally scaled Distributed applications and mobile users require secure remote access to electronic credentials and identity information P 2 P networks normally (based on DHT) require non-hierarchical (non-PKI) security infrastructure Advent of XML/SOAP based standards for SSO/Identity management creates technological alternative for traditional PKI and PMI ©February 21, 2003. Amsterdam. Donkey Project 12

Donkey and DNSSEC can be a source of public keys for zones/nodes but it's not intended to provide this service for other applications: · Intended for host names, not arbitrary names · Updates are slow (propagation through caches, administrative overhead) · Requires DNSSEC protocol for public key access/request (standard request for KEY and SIG RRs) Donkey can provide (shadow/alternative) key distribution infrastructure using application specific protocols to off-load DNSSEC ©February 21, 2003. Amsterdam. Donkey Project 13

Identity management and SSO Two Identity standards · Microsoft passport – deployed since 2000 · Liberty alliance – emerging, deployment 2003 ©February 21, 2003. Amsterdam. Donkey Project 14

Microsoft Passport · Proposed as a solution for Internet-wide Credentials management and Authentication service · Recently proposed Passport Manager Licensing Program u Allows access to and use of Passport Manager source code to develop, debug and support both commercial and noncommercial software for the purpose of integration · Passport Password Quality Meter u tools to gauge and improve the strength of their Passport password · Next Step for the Industry: Federated Security and Identity u Federated security is the ability for sites, services and applications to safely accept and recognize identities and authentication assertions issued by any one of a trusted set of partners u Based on industry emerging Web Services Security ©February 21, 2003. Amsterdam. Donkey Project 15

Securely available credentials · Obvious need for such a service u Mobile users/agents u Persistent storage of valuable information u Scope of former IETF SACRED WG u Intersects with Identity management · Required functionality u Use/integrate/interchange credentials from different appliances (Internet, mobile telephone, smartcard/bankcard, etc. ) u Credentials server vs direct access to home storage of credentials u Technology (storage and protocol) must be opaque to credentials u Need to support different types of user authentication u Primary and secondary credentials vs credentials delegation ©February 21, 2003. Amsterdam. Donkey Project 16

Liberty Identity and Protocol Liberty is a set of protocols that collectively provide a solution for identity federation management, cross-domain authentication, and session management. · The Liberty architecture contains three actors: Principal, identity provider, and service provider Liberty protocol provides federation of Principal’s identity between the identity provider and the service provider. · Principal is authenticated to the identity provider · Identity provider provides an authentication assertion to the Principal · Principal can present the assertion to the service provider u Principal is then also authenticated to the service provider if the service provider trusts the assertion. · An identity federation is said to exist between an identity provider and a service provider when the service provider accepts authentication assertions regarding a particular Principal from the identity provider ©February 21, 2003. Amsterdam. Donkey Project 17

Reference information · · PKI Basics X. 509 Public Key Certificate (PKC) X. 509 Attribute Certificate (AC) Role Based Access Control (RBAC) ©February 21, 2003. Amsterdam. Donkey Project 18

Reference: PKI Basics PKI - Public Key Infrastructure · Binds subject’s distinguished name or identity with his/her public key · The major component of PKI is Public Key Certificate (PKC) u CRL – Certificate Revocation List as a component of PKC management · PKI components Identification Service (IS) u Registration Authority (RA) u Certification Authority (CA) u Certificate Repository (CR), normally built on LDAP u ©February 21, 2003. Amsterdam. Donkey Project 19

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 (Privilege Management Infrastructure) AC contains no public key but it is issued to particular subject identified by DN u AC may contain attributes that specify group membership, role, security clearance, or other authorisation information associated with the AC holder u Analogy: PKC is like passport, and AC is like entry visa u · PKC is used for Authentication and AC is used for Authorisation u AC may be included into Authentication message · PKC relies on Certification Authority and AC requires Attribute Authority (AA) ©February 21, 2003. Amsterdam. Donkey Project 20

PKC vs AC: Certificates structure X. 509 PKC · Version · Serial number · Signature · Issuer · Validity · Subject Public key info · Issuer unique identifier · Extensions ©February 21, 2003. Amsterdam. AC · · · · · Donkey Project Version Holder Issuer Signature Serial number Validity Attributes Issuer unique ID Extensions 21

X. 509 PKC Fields and Extensions – RFC 3280 X. 509 PKC Fields · Serial Number · Subject Public Key · Issuer Unique ID · Subject Unique ID X. 509 PKC Extensions · Standard Extensions u u u u X. 509 PKC Fields · Private Extensions u u Authority Information Access Subject Information Access u u · Custom Extensions u u ©February 21, 2003. Amsterdam. Donkey Project 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 22

AC Attribute Types and AC Extensions AC Attribute Types · Service Authentication Information · Access Identity · Charging Identity · Group · Role · Clearance · Profile of AC ©February 21, 2003. Amsterdam. AC Extensions · Audit Identity Donkey Project To protect privacy and provide anonymity u May be traceable via AC issuer u · · AC Targeting Authority Key Identifier Authority Information Access CRL Distribution Points 23

Role Based Access Control (RBAC) RBAC – Role Based Access Control · Role describes the function · Rights define access to the resource in a specific mode under specific conditions Benefits of RBAC · · · Easy manage and control Seperate definition of role-user and role-privilege Scaleability Support of least privilege [rinciple Enheritance and aggregation of privileges and rights Possibility to delegate ©February 21, 2003. Amsterdam. Donkey Project 24

Proxy Certificate Profile · Impersonation – used for Single-Sign-On and Delegation Unrestricted Impersonation u Restricted Impersonation defined by policy u · Proxy with Unique Name Allows using in conjunction with Attribute Cert u Used when proxy identity is referenced to 3 rd party, or interact with VO policy u · Limited validity time – approx. 24 hours 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. ©February 21, 2003. Amsterdam. Donkey Project 25