Esecurity framework-camp-final

Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 1

The Australian Higher Education and

Research Sector Federation Certification Authority

(AHERTF)

PKI implementation issues and case studies

Viviani Paz (AusCERT)Rodney McDuff (UQ)

James Lever (UQ)John Zornig (UQ)

[email protected]


Content

• Introduction to PKI• AHERTF

– eSecurity Framework Project

• Objectives

• HE and research Federation

• Future Steps

• Trust Fabric & Trust Model

• Identification Process

• Certificate Path Construction

• Certificate Path Validation

• PKI Testing Environment

• PKI for Grid Computing

• Monash PKI Case Study


Introduction to PKI

• Authentication• Entity identification

• Data origin identification

• Integrity

• Confidentiality

Services


Introduction to PKI

• 1976 Diffie and Hellman– encryption method that uses a two-part key

• A public key and a private key

– a public key is known to everyone and a private or secret key is known only to the recipient of the message

Public-key cryptography

Plain text Encrypt Decrypt

Recipient’s EncryptionPrivate Key

Encryptedtext

Plain text

Recipient’s EncryptionPublic Key


Introduction to PKI

• Public Key Infrastructure– enables users of an insecure public network to securely and

privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.

CA

IssuesCertificates


Introduction to PKI

• Digital Signature

Digital Signature VerificationSend Message

Digital Signature Creation

Originator’s Public Key

Original

Message

DigitalSignature

Plain text

Create Signature Verify Signature

Originator’s Private Key

Plain text

Signature


Introduction to PKI

• Digital or Public-Key Certificate– X.509

Bob Info: Name Department Phone Number Certificate Info: Expiration Date Serial Number Bob's Public Key:

Digital Certificate

CA

Trusted Authority

Sign Data


Introduction to PKI

• Certification Authority (CA)

• Registration Authority (RA)

• Certificate Policy (CP)

• Certification Practice Statement (CPS)

• Policy Management Authority (PMA)

Definitions


Introduction to PKI

CARA

SendCertificate SigningRequest (CSR)User information

AcceptPolicy

Request Certificate

Send Certificate

IssueCertificate

ComplyCP / CPS

PublishInformation

aboutCertificates

PMA

Basic PKIBob Info: Name Department Phone Number Certificate Info: Expiration Date Serial Number Bob's Public Key:


eSecurity Framework for Research

• Funded by $649K

• Lead Institution

• Supported by

• http://www.esecurity.edu.au

Council of Australian University Directors of Information Technology


eSecurity Framework for Research

Objectives

• Take PKI into Production– Australian Higher Education and Research Federation Certification Authority

• Reduce the Systems Cost barriers to entry for PKI– Dissemination of information

• Establish PKI/Shibboleth alignment– Common Trust Federation for Australian HE sector

• Aiding the integration of Grid technologies with PKI / Shibboleth in the Australian HE sector


Collaboration and Interoperation

• Develop the Trust Fabric between Australian Higher Education and Research Institutions– Trust Fabric between Institutions and AusCERT will

help

• Develop common policies, practices and standards

• Evolve a PK Infrastructure as a vehicle to enable this trust fabric

• Avoid retro-fitting other implementations

• Ensure interoperability with other national and international PKIs and Federations

Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 13Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg

Ma

p R

ule

sM

ap

Ru

les

Institution1

Institution2

Institution3

Institution4

Institutionn

Set of rulesCommunity agrees to abide by rules

Community with common goals

Oversee and Ensure Compliance

Federation


Federation Considerations

• PKI is based on trustworthiness asserted and enforced by a Policy Authority and expressed through the credentials issued by Certification Authorities under a federation.

• Shibboleth is based on trusting participants to abide by established community standards and rules. Contracts are required.

• Grid Services accept certificates as valid credentials if they are signed by trusted authorities.

HE and Research Context

Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 15Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg

Australian Higher Education and Research Trust Federation

• Federation Management Authority

1….n 1….n

AusCERTCA Level 1

AusCERTCA Level 2

