14 May 2002© 2000-02 TrueTrust Ltd1 Privilege Management in X.509(2000) David W Chadwick BSc PhD

14 May 2002 © 2000-02 TrueTrust Ltd 1

Privilege Management in X.509(2000)

David W Chadwick BSc PhD


X.509 Evolution

• X.509 (1988) - V1 PKCertificates and CRLs

• X.509 (1993) - V2 PKCertificates and revised V1 CRLs

• X.509 (1997) - V3 PKCertificates, V2 CRLs and V1 Attribute Certificates

• X.509 (2000] - V3 PKCertificates and V2 CRLs with additional extensions, plus V2 Attribute Certificates and PMI


Assigning and Delegating Privileges

ResourceOwner

“I authorise this Privilege Holder to use this resource in the following ways”signed The Resource Owner

Privilege Holder

“I delegate authority to this End User to use this resource in this limited way”signed The Privilege Holder

End User(PrivilegeHolder)

Assignsprivilege

Delegates privilege


Privilege Checking

“Please purchase this product from company X” signed the End User

EndUser(PrivilegeHolder)

Privilege VerifierQ. “Is this user authorised to purchase these goods?”

Issues acommand(AssertsPrivilege)


Traditional Applications

• Authentication and Authorisation are Internal to the Application

UserName/Password Lists

AccessControl Lists

Multiple passwordsMultiple usernames

Confusion!! Multiple AdministratorsHigh cost of administrationNo overall Security Policy


Enter PKI

• Authentication is External to the Application

AccessControl Lists

One password or pinto access private key

Happy Users! Multiple AdministratorsHigh cost of administrationNo overall Security Policy

DigitalSignature

Public Key Infrastructure

ApplicationGateway


Enter PMI• Authentication and Authorisation are External to the Application

One password or pinto access private key

Happy Users!

Fewer AdministratorsLower cost of adminOverall Security Policy

DigitalSignature

Public Key Infrastructure

ApplicationApplicationGateway

Privilege ManagementInfrastructure


X.509 PMI Entities

Source of Authority

Attribute Authority

Privilege Holder

Privilege Verifier

Assigns privilege

Delegate privilege

Trusts

Asserts privilege

Asserts privilege


Traditional Implementation

• Discretionary Access Controls– Users may optionally be given access

to resources by the resource holder– The privileges are usually held in

Access Control Lists in the Resource– Either user first or privilege firstUser1 r, w, e, dUser2 r, eUser3,4 r

r User3,4r, e User2r, w, e, d User1


DAC with X.509 Attribute Certificates• The user (holder) is given an Attribute

Certificate which strongly binds his/her name to the privileges being given to him/her

• The AC is signed by the Attribute Authority (Resource Owner or his delegate)

• Similar to X.509v3 certificate, only holds a sequence of attributes rather than a public key

• An attribute certificate can be stored anywhere since it is secure and self contained


Similarities of PKIs and PMIs

• Privilege Management Infrastructure (PMI)

• Source of Authority• Attribute Authority• Attribute Certificate• Att Cert Rev List• Att Authority Rev List

• Public Key Infrastructure (PKI)

• Root CA/Trust Anchor• Certification Authority• Public Key Certificate• Cert Revocation List• Authority Rev List


X.509 attributeCertificateAttribute Attribute Type• Comprises SIGNED SEQUENCE of:– version number of this AC (v1)– the holder (see next slide)– the General Name of the AA issuing this AC, plus

optional unique id and pk certificate serial number– the identifier of the algorithm used to sign this AC– the unique serial number of this AC– the validity period of this AC– the sequence of attributes being bound to the holder– any optional extensions


Attribute Certificate Holder

• Either GeneralName of the holder, or • The holder of a private signing key,

pointed to via the corresponding public key (X.509) certificate:– the General Name of the CA issuing the

PK certificate– Certificate Serial Number


General Names

• otherName - any name of any form• rfc822Name - e-mail address as per RFC 822• dNSName - Internet domain name as per RFC 1035• x400Address - O/R address as per X.411• directoryName - directory name as per X.501 • ediPartyName - format agreed between EDI

partners, consists of name of EDI naming authority and name of edi party

• uniformResourceIdentifier - for the WWW as per RFC 1630

• iPAddress - Internet Protocol address as per RFC 791• registeredID - any OID registered as per X.660|ISO

9834-1


Version 2 Attribute Certificates

• The holder and/or the issuer can be identified by a hash value– of their public key certificate, or– if the holder or issuer is a software

object e.g. applet, of the object itself

• The relying party will directly re-calculate the hash in order to authenticate the holder and/or the issuer


Role based Privilege Management• Can simplify the management of

privileges• People are given a role, and they

inherit the privileges assigned to the role

• Many people can hold the same role e.g. member of project team A

• Implemented as Role Based

Access Controls


Assigning Privileges to Roles in X.509

• Have a Role Specification Attribute Certificate that assigns privileges to a role (the holder is a role name)

• Then assign roles to people, using the role attribute, either– Add a role to the PK certificate of the subject,

in the subjectDirectoryAttributes extension, or– Give the person a Role Assignment Certificate

(assigns a role to a AC holder)

• The role membership and role privileges can be separately administered if wanted


Extensions to Attribute Certificates

• Basic privilege management - information about the privilege being asserted

• Privilege revocation - location of revocation information

• Roles - location of role specification certificates• Source of Authority - information about the SOA• Delegation - place constraints on the delegation

of the privileges


Privilege Revocation Extensions

• CRL distribution points extension points to where ACRL(s) for this AC will be found– different ACs can be posted to different lists,

or– ACs can be posted to different lists according

to the reasons for their revocation

• No revocation extension – for short lived privilege that will not be revoked during their validity. Can only be present in privilege holder certificates, and not AA certificates


PrivilegeVerifier

Resource beingprotected (object)

Environmentalvariables

Privilegepolicy

Privilege AsserterService

Request (object method)

Privilege Control Model

Directory

Certificatesand CRLs


Bootstrapping the Privilege Verifier

• The resource (privilege verifier) must have available to it– the root of trust of the PKI (public key of root CA)– the root of trust of the PMI (public key of Source of

Authority or a valid PK certificate)– privilege policy (rules for handling privileges)– local variables e.g. time of day, account balances– access to revocation information and certificate

chains


Verifying Claimed Privilege

PrivilegeVerifier

Bill

Alice

Bob

SOA

AA

Holder

Root CA SignsAlice’sPublicKey

Bill’sPublicKey

Bob’sPublicKey

IssuesAC to

IssuesAC to

IssuesCommand to

Checks delegation of privilegesChecks all signaturesChecks privilege is sufficient


Further Standardisation Work ofSG 17 Q.9• Friends attributes in X.501, X.511• Distributed page results service in X.518• Related Entries in X.501, X.511, X.518• Alignment with IETF LDAP standards• Defect reports in entire X.500-series

Documents

14 May 2002© 2000-02 TrueTrust Ltd1 Privilege Management in X.509(2000) David W Chadwick BSc PhD