Transcript HTTP и CGI - UAZone.org

Donkey Project
Technologies and Target applications
March 6, 2003, Vrije Universiteit
Yuri Demchenko <[email protected]>
Outlines





Problems in traditional PKI and Identity Management
Donkey goals and functionality
Design issues
Timetable and Next steps
Discussion:
 Using
and extending Donkey functionality
 Possible applications
 Reference information
©February 21, 2003. Amsterdam.
Donkey Project
Slide2_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 AuthN and AuthZ
Donkey website: http://www.nlnetlabs.nl/donkey/
©February 21, 2003. Amsterdam.
Donkey Project
Slide2_3
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_4
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_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
Slide2_6
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 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_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
Slide2_8
Some specific next tasks
 Overview of existing solutions for AA and Identity management
 Analysis of applications specific requirements
OpenPGP Keyserver
 Attribute/Privilege storage
 Identity/Credentials Storage

 Trust analysis
 Threats analysis
©February 21, 2003. Amsterdam.
Donkey Project
Slide2_9
Donkey functionality for AuthN/AuthZ
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
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_12
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_13
Identity management and SSO
Two Identity standards
 Microsoft passport – deployed since 2000
 Liberty alliance – emerging, deployment 2003
©February 21, 2003. Amsterdam.
Donkey Project
Slide2_14
Microsoft Passport
 Proposed as a solution for Internet-wide Credentials
management and Authentication service
 Recently proposed Passport Manager Licensing Program

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

tools to gauge and improve the strength of their Passport password
 Next Step for the Industry: Federated Security and Identity
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
 Based on industry emerging Web Services Security

©February 21, 2003. Amsterdam.
Donkey Project
Slide2_15
Securely available credentials
 Obvious need for such a service
Mobile users/agents
 Persistent storage of valuable information
 Scope of former IETF SACRED WG
 Intersects with Identity management

 Required functionality
Use/integrate/interchange credentials from different appliances (Internet,
mobile telephone, smartcard/bankcard, etc.)
 Credentials server vs direct access to home storage of credentials
 Technology (storage and protocol) must be opaque to credentials
 Need to support different types of user authentication
 Primary and secondary credentials vs credentials delegation

©February 21, 2003. Amsterdam.
Donkey Project
Slide2_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

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
Slide2_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
Slide2_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)

CRL – Certificate Revocation List as a component of PKC management
 PKI components
Identification Service (IS)
 Registration Authority (RA)
 Certification Authority (CA)
 Certificate Repository (CR), normally built on LDAP

©February 21, 2003. Amsterdam.
Donkey Project
Slide2_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
 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_20
PKC vs AC: Certificates structure
X.509 PKC
 Version
 Serial number
 Signature
 Issuer
 Validity
 Subject
 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
Slide2_21
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







X.509 PKC Fields
 Private Extensions




Authority Information Access
Subject Information Access


 Custom Extensions


©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
Slide2_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
 May be traceable via AC issuer





AC Targeting
Authority Key Identifier
Authority Information Access
CRL Distribution Points
Slide2_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
Slide2_24
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

 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
Slide2_25