AusCERTCA Level 3

AusCERTCA Level 4

GRID CALevel 3

VO CALevel 4

VO CALevel 3

VO CALevel 2

VO CALevel 1

InstitutionsCA Level 4




VO ShibCA Level 3

VO MyProxyCA Level 3

RA RA RARARA

AusCERTRoot CA

Policy ManagementAuthority (PMA)

OldCA

RA RA

Australian Higher Education and Research Federation CA

Transparency

• Members and

ID processes

Grid Computing Federation

Diag

ram fro

m Jo

hn

O’C

allagh

an’s P

resentatio

nB

ased o

n S

id K

arin, S

DS

C/N

PA

ServiceIdentity

ProviderProvider

MAMS


Future Steps

• Further develop the Australian HE Trust Fabric• Implement the Trust Model that supports the Trust Fabric• Aid further integration with Shibboleth and Grid Technologies• Seek Australian HE input

– Application survey results (http://www.esecurity.edu.au/esecurity-framework-project-overview.data/application_survey_summary.pdf)

– Technical Working Group Mailing list ([email protected])– Wiki – Test and evaluate available technologies for certificate management systems– Further develop Interoperability test– Input into draft CP/CPS– Revision of Certificate Profile – Questions/Comments: [email protected]– www.esecurity.edu.au

• Keep PKI uptake costs low– Share lessons learnt

• Training, disseminate information, guidelines, policies, procedures


AHERFCA Architecture


Trust Fabric & Trust Model

• Need to develop a Trust Fabric– An exercise in sociology

• Need to develop a Trust Model– An exercise in technology

Technology can not develop a Trust Fabric.

Technology is an instrument that can enable and enhance a Trust Fabric.


What is Trust?

• Trust between individuals is well known concept to us.– Social animals learn how to trust.

• But what about:– Individuals trusting an external organization.

– Organizations trusting external individuals.

– Organizations trusting other organizations.

• These cases are not so clear to us.


What is Trust?

From ITU-T Recommendation X.509/ISO/IEC 9594. The directory: public-key and attribute certificate frameworks:Generally, an entity can be said to “trust” a second entity when it (the first entity) makes the assumption that the second entity will behave exactly as the first entity expects. This trust may apply only for some specific function. The key role of trust in this framework is to describe the relationship between an authenticating entity and a authority; an entity shall be certain that it can trust the authority to create only valid and reliable certificates.


What is Trust?

From the Online Ethics Center for Engineering and Science <http://onlineethics.org>Trust is confident reliance. We may have confidence in events, people, or circumstances, or at least in our beliefs and predictions about them, but if we do not in some way rely on them, our confidence alone does not amount to trust.

Reliance is a source of risk, and risk differentiates trusting in something from merely being confident about it. When one is in full control of an outcome or otherwise immune from disappointment, trust is not necessary. It is, of course, possible to rely on other people or on circumstances simply because one lacks other options.

Basis for confidence in relying on some person may not be morally sound. Trust may be naive or otherwise ill-founded. In that case it is likely to be disappointed. Trust may also rest on a morally unsound foundation as when, for example, one party feigns trustworthiness or behaves reliably only because the other party dominates. Philosopher Annette Baier offers as a test of the moral soundness of trust relationships that they thrive rather than wither when the basis for confidence is revealed.


What is Trust?

From F. Fukuyama, Trust: The Social Virtues and the Creation of Prosperity Trust is the expectation that arises within a community of regular, honest, and cooperative behavior, based on commonly shared norms, on the part of other members of that community.

From M. Sako, Prices, Quality, and Trust: Inter-firm Relations in Britain and Japan Trust is a state of mind, an expectation held by one trading partner about another, that the other behaves or responds in a predictable and mutually expected manner.

From E. Lorenz, Trust, Contract and Economic CooperationTrust can be defined as the judgment one makes on the basis of one's past interactions with others that they will seek to act in ways that favor one's interests, rather than harm them, in circumstances that remain to be defined. Trusting judgments inevitably remain tentative, rather than certain, since they are based on a limited knowledge of others rather than a precise calculation of their interests."


What is Trust?

From WikiPedia <http://en.wikipedia.org/wiki/Trust_(sociology)>Trust in sociology is a relationship between people, or between people and social institutions such as a corporation or government. It is the belief by one person that another's motivations towards them are benevolent and "honest“ ….

The work of Barbara Misztal attempts to combine all notions of trust together. She points out that there are three basic things that trust does in the lives of people. – It makes social life predictable, – It creates a sense of community– It makes it easier for people to work together.


• Predictable behaviour– Expectations are understood and agreed

upon

– Institutions follow agreed set of rules

• Beneficial to all Australian HE community– Institutions work together towards

a common goal

• Confident reliance– Identification Process

What does Trust mean to us?


• Identify Community– Australian and New Zealand Higher Education and

Research Sector

– 53+ Institutions• Community must consist of peers

– 1,000,000+ people

Trust Fabric Check List (1)



• Develop/Identify commonality– Has to be important to us

• If it is not important to us why bother?

– Has to inspire confident predictability• The way it works for me is the same as it works for

you

• The way it works today is the same way it will work tomorrow and after tomorrow

– Has to be transparent• Has to be auditable


• Engineering Issues– Has to be simple

• Complex things break easily• Complex things don’t get implemented

– Has to be inclusive• Must cover full spectrum of possibilities within the

community– Has to have minimal impact on an institution’s

business process• Institutions don’t like being told what to do

– Has to be flexible to fit an institution’s particular “uniqueness”



• Simple– Based on Australian Law and Breeder Documents

• Identification Record for a Signatory to an Account– 100 Point Check– http://www.austrac.gov.au/guidelines/forms/201.pdf– Primary Documents

» Proof of identity

– Accrued Points

– IdM an integral part of any institution

• Minimal Impact– Only measures the strength of an institution’s identification

process. Doesn’t change it– An Institution can pick and choose what it wants to

implement

Trust Fabric Commonality based on Strength of Identification Process


• Authentication Process Agnostic• Authorization Process Agnostic• Independent of Technology• Auxiliary Processes and Practices need to complete

the whole picture– For PKI needs CP/CPS– For Shibboleth needs Federation Participation Agreement

• InCommon (http://www.incommonfederation.org/)• MAMS Federation (http://federation.org.au)

Trust Fabric Commonality based on Strength of Identification Process


Why concentrate on Identity?

AuthZProcess.Access

based on user’s

attributes

AuthNProcess.Proof of

Possession ofCredentials

IdentificationProcess.

Issuance ofCredentials.

Because that is where it all starts going wrong.


Identification Process Metric

No Identification P

rocess

Another’s Identification P

rocessW

hich you “trust”.

Your Identification Process

< 100 Points 100 Points > 100 Points

Level 1 Level 2 Level 3 Level 4

Birth Certificate=70ptPassport=70ptDrivers License=40ptKnown customer (>= 12 month) = 40ptCredit Card=25pt


Certificate Level

Description

Level 1

No proactive identity check has been provided to the RA. However identity information has been provided by a body that the RA has a trust relationship.Example: A student being enrolled in at least one subject is sufficient for the certificate issuing however identity information has only been supplied by QTAC (or similar state body).

Level 2

Subject is required to provide proof of identity by an in-person appearance to the RA. However the individual for what ever reason can not provide the required 100 points of identification.Example: A contractor, who is at an institution for a short time but needs access to a system protected by PKI, may not have enough credentials on her person to meet the 100 points check but can provide some credentials like a drivers licence and/or credit card.

Level 3

Subject is required to provide proof of identity by an in-person appearance to the RA. That proof should accrue to at least 100 points of identity.Example: A foreign staff member that has a valid passport and has a written reference from an acceptable referee.

Level 4Subject is required to provide the same information for Level 3 certification in addition to a positive check to be conducted by an appropriate external agency.

Certification Levels


• For our exercise in sociology we need:– To construct a “sense of trust” between a relying party

and an end entity. IE a Trust Fabric.

• For our exercise in (PKI) technology we need:– To construct a valid unbroken chain of CAs between a

relying party’s trust anchor and an end entity’s certificate.

• Certificate Path Processing

– Certificate Path Construction.

– Certificate Path Validation.

– A Trust Model.

• Topology of how CAs are order.

Trust Model


Relying Party’s Trust Anchor?

• Trust Anchors are self-signed certificates.– A Relying Party usually chooses its Trust Anchor.– Typically it’s the Trust Anchor of their Organization.– Or …

• Trust List.– CAs trusted by a particular application vendor.– CAs manually added to a Trust List. (But by who?)

• Sometimes it not obvious who is your Trust Anchor. – Need to click on the Padlock.


Trust Model:Policy Management Authority

Harmonize polices and practices across existing PKI inline with common purpose.

• GRID Model• CPP by publishing

cert bundle.


Trust Model:Mesh Cross-Certification

• Very flexible for institutions policies and procedure wise.

• 53x(53-1) = 2756 cross-certificates.

• CPP distressingly difficult.

...

Mesh of Cross-Certified CAs at an Institution Level

RA RA

Institution 53

CA

RA RA

Institution 52

CA

RA RA

Institution 2

CA

RA RA

Institution 1

CA(self-signed) (self-signed) (self-signed)

CommercialCA

Chain

Each institution has is own CA and RAs and acts as its own trust anchor. Cross-certificationagreements signed with other institutions.


• As with Mesh Cross-Certification.

• Only 53 cross-certificates needed. – Scales linearly.

• Each institution 2 hops away.

• CPP slightly easier.• Model used to

connect US Uni’s (HEBCA) and US Gov. Agencies (FBCA).

...

AusCERT as the Bridging CA

RA RA

Institution 53

CA

RA RA

Institution 52

CA

RA RA

Institution 2

CA

RA RA

Institution 1

CA

CommercialCA

Chain

AusCERTCA

CommercialCA

Chain

(self-signed) (self-signed) (self-signed)

Each institution has is own CA and RAs and acts as its own trust anchor. Cross-certificationagreements signed AusCERT.

Trust Model:Bridge Cross-Certification


• Only AusCERT CA issues and revokes certificate.

• Good for CPP.• Less flexible for

institutions.– Difficult to respond to

institution customizations.

• Common policies and practices across 53+ institutions.

• AusCERT needs huge infrastructure if CAUDIT PKI gets large. (1 million + clients.)

– Revocation problems.– Much duplication

with help and service desks.

...RA RA

Institution 1

RA RA

Institution 53

RA RA

Institution 52

RA RA

Institution 2

AusCERTCA

CommercialCA

Chain

AusCERT CA as the only Trust Anchor

Each institution only has RAs which initiates issuance and certificate management based on common policies and practices over entire PKI.

Trust Model:Single CA


Australian Higher Education and Research CA Federation Trust Model

AusCERT will provide:PMA, Directory of Directories, Single point Certificate Dissemination, Single point CRL and OCSP, Virtual CAs.


Certificate Path Construction

• Two CAs must have trust relationship to form link. Either– One must be subordinate to other or– Must be Cross-Certified. (Unilateral or Bilateral?)– Relationships should be forged due to common policies or

procedures or interests. Otherwise there is a dilution of trust.

• Must be able to locate and retrieve candidate CAs for chain– Don’t need end entity’s certificate. Already have it.– Some protocols can provide them. SSLv3/TLSv1,

S/MIME.– Some certificate attributes can hint at where to find them.

• Authority Information Access Extension.– Some X.500 or LDAP directories can contain them.

• Can’t construct path, can’t construct “sense of trust”.


Realistic example of CertificatePath Construction

Issuer: CA1

Subject: EE1

Issuer: CA2

Subject: CA1

Issuer: CA2

Subject: CA2

Issuer: CA2

Subject: CA3

Issuer: CA3

Subject: EE2

Issuer: CA4

Subject: CA4

Issuer: CA2

Subject: CA4

Issuer: CA4

Subject: CA2

Issuer: CA4

Subject: EE4

Issuer: CA4

Subject: CA5

Issuer: CA5

Subject: EE3

Issuer: CA3

Subject: CA5

Issuer: CA5

Subject: CA3

Issuer: CA7 (Trust Lst)

Subject: CA6

Issuer: CA6

Subject: EE5


Subject: CA7 (Trust Lst)

Issuer: CA4

Subject: CA6

Issuer: CA6

Subject: CA4

Certificate Path Construction:Mesh CA Cross-Certification


Realistic example of CertificatePath Construction

Issuer: CA1

Subject: EE1

Issuer: CA2

Subject: CA1

Issuer: CA2

Subject: CA2

Issuer: CA2

Subject: CA3

Issuer: CA3

Subject: EE2

Issuer: CA4

Subject: CA4

Issuer: CA2

Subject: CA4

Issuer: CA4

Subject: CA2

Issuer: CA4

Subject: EE4

Issuer: CA4

Subject: CA5

Issuer: CA5

Subject: EE3

Issuer: CA3

Subject: CA5

Issuer: CA5

Subject: CA3


Subject: CA6

Issuer: CA6

Subject: EE5


Subject: CA7 (Trust Lst)

Issuer: CA4

Subject: CA6

Issuer: CA6

Subject: CA4

Mesh CA Cross-Certification


Certificate Path Construction:Bridge CA Cross-Certification

From http://pkidev.internet2.edu/bridge/


Certificate Path Validation

• Once path is constructed each link of chain must be checked.– Is integrity of certificate sound? Issuer signature must be verified.– Is the certificate being used within its validity period?– Has certificate been revoked?

• Not trivial pursuit. Need external information. CRL. OCSP. • Where do I find these? Some X.509 extensions hint at

locations.– Has it been used for its intended purpose?– Is the candidate path too long?– Does one of the CA certificates prohibit the candidate path?– Does one of the CA certificates prohibit the policy of another?

• Can’t validate path, can’t construct “sense of trust”.• If path doesn’t validate sirens go off.• If path does validate (suddenly) nothing happens.

– But who does my application think is the trust anchor and how did it get there? Check the Padlock.


The Good, The Bad and The Ugly

• X.509 and RFC3280 imprecise about Certificate Path Processing.– Has lead to vendor inoperability problems.– Common applications can’t do dynamic path construction.

• Netscape/Mozilla/Firefox. – Others do it but with varying degrees of success.

• Microsoft Windows CryptoAPI (IE, Outlook)• Authority Information Attritbute

– Can get third party CPP engines. • Entrust Entelligence.

– CPP can be very intensive and untimely for relying party.• Delegated Path Construction and Validation. (DPP and DPV.)

– Certificate Authority Module. (CAM)• Freely available.• Used by HEBCA and FBCA.

– Simple Certificate Validation Protocol (SVCP).• Coming soon to a RFC near you.

– W3C XML Key Management Specification (XKMS). • Total refactoring of PKI way from ASN.1


AHERFCATesting Environment


eSecurity Framework Project

• eSecurity Framework Project follows on from the CAUDIT PKI and has the goal to develop a production PKI– Initial architecture was developed and a proof of concept CA was

designed and built. – Fully hierarchical CA test environment, now version 0.2 test

environment– Developed Draft CP/CPS

• www.esecurity.edu.au• Requested Feedback from

– Technical Activities Group (pkitag)– HEBCA, FBCA and others

– Issued CA Certificates• Victoria University• Monash University• The University of Queensland

– Participant Universities Issued End User Certificates


eSecurity Framework Project

• Preliminary Interoperability tests– Email interoperability tests including

Mozilla/Thunderbird, Outlook and Mail.app• Email encryption, signing, signing+encryption

• Certificate revocation validation

• CRL and OCSP validation

– Client Authentication testing between Apache httpd (Web Server) and Mozilla/Firefox, Internet Explorer

• CRL and OCSP validation


OpenCA Test Environment

• OpenCA used for the initial test environment– 4 CAs on one test infrastructure– 4 RAs on another test infrastructure– RootCA on own host– Both CA hosts are kept entirely off the network

• Difficulties encountered getting them to all work together on the one host system – testing purposes

• Built a management system tool– Documented


OpenSSL is your friend

• OpenSSL, every PKI/crypto engineer’s Swiss army knife.

• Basic OpenSSL commands worth knowing for any PKI Practitioner – x509, req and the PKCS formats and protocols

• Fundamental requirement to debugging problems with your PKI Certificates


OpenSSL Commands

Standard commands

asn1parse ca ciphers crl crl2pkcs7

dgst dh dhparam dsa dsaparam

enc engine errstr gendh gendsa

genrsa nseq ocsp passwd pkcs12

pkcs7 pkcs8 prime rand req

rsa rsautil s_client s_server s_time

sess_id smime speed spkac verify

version x509


PKCS* - What/when/where/why?

• Public-Key Cryptography Standards were developed and published by RSA Laboratories.

• Of specific practical interest are:– PKCS8 (pkcs8) – Key Store

– PKCS10 (req) – The Certificate Signing Request

– PKCS11 (engine) – Communication w/crypto devices

– PKCS12 (pkcs12)– key store and full certificate chain


Certificate Signing Request

NAME

req - PKCS#10 certificate request and certificate generating utility.

SYNOPSIS

openssl req [-inform PEM|DER] [-outform PEM|DER] [-in filename]

[-passin arg] [-out filename] [-passout arg] [-text] [-pubkey] [-noout]

[-verify] [-modulus] [-new] [-rand file(s)] [-newkey rsa:bits] [-newkey

dsa:file] [-nodes] [-key filename] [-keyform PEM|DER] [-keyout file-

name] [-[md5|sha1|md2|mdc2]] [-config filename] [-subj arg] [-x509]

[-days n] [-set_serial n] [-asn1-kludge] [-newhdr] [-extensions sec-

tion] [-reqexts section] [-utf8] [-nameopt] [-batch] [-verbose]

[-engine id]

DESCRIPTION

The req command primarily creates and processes certificate requests in

PKCS#10 format. It can additionally create self signed certificates for

use as root CAs for example.


CSR 2…

• OK, so that’s a manpage, but how do I do anything?openssl req -new

• By default, this will expect you to then enter a number of attributes for the CSR, namely:% openssl req -newGenerating a 1024 bit RSA private key...................++++++..........++++++writing new private key to 'privkey.pem'Enter PEM pass phrase:Verifying - Enter PEM pass phrase:-----You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----


CSR 3…

Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, YOUR name) []:Email Address []:

Please enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:An optional company name []:-----BEGIN CERTIFICATE REQUEST-----MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5r4pU/y6f+WkLhZwPx2dtLYVYBNnsuiSma9Fj5B3L+VU4ueaSCSdypiFDA9hrlctJKOlRT4HxigcI2gnbif2KicFDoX9SxXfcaAwSQ2zB74T2g6Z5sH44XRsu+o+KADrNlIas0ugF8Ute6kU5iLzO+weeR5hXeEe7mTznPv23gQIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAGVhKddSY2htMkgSliEFJmwHBUpPHWJnknRao9WYrkq0o05LhtT5KAUTYQ5VA+rjbtsNjWYM6tcyVcvHz/EfqHqaoWMFCErut5FC2WNrH08T7NfCSMBk30kvXnVSJPoO5fY5ieXHJY4PkjgEBOnCgGgkfRd6YSH8D/ndemFYQG8o=-----END CERTIFICATE REQUEST-----


OpenSSL Configuration Files

[ req ]

prompt = no

email_in_dn = no

req_extensions = req_extensions

attributes = req_attributes

encrypt_key = no

default_keyfile = myhost_wooloomooloo_edu_au.pem.key

input_password = test passphrase

output_password = test passphrase

default_bits = 2048

default_md = sha1

distinguished_name = req_DN

[ req_DN ]

countryName = AU

organizationName = The University of Wooloomooloo

organizationalUnitName = Information Technology Services

commonName = myhost.wooloomooloo.edu.au

#emailAddress = [email protected]


OpenSSL Conf Files cont…

[ req_extensions ]

subjectAltName=@alt_section

[ alt_section ]

[email protected]

IP.2=10.0.0.1

DNS.3=myhost2.woolloomooloo.edu.au

[ req_attributes ]

challengePassword = A challenge password

challengePassword_min = 4

challengePassword_max = 20


New Certificate Request

• Generating the Certificate Signing Request with the new configuration file% openssl req -new -config openssl_test_req.cnf -out

myhost_woolloomooloo_edu_au.pem.csr

Generating a 2048 bit RSA private key

.+++

.................+++

writing new private key to 'myhost_woolloomooloo_edu_au.pem.key’


Self-Signed Certificate

• CA Extensions to use for the Self-Signed CA [ v3_ca ] basicConstraints = CA:truesubjectKeyIdentifier=hashauthorityKeyIdentifier=keyid:always,issuer:alwayskeyUsage = cRLSign, keyCertSignsubjectAltName=email:copyissuerAltName=issuer:copy

• Actually Signing the Certificate with its private key% openssl x509 -req \-in myhost_woolloomooloo_edu_au.pem.csr \-extfile openssl_test_v3_ca.cnf \-extensions v3_ca \-signkey myhost_woolloomooloo_edu_au.pem.key \-out myhost_woolloomooloo_edu_au.pem.crtSignature oksubject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology

Services/CN=myhost.instutition.edu.auGetting Private key


Inside the Certificate% openssl -x50 -text -noout -in myhost_wooloomooloo_edu_au.pem.crt

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

d0:64:a8:0b:96:bb:f1:34

Signature Algorithm: md5WithRSAEncryption

Issuer: C=AU, O=The University of Wooloomooloo, OU=Information Technology Services, CN=myhost.wooloomooloo.edu.au

Validity

Not Before: Aug 22 00:51:55 2006 GMT

Not After : Sep 21 00:51:55 2006 GMT

Subject: C=AU, O=The University of Wooloomooloo, OU=Information Technology Services, CN=myhost.wooloomooloo.edu.au

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (2048 bit)

Modulus (2048 bit):

[snip]


Certificate (2) Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Subject Key Identifier: A8:DB:74:0A:CA:BC:62:C8:AA:B4:1A:ED:28:D8:58:EC:19:88:B1:1E X509v3 Authority Key Identifier:

keyid:A8:DB:74:0A:CA:BC:62:C8:AA:B4:1A:ED:28:D8:58:EC:19:88:B1:1E DirName:/C=AU/O=The University of

Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

serial:D0:64:A8:0B:96:BB:F1:34

X509v3 Key Usage: Certificate Sign, CRL Sign X509v3 Subject Alternative Name: <EMPTY> X509v3 Issuer Alternative Name: <EMPTY>Signature Algorithm: md5WithRSAEncryption[snip]


OpenSSL s_server

% openssl s_server -cert myhost_woolloomooloo_edu_au.pem.crt -key myhost_woolloomooloo_edu_au.pem.key -HTTP -ssl3 -port 12345 -CAfile myhost_woolloomooloo_edu_au.pem.crt -Verify 2

verify depth is 2, must return a certificate

Using default temp DH parameters

ACCEPT

depth=0 /C=AU/O=The University of Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

verify return:1

FILE:foo

ACCEPT


OpenSSL s_client

% openssl s_client -cert myhost_woolloomooloo_edu_au.pem.crt -key myhost_woolloomooloo_edu_au.pem.key -ssl3 -connect localhost:12345

CONNECTED(00000003)


verify error:num=18:self signed certificate

verify return:1


verify error:num=26:unsupported certificate purpose

verify return:1


verify return:1

---

Certificate chain

0 s:/C=AU/O=The University of Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

i:/C=AU/O=The University of Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

---


OpenSSL s_client (2)

Server certificate-----BEGIN CERTIFICATE----- [SNIP] -----END CERTIFICATE-----subject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology

Services/CN=myhost.instutition.edu.auissuer=/C=AU/O=The University of Wooloomooloo/OU=Information Technology

Services/CN=myhost.instutition.edu.au---Acceptable client certificate CA names/C=AU/O=The University of Wooloomooloo/OU=Information Technology

Services/CN=myhost.instutition.edu.au---SSL handshake has read 1917 bytes and written 1719 bytes---



New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHAServer public key is 2048 bitSSL-Session: Protocol : SSLv3 Cipher : DHE-RSA-AES256-SHA Session-ID:

9F90164E6549A8C5215A6FAF05D2C6F180D2D98EB7CDB7F7B7B068FB130F79B0 Session-ID-ctx:

Master-Key: 957101F3793629A588C60EE0D81336A6F214A890C4BEB4C9701207626002C6870EF142D3C9FD28F6BF26B6BABF90D461

Key-Arg : None Start Time: 1156209705 Timeout : 7200 (sec) Verify return code: 26 (unsupported certificate purpose)---GET /foo HTTP/1.0foobarbazread:errno=0


OpenSSL s_client (4)-----END CERTIFICATE-----

subject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

issuer=/C=AU/O=The University of Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au

---

No client certificate CA names sent

---

SSL handshake has read 1767 bytes and written 250 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 2048 bit

SSL-Session:

Protocol : SSLv3

Cipher : DHE-RSA-AES256-SHA

Session-ID: 6FA491AAF9D430D9E6799111449245918DD2184055605DC79ED2A58D93F8C651 Session-ID-ctx:

Master-Key: A07730E9FF160ED511E9D32D01D112F07C808557CF9BBB0DA4B446E07E2FE3FEF17E48A82D10767A58324BDE12EFB737



Key-Arg : None

Start Time: 1156208569

Timeout : 7200 (sec)

Verify return code: 26 (unsupported certificate purpose)

---GET /foo HTTP/1.0

foo

bar

baz

read:errno=0


OpenCA Internals

• OpenCA – Wrapper around OpenSSL

– Perl script

– Meta configuration structure• Useful when creating VO CAs

– Modules• CA, RA, LDAP, Public User, SCEP (Cisco), OCSP

– HSM integration% openssl engine


OpenCA Internals

• OpenSSL Extension files and customising your own certificate profile${openca_root}/openca/etc/openssl/extfiles

• Certificate profile requirements and issues importing remotely generated CSRs

Certificate Profiles


CMS Capability Study

• Certificate Management Systems Capability Study– Which products member institutions will use?

– What requirements the institutions have?

– Key elements that will determine decisions

• Requirements Matrix– Active Directory Integration

– Bulk Certificate Generation

– Cross platform support (Linux, Windows, Apple)

• CMS Products on the RADAR– OpenCA, AIAK, enTrust, Microsoft, Red Hat, RSA


Client Interoperability Study

• Client Application Interoperability Study

• Email clients– Which features are supported between clients?

– Will full CPP and Online Verification work?

• X509 Extensions Support– AIA attribute handling

– CRL attribute support

– Which extensions should we actually have in our base certificate profiles


Future work being performed…

• Further work with Certificate Management Systems and client applications

• Smart card and crypto tokens interoperability

• Hardware Security Modules (HSM) testing and integration with various CMS

• Fine tune Certificate Profile

• More interoperability studies for different clients and applications


Challenges

• Large Project and small core team• Requirements analysis takes time, and requires

many hands to perform the testing• Only the end users and administrators know the

critical requirements within their institution• Community input

– Community service

• Get involved!– Feedback and requests to [email protected]– Discussion list at [email protected]


PKI for Grid Computing


Thank You!

[email protected]