Upload
carmel-skinner
View
217
Download
3
Embed Size (px)
Citation preview
©February 21, 2003. Amsterdam. Donkey Project Slide2_2
Outlines
Problems in traditional PKI and Identity Management Donkey goals Donkey Functionality Design issues Timetable Next steps Discussion:
Where the Donkey can be of use for RIPE NCC
©February 21, 2003. Amsterdam. Donkey Project Slide2_3
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
P2P 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 Slide2_4
Donkey and DNSSEC
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 Slide2_5
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 AuthN and AuthZ
Donkey website: http://www.nlnetlabs.nl/donkey/
©February 21, 2003. Amsterdam. Donkey Project Slide2_6
What is Donkey: Donkey functionality
Donkey allows anyone to publish a named key, together with optional data (Donkey package)
Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match
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
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 Slide2_7
Design issues: Package structure
(Proprietary) Internal format (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 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 Slide2_8
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 Slide2_9
Existing OpenSource solutions for AA and PMI
Donkey will be built upon existing PKI and AA applications:
• PGP Key Server
• Internet2 PubCookie/WebISO and Shibboleth/AA
• PAPI (AuthZ and Web SSO)
• A-Select (AuthZ and Web SSO)
• PERMIS (PrivilEge and Role Management Infrastructure Standards Validation Project)
• Akenti (cross-domain AA for Grid applications)
©February 21, 2003. Amsterdam. Donkey Project Slide2_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 Slide2_11
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)
©February 21, 2003. Amsterdam. Donkey Project Slide2_12
X.509 PKC Fields and Extensions – check with 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
©February 21, 2003. Amsterdam. Donkey Project Slide2_13
X.509 PKC Extensions format
Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage:
Digital Signature Key CertSign Crl Sign
©February 21, 2003. Amsterdam. Donkey Project Slide2_14
AC vs PKC: 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
©February 21, 2003. Amsterdam. Donkey Project Slide2_15
AC Attribute Types and AC Extensions
AC Attribute Types Service Authentication Informaion 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
©February 21, 2003. Amsterdam. Donkey Project Slide2_16
Donkey Project milestones
Overview and inventory/planning - current stage Selected basic technologies and development environment Overview document
March-April: Prospective applications area overview Requirements (common and specific for applications) Draft Package and Protocol description/definition
April-May: API(s) definition and Donkey prototyping API requirements
June-August: Development and pilot implementation for 1-2 applications
©February 21, 2003. Amsterdam. Donkey Project Slide2_17
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 Slide2_18
Some specific next tasks
Overview of existing solutions for AA and Identity management Analysis of applications specific requirements Scalability analysis Trust analysis Threats analysis