A Plan to Implement a Public Key Infrastructure (PKI ...

A Plan to Implement a Public Key Infrastructure (PKI) Interoperability and Vulnerability Laboratory (U)

A. Magar Magar Security Architecture Inc. Magar Security Architecture Inc. 9955 BBeeeecchh SSttrreeeett,, SSuuiittee 331100 Ottawa, ON K1S 3J7 Contractor Report Number: DRDC-02

Contract Number: WW77771144--22--88330099

Contract Scientific Authority: S. Zeber (613) 991-1388

Defence R&D Canada - Ottawa Contract Report DRDC Ottawa CR 2003-027 March 2003

Terms of release: The scientific or technical validity of this Contract Report is entirely the responsibility of the contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada.

Terms of release: The information contained herein is proprietary to Her Majesty and is provided to the recipient on the understanding that it will be used for information and evaluation purposes only. Any commercial use including use for manufacture is prohibited. Release to third parties of this publication or information contained herein is prohibited without the prior written consent of Defence R&D Canada.
© Her Majesty the Queen as represented by the Minister of National Defence, 2003
© Sa majesté la reine, représentée par le ministre de la Défense nationale, 2003

______________________________________________________________________________________

A Plan to Implement a Public Key Infrastructure (PKI) Interoperability & Vulnerability

Laboratory

3 March 2003

Alan Magar Magar Security Architecture Inc.

Defence R&D Canada

Defence R&D Canada PKI Interoperability & Vulnerability Lab

______________________________________________________________________________________ Magar Security Architecture Inc. Page i March 3, 2003

Executive Summary The Information Operations (IO) Section of DRDC – Ottawa proposes to establish a Public Key Infrastructure Laboratory and Testbed Facility (PKI Lab) to acquire expertise in PKI technology. The PKI Lab would be used to investigate and evaluate PKI security mechanisms and the issues arising from its deployment and operation in a military environment. The initial euphoria surrounding Public Key Infrastructure (PKI) technology has subsided to the point where it is now disparaged by many in the information security community. The technology was found to be extremely complex and costly to deploy, with only a few valid applications. Another major impediment to the widespread adoption of this technology has been the interoperability problems between products from multiple vendors. The inevitable result was that initial pilot implementations floundered, while more ambitious large scale deployments struggled to survive. Given PKI’s bleak history and less than stellar reputation it is somewhat surprising that the popularity of the technology is experiencing a major recovery. Listed below are four examples that attest to this resurgence:

• The IETF-standardized authentication method (EAP/TLS) for securing 802.11 wireless communications mandates the use of digital certificates;

• The Trusted Computing Platform Alliance (TCPA) requires a PKI to take full advantage of trusted platform properties;

• The largest software company in the world (Microsoft) not only embedded the technology in their leading operating system (Windows 2000 Server) but improved the level of integration in subsequent releases (Windows XP Professional & Windows Server 2003); and

• Standards (XKMS) have been developed to enable PKI to be used to secure Web services. PKI was initially designed to solve the complex problem of scalable cryptographic key management. Without PKI this problem still exists and with the increasing dependence on untrusted communications networks (specifically the Internet) this problem is only going to get worse. PKI is here to stay whether security practitioners like it or not. It may not exist in its present form as it evolves to meet emerging technological advances but it will exist nonetheless. The Department of National Defence (DND) is currently using PKI and smart card technology throughout the department for accessing and communicating sensitive but unclassified, information over its networks. The Government of Canada is using the same technology to provide for the secure electronic delivery of federal services and programs as part of its Government On-Line initiative. In both cases it was decided early on to standardize on a single PKI product to ultimately simplify deployment and avoid interoperability issues. The eventual challenge facing these PKI implementations as they mature is how to expand their trust network to incorporate trusted trading partners and allies. In a military context, PKI interoperability could be used to facilitate NATO and NORAD commitments, multinational exercises, coalition operations and daily communications with our allies. This will involve migrating from the current homogeneous environment to a heterogeneous one replete with disparate PKI technology that will require considerable expertise to facilitate interoperability in a timely manner. Given that DND has now standardized on Windows 2000, the reality of a heterogeneous PKI environment may already be here. This report proposes, and includes the necessary plans for, the implementation of a world-class PKI Laboratory and Testbed Facility (PKI Lab). The PKI Lab would enable DRDC to further develop practical expertise in this field, to conduct research activities related to PKI and to provide expert advice to DND and other government departments. Initial research activities will focus on interoperability issues and the vulnerability of commercial PKI implementations. Although a program of work is included within this report, further research will largely be dictated by client organizations. Specifically, this plan calls for a PKI lab equipped with:

• Complete PKI implementations from seven leading vendors; one of which will be configured in a high availability/secure architecture;

• Four LDAP and three X.500 best-of-breed directory services; and


______________________________________________________________________________________ Magar Security Architecture Inc. Page ii March 3, 2003

• One validation infrastructure. The PKI Lab will initially demonstrate:

• Cross-certification between each Certification Authority; no reference implementation will be used;

• X.500 chaining, X.500 shadowing and LDAP referrals; • Real-time certificate revocation & validation (OCSP); and • Application-level interoperability (S/MIMEv3 e-mail). The PKI Lab will initially consist of twenty rack-mounted servers and ten rack-mounted workstations divided amongst ten distinct subnets and interconnected via a router and eleven hubs. The initial plan of work has been sub-divided into four distinct phases to facilitate planning and budgeting. The forecasted cost for the establishment of the DRDC PKI Lab is $347,494.76, exclusive of maintenance and taxes. The figure below shows the relative costs of the four component parts; hardware, software, professional services and contingency.

$31,590.43 (10%)

$107,666.67(31%)

$119,214.66 (34%)

$89,023.00 (25%)

HardwareSoftwareProfessional ServicesContingency

The intent of the PKI Lab is not for DRDC to conduct PKI research in isolation. A well equipped lab would enable DRDC to take an active role in relevant standards activities and to establish meaningful relationships with counterpart agencies in other departments and countries.


______________________________________________________________________________________ Magar Security Architecture Inc. Page iii March 3, 2003

Table of Contents 1.0 Introduction................................................................................................................... 1

1.1 Purpose...................................................................................................................... 1 1.2 Background ............................................................................................................... 1 1.3 Scope......................................................................................................................... 1 1.4 Objective ................................................................................................................... 2 1.5 Assumptions.............................................................................................................. 2 1.6 Disclaimer ................................................................................................................. 2 1.7Acknowledgements.................................................................................................... 2

2.0 PKI Software Products.................................................................................................. 3 2.1 Overview................................................................................................................... 3 2.2 Baltimore UniCERT ................................................................................................. 3

2.2.1 Core Components............................................................................................... 3 2.2.2 Optional Components ........................................................................................ 5 2.2.3 Architecture........................................................................................................ 6 2.2.4 Supported Standards .......................................................................................... 7 2.2.5 System Requirements......................................................................................... 7

2.3 Entrust Authority Security Manager......................................................................... 8 2.3.1 Core Components............................................................................................... 8 2.3.2 Optional Components ........................................................................................ 9 2.3.3 Architecture...................................................................................................... 10 2.3.4 Supported Standards ........................................................................................ 11 2.3.5 System Requirements....................................................................................... 11

2.4 IDX-PKI/OpenSSL................................................................................................. 12 2.4.1 Core Components............................................................................................. 12 2.4.2 Architecture...................................................................................................... 12 2.4.3 Supported Standards ........................................................................................ 13 2.4.4 System Requirements....................................................................................... 13

2.5 Microsoft Windows 2000 PKI ................................................................................ 13 2.5.1 Core Components............................................................................................. 13 2.5.2 Optional Components ...................................................................................... 14 2.5.3 Architecture...................................................................................................... 14 2.5.4 Supported Standards ........................................................................................ 15 2.5.5 System Requirements....................................................................................... 15

2.6 PGP Enterprise 8.0.................................................................................................. 16 2.6.1 Core Components............................................................................................. 16 2.6.2 Architecture...................................................................................................... 16 2.6.3 Supported Standards ........................................................................................ 17 2.6.5 System Requirements....................................................................................... 17

2.7 RSA Keon Certificate Authority............................................................................. 18 2.7.1 Core Components............................................................................................. 18 2.7.2 Optional Components ...................................................................................... 18 2.7.3 Architecture...................................................................................................... 19 2.7.4 Supported Standards ........................................................................................ 20 2.7.5 System Requirements....................................................................................... 20


______________________________________________________________________________________ Magar Security Architecture Inc. Page iv March 3, 2003

2.8 Sun One Certificate Server ..................................................................................... 21 2.8.1 Core Components............................................................................................. 21 2.8.2 Optional Components ...................................................................................... 22 2.8.3 Architecture...................................................................................................... 22 2.8.4 Supported Standards ........................................................................................ 23 2.8.5 System Requirements....................................................................................... 23

2.9 Valicert Validation Authority ................................................................................. 23 2.9.1 Core Components............................................................................................. 23 2.9.2 Optional Components ...................................................................................... 24 2.9.3 Architecture...................................................................................................... 24 2.9.4 Supported Standards ........................................................................................ 25 2.9.5 System Requirements....................................................................................... 25

3.0 Directory Software Products....................................................................................... 26 3.1 Overview................................................................................................................. 26 3.2 Critical Path Directory Server................................................................................. 26 3.3 Microsoft Active Directory................................................................................. 2627 3.4 Nexor Directory ...................................................................................................... 27 3.5 Novell eDirectory................................................................................................ 2728 3.6 OpenLDAP ............................................................................................................. 28 3.7 Siemens DirX...................................................................................................... 2829 3.8 Sun One Directory Server....................................................................................... 29

4.0 Interoperability Initiatives........................................................................................... 30 4.1 Overview................................................................................................................. 30 4.2 Communications-Electronics Security Group (CESG) .......................................... 30 4.3 DoD Bridge Certification Authority Technology Demonstration ...................... 3031

4.3.1 BCA Interoperability Test Suite ...................................................................... 31 4.4 Internet Engineering Task Force (IETF)................................................................. 31

4.4.1 IPSEC............................................................................................................... 31 4.4.2 Lightweight Directory Access Protocol (LDAP)............................................. 32 4.4.3 OpenPGP.......................................................................................................... 33 4.4.4 Public Key Infrastructure X.509 ...................................................................... 33 4.4.5 S/MIMEv3 ....................................................................................................... 34 4.4.6 Transport Layer Security (TLS)....................................................................... 34

4.5 International Telecommunications Union (ITU) .................................................... 35 4.6 National Institute of Standards and Technology PKI Program .............................. 35 4.6.1 Application Programming Interface (API) .................................................. 3536 4.6.2 Common Signed Information Format .............................................................. 36 4.6.3 Federal Bridge CA ........................................................................................... 36 4.6.4 Minimum Interoperability Specification for PKI Components ....................... 36 4.6.5 PKI Component Testing .............................................................................. 3637 4.6.6 PKI Interoperability Testbed............................................................................ 37 4.6.7 PKI Technical Working Group........................................................................ 37 4.7 OASIS ..................................................................................................................... 37 4.8 PKI Challenge..................................................................................................... 3738 4.9 Public-Key Cryptography Standards ...................................................................... 38 4.10 World Wide Web Consortium (W3C) .................................................................. 39


______________________________________________________________________________________ Magar Security Architecture Inc. Page v March 3, 2003

5.0 PKI-Enabled Applications .......................................................................................... 41 5.1 File Security ............................................................................................................ 41 5.2 Secure Document Management .............................................................................. 41 5.3 Secure E-mail.......................................................................................................... 41 5.4 Secure Single Sign-On............................................................................................ 42 5.5 Trusted Computing ................................................................................................. 42 5.6 Virtual Private Networks ........................................................................................ 42 5.7 Web Security........................................................................................................... 43 5.8 Wireless Communications ...................................................................................... 43 5.9 Workflow ................................................................................................................ 43

6.0 Interoperability Considerations................................................................................... 44 6.1 Overview................................................................................................................. 44 6.2 Component-level Interoperability........................................................................... 45

6.2.1 CA & RA ......................................................................................................... 45 6.2.2 VAs, Directory Services & Timestamp Servers .............................................. 46 6.2.3 End Entities...................................................................................................... 46 6.2.4 XKMS.............................................................................................................. 46

6.3 Application-level Interoperability........................................................................... 46 6.4 Inter-Domain Interoperability................................................................................. 47

6.4.1 Trust Relationships .......................................................................................... 47 6.4.2 Information Sharing ......................................................................................... 48 6.4.3 Policy Enforcement.......................................................................................... 49

6.5 Interoperability Lab ................................................................................................ 50 7.0 Vulnerability Considerations ...................................................................................... 51

7.1 Overview................................................................................................................. 51 7.2 Information Operations........................................................................................... 52

7.2.1 Techniques ....................................................................................................... 52 7.2.2 Tools ................................................................................................................ 53

7.3 Component Security................................................................................................ 54 7.3.1 Certification Authority..................................................................................... 55 7.3.2 Client................................................................................................................ 55 7.3.3 Directory .......................................................................................................... 56 7.3.4 Registration Authority ..................................................................................... 56

7.4 Inter-Component Security....................................................................................... 56 7.5 Key & Certificate Management .............................................................................. 56 7.6 User Registration & Administration ....................................................................... 57

8.0 PKI Lab Architecture.................................................................................................. 58 8.1 Overview................................................................................................................. 58 8.2 Administrative Subnet ............................................................................................ 59

8.2.1 Symantec Ghost ............................................................................................... 60 8.2.2 Virtual Network Computing (VNC) ................................................................ 61

8.2.3 Operating System Builds ................................................................................. 61 8.2.4 Domain Name Service (DNS) ......................................................................... 62

8.3 Baltimore Subnet .................................................................................................... 62 8.4 Entrust Subnet......................................................................................................... 64 8.5 IDX-PKI Subnet...................................................................................................... 66


______________________________________________________________________________________ Magar Security Architecture Inc. Page vi March 3, 2003

8.6 Microsoft Subnet..................................................................................................... 67 8.7 PGP Subnet ............................................................................................................. 68 8.8 RSA Subnet............................................................................................................. 69 8.9 Sun Subnet .............................................................................................................. 70 8.10 Valicert Subnet...................................................................................................... 71 8.11 Vulnerability Subnet ............................................................................................. 71

9.0 Project Plan ................................................................................................................. 74 9.1 Overview................................................................................................................. 74 9.2 Proposed Timetable & Activities........................................................................ 7574

9.2.1 Phase 1 – Acquisition, Base Configuration & Networking ......................... 7574 9.2.2 Phase 2 – PKI Configuration ....................................................................... 7675 9.2.3 Phase 3 – Cross-Certification & Validation................................................. 7978 9.2.4 Phase 4 –Test Application ........................................................................... 8180

9.3 Cost Estimate ...................................................................................................... 8482 9.3.1 Hardware...................................................................................................... 8482 9.3.2 Software ....................................................................................................... 8583 9.3.3 Professional Services ................................................................................... 8684 9.3.4 Summary ...................................................................................................... 8785

10.0 Further Research ................................................................................................... 8886 10.1 Overview........................................................................................................... 8886 10.2 Interoperability Research .................................................................................. 8886

10.2.1 Component-Level Interoperability............................................................. 8886 10.2.2 Application-Level Interoperability ............................................................ 8886 10.2.3 Inter-Domain Interoperability.................................................................... 8987

10.3 Vulnerability Research...................................................................................... 8987 10.4 Related Research............................................................................................... 8987

11.0 References............................................................................................................. 9189 Annex A – Glossary of Terms ........................................................................................ A-1 Annex B – Quoted Hardware.......................................................................................... A-4 Annex C – Baltimore Technologies Quote..................................................................... A-7 Annex C – Siemens Quote............................................................................................ A-12 Annex D – Sun One Certificate Server......................................................................... A-14 Annex E – Valicert Quote............................................................................................. A-16


______________________________________________________________________________________ Magar Security Architecture Inc. Page vii March 3, 2003

List of Figures Figure 1 - Baltimore UniCERT Architecture...................................................................... 6 Figure 2 - Entrust PKI Architecture.................................................................................. 10 Figure 3 - IDX-PKI Architecture...................................................................................... 13 Figure 4 - Microsoft Windows 2000 PKI Architecture .................................................... 15 Figure 5 - PGP Enterprise Architecture ............................................................................ 17 Figure 6 - RSA Keon Certificate Authority Architecture................................................. 20 Figure 7 - Sun One Certificate Server Architecture.......................................................... 22 Figure 8 - Valicert Validation Authority Architecture ..................................................... 24 Figure 9 - Technical Interoperability Areas...................................................................... 45 Figure 10 - DRDC PKI Lab Architecture ......................................................................... 58 Figure 11 - Administrative Subnet Architecture............................................................... 59 Figure 12 - Baltimore Subnet Architecture....................................................................... 63 Figure 13 - Entrust Subnet Architecture ........................................................................... 64 Figure 14 - IDX-PKI Subnet Architecture....................................................................... 66 Figure 15 - Microsoft Subnet Architecture....................................................................... 67 Figure 16 - PGP Subnet Architecture ............................................................................... 68 Figure 17 - RSA Subnet Architecture............................................................................... 69 Figure 18 - Sun Subnet Architecture ................................................................................ 70 Figure 19 - Valicert Subnet Architecture.......................................................................... 71 Figure 20 - Vulnerability Subnet Architecture ................................................................. 72


______________________________________________________________________________________ Magar Security Architecture Inc. 1 March 3, 2003

1.0 Introduction

1.1 Purpose The Information Operations (IO) Section proposes to establish a PKI laboratory and testbed facility to acquire expertise in PKI technology and to investigate and evaluate the PKI security mechanisms and the issues arising from its deployment and operation, particularly in a military environment. This supports the IO mission to provide the Department of National Defence (DND) and the Canadian Forces (CF) with expert technical advice and vision to enhance their operational capabilities. It is anticipated that such a facility will actually be useful to all levels of government, and possibly even to the private sector.1

1.2 Background DND and the Government of Canada (GoC), like many public and private organizations, have implemented a PKI to provide the underlying trust infrastructure within the organization. The largest impediment to the widespread implementation of PKI technology has been the lack of interoperability between products from multiple vendors. The development of standards to address interoperability issues has frequently compounded the problem by allowing too much vendor interpretation in their implementation. In addition, standards have been slow to catch up with product functionality thereby impeding interoperability. DND, as well as the GoC, have tried to minimize interoperability problems by standardizing on the Entrust suite of products. However DND has also chosen to standardize on the Microsoft Windows 2000 operating system platform, which includes integrated PKI functionality. Therefore there is no guarantee that Entrust will remain the only PKI vendor within the department. In addition, as public and private PKI implementations expand in scope, there will be increasing pressure to support interoperability without compromising security. In a military context, PKI interoperability could be used to facilitate NATO and NORAD commitments, multinational exercises, coalition operations and daily communications with our allies. This will result in heterogeneous PKI environments that will require considerable PKI interoperability expertise to facilitate in a timely manner. The Information Operations (IO) section of DRDC – Ottawa (DREO) has developed a proposal to establish a PKI laboratory to investigate and evaluate PKI security mechanisms and the issues arising from its deployment and operation, particularly in a military environment. The laboratory is intended to support the Information Protection and Assurance (IPA) activities of the IO section. A detailed plan is now required in order to set up the laboratory and initiate a program of PKI-related research activities.2

1.3 Scope This document proposes a complete project plan for a laboratory and testbed facility combining commercial-off-the-shelf (COTS) PKI and Directory Services technology. Since DND must interact with a wide range of military and non-military organizations who will be using disparate PKI and Directory products, it is necessary to gain experience through interoperability and vulnerability research. The lab will initially consist of seven leading PKI products and seven directory products. These products will be located in seven PKI subnets and interconnected, along with three additional subnets (administrative, vulnerability and validation), via a router. The laboratory will be located at the DRDC facilities in Ottawa, Ontario. This proposal addresses the following areas:

1 [LAM01] p.1 2 [ZEB02] p.1



• PKI Software Products • Directory Software Products • Interoperability Initiatives • PKI-Enabled Applications • Interoperability Considerations • Vulnerability Considerations • PKI Lab Architecture • Project Plan • Further Research

1.4 Objective The objective of this report is to support the initiation of PKI-related research activities by designing a laboratory environment where the work can be carried out. The purpose of the report is to propose a detailed project plan to realize an IO section PKI laboratory and to propose an initial program of related research activities.3

1.5 Assumptions This report assumes that the reader has a good understanding of both PKI and Directories, and at least a passing familiarity with some of the issues involved with interoperability and vulnerability testing. No effort has been made to include this information in the report. Those lacking this background are encouraged to reference the following texts and papers:

• Understanding Public-Key Infrastructure – Concepts, Standards, and Deployment Considerations [ADA99]

• PKI Interoperability Framework [PKI01-1] • CA-CA Interoperability [PKI01-2] • Ten Risks of PKI: What You’re Not Being Told about Public Key Infrastructure [ELL]

1.6 Disclaimer The development of this report was entirely a paper-based exercise. As such, we are 100% reliant on product documentation provided by the software vendors. While every effort has been made to anticipate and plan for implementation difficulties the integration of many complex software components will likely result in unforeseen challenges.

1.7Acknowledgements The author would like to thank the following individual for his expert advice during the preparation of this paper:

• Dr. Steve Zeber, Information Operations Group, DRDC

3 [ZEB02] p.1



2.0 PKI Software Products

2.1 Overview The DRDC PKI Laboratory will initially evaluate seven leading PKI products and a Validation Authority (VA). Of the seven PKI products, two are of particular interest to DND, three are market leaders, one has a large install base and one is open source. Table 1 lists the products initially selected for inclusion in the lab. In each case the products selected allow for the establishment of an in-house Certification Authority (CA). Outsourced products, such as VeriSign, complicate interoperability testing and were consequently excluded from the DRDC PKI Laboratory. In any case, this list will likely evolve according to specific DRDC projects, DND requirements and changing market conditions.

Vendor Justification Baltimore Technologies Prominent PKI vendor Entrust Prominent PKI vendor

Products used extensively throughout GoC IDX-PKI / OpenSSL Open source PKI Microsoft DND standardizing on Windows 2000 PGP Large installed base RSA Security Prominent PKI vendor Sun Prominent PKI vendor Valicert Prominent VA vendor

Table 1 – PKI Vendors

This section provides an introduction to each of these PKI software products.

2.2 Baltimore UniCERT Baltimore Technologies is a Dublin-based security vendor. UniCERT 5.0.1 is the latest release of their PKI software. Additional company and product information can be found at www.baltimore.com. 2.2.1 Core Components Baltimore UniCERT has a modular architecture that allows new components to be individually added, modified, upgraded or removed as the organization’s needs evolve. Core components include certification authority components, registration authority components and utilities.

a) Certification Authority Components

• Certification Authority (CA) – The Certification Authority generates and signs certificates and Certificate Revocation Lists (CRLs). The CA operates according to its own flexible operational policy, which is controlled by the Certification Authority Operator (CAO).4

4 [BAL02-1] p.12



• Certification Authority Operator (CAO) – The CAO module is the Security Officer of the PKI. The CAO controls all of the administration functions and grants privileges to other UniCERT modules and operators.5

• Publisher – The Publisher handles all of the publishing requirements of the CA,

including the ability to publish to a wide range of different directories and OCSP responders. It supports flexible publishing schemas, and has the ability to only publish certain types of certificates.6

b) Registration Authority Components

• Registration Authority (RA) – The RA acts as a router between RA Operators (WebRAOs), Protocol handlers and the CA. RAs divide the PKI into operational domains. Each operational domain is a separate structure linked to the CA. Intra-domain confidentiality is maintained at all times. Each RA is governed by its own operational policy, which is maintained centrally.7

• WebRAO – The WebRAOs can authorize certification and revocation requests that have

been sent by the Protocol Handlers, or via other WebRAOs. They can also handle face-to-face registrations. The WebRAOs belong to one or a number of Authorization Groups, and can only process requests associated with specific registration policies that have been assigned to their Authorization Groups by the CAOs.8

• RAeXchange – The RA eXchange functions as a gateway for remote requests from the

protocol handlers and the WebRAO. The RA eXchange can handle the following types of certificate requests:

i. Web requests from a browser

ii. E-mail requests iii. VPN requests iv. SCEP requests from Cisco routers v. CMP requests

• Protocol Handlers (PH) – The Protocol Handlers are an extensible set of request

handlers, that handle certification requests using such protocols as Web, e-mail, SCEP and PKIX CMP. The Protocol Handlers, handle the complexities of each protocol, and pass the registration (or revocation) requests into the RA for onward processing. They also return the resulting certificates.9

i. E-mail PH - The email PH retrieves certificates requests in PKCS#10 or PEM

format from a POP3 store. The email PH sends back certificates in PKCS#7 (certificate chain), X.509 (binary) or PEM format via a SMTP server.

ii. Web PH - The Web PH provides registration pages, which are dynamically built from the registration policies. Via these request pages customers may request certificates via the major browsers (Netscape and Microsoft IE) and via PKI-aware applications capable of generating PKCS#10 certificate requests (e.g., Web servers).

iii. SCEP PH - The SCEP PH receives Simple Certificate Enrolment Protocol (SCEP) requests directly by sockets and returns the certificate in the same

5 [BAL02-1] p.12 6 [BAL02-1] p.12 7 [BAL02-1] p.13 8 [BAL02-1] p.13 9 [BAL02-1] p.13



manner. SCEP is the certificate request and retrieval method used by Cisco and other VPN vendor devices and software.

iv. PKIX CMP PH - The PKIX CMP PH handles registration and revocation requests and responses in accordance with the PKIX CMP protocol. This PH is used with the Baltimore PKIX CMP Toolkit, and is typically used for custom remote registration/authorization applications.

c) Utilities - UniCERT also contains a number of utilities for handling such things as token

management, key generation, database setup, and service management.10

• Token Manager – The Token Manager module is designed to manage the various personal secure environments (PSEs) used in PKIs. The Token Manger is a stand-alone module that manages software and hardware (smartcards and HSMs) PSEs.

• Service Manager – The Service Manager is used to start and stop all of the server

components e.g., the CA, RA, RA eXchange, Publisher, ARM, CSS, Protocol Handlers.

• Database Wizard – The Database Wizard is used initially to create the Oracle tables, and to create user accounts for the UniCERT users, i.e., the CA, CAO, RA.

• Key Generator – The Key Generator utility is used to perform key generation for the

UniCERT components such as the CA, RA, Protocol Handlers etc. Once the keys have been generated, a PKCS#10 can be sent to a CAO for certification. The CAO returns a PKCS#7 which is then imported using this utility. The Key Generator supports both hardware based cryptographic devices (HSMs, tokens, smartcard) as well as software.

• Certificate Status Server (CSS) – The Certificate Status Server provides certificate

status information to the other UniCERT components. The CSS responds to OCSP request messages by sending OCSP response messages.

2.2.2 Optional Components Optional components within Baltimore UniCERT include advanced technology modules that provide enhanced functionality for specific user environments.

• Advanced Registration Module (ARM) – The ARM is an automated registration system that allows PKI solutions to be fully integrated into database or workflow systems. It has been designed to enforce centrally generated security policies and to be easily customizable in order to meet the diverse and complex registration needs of today’s organizations.11

• Key Archive Server – The Key Archive Server securely backs up and recovers end-users

private encryption keys. This allows enterprises to implement PKI without the threat and expense of data loss. The use of the Key Archive Server to backup private encryption keys does not impact upon non-repudiation.12

• Roaming – UniCERT Roaming enables end-users to digitally sign transactions from almost

any Internet browser without the use of hardware tokens, such as smart cards.13

10 [BAL02-1] p.13 11 [BAL02-1] p.13 12 [BAL02-1] p.13 13 [BAL02-1] p.13



• Credential Server - The Credential Server controls and coordinates the operation of other roaming components. An administration interface and scripting language allows for easy management.

• Protection Encryption Key (PEK) Server - The PEK Server is a hardware device (designed

to be evaluated to FIPS-140-1 level 4) that assures the security of the system.

• Proxy Server - The Proxy Server masks the location of the Credential Server and the PEK Server from the wider network

• Roaming Applets - The Roaming applet is downloaded by the end-user and performs all of

the security operations on behalf of the user.

• XKMS Server - UniCERT XKMS streamlines key registration and validation processes and also facilitates integration of the UniCERT PKI with any XML-aware application.14

• Timestamp Server - The Timestamp Server supplies non-repudiation services by attesting to

the existence of a document at a particular time. It does this by cryptographically linking an imprint of a document along with a timestamp.15

• Telepathy Registration Server (Wireless) – The Telepathy Registration Server enables

network operators, content providers and technology vendors to provide world-class e-security services to mobile customers.16

2.2.3 Architecture The basic UniCERT architecture can be seen in Figure 1.

DirectoryCA Database

RADatabase

RA & RAeXchange

SCEP & CMPHandler

WebRAOservlets& Web

Handler

WebRAOapplet

CMP Client

SCEPRouter

CAO

RADatabase

CA, CSS & Publisher

DirectoryCA Database

RADatabase

RA & RAeXchange

SCEP & CMPHandler

WebRAOservlets& Web

Handler

WebRAOapplet

CMP Client

SCEPRouter

CAO

RADatabase

CA, CSS & Publisher

Figure 1 - Baltimore UniCERT Architecture

14 [BAL02-1] p.13 15 [BAL02-1] p.13 16 [BAL02-1] p.13



2.2.4 Supported Standards Table 2 lists supported algorithms and standards within the UniCERT product family.17

Algorithm/Standard Comments

RSA (512-4096-bit) Certificates, key generation and internal messaging DSA (1024-bit) Certificates, key generation and internal messaging ECDSA Certificates, key generation MD5 Certificates SHA-1 Certificates and internal messaging 3-DES Encryption of private keys Blum Blum Shub Random number generator X.509 Certificate (v1 and v3) and CRL (v2) standard X.962 Standard for ECDSA X.3.92 Data encryption algorithm X9.31-2 Standard for SHA-1 RFC 2459 Profile for X.509v3 certificates PKCS#1 Certificate creation, verification and internal messaging PKCS#7 Certificate reply, internal messaging PKCS#10 Certificate request syntax including cross-certification PKCS#11 Communication with external cryptographic modules PKCS#12 Vault to store private keys and certificates CMP (RFC 2510) Internal messaging and cross-certification CRMF (RFC 2511) Internal messaging and cross-certification SCEP Simple Certificate Enrolment Protocol LDAP Communication with LDAP and X.500 directories SQL Internal communication TCP/IP Internal communication POP3 Remote requests SMTP Distribution of certificates and informational messages HTTP (RFC 2560) Remote requests OCSP Supported through 3rd party software FIPS 140-1 levels 2, 3 and 4 UniCERT supports FIPS 140-1 levels 2, 3 and 4 through 3rd

party hardware FIPS 186-1 Standard for DSA FIPS 180-1 Standard for SHA-1 FIPS 46-3 Standard for 3-DES FIPS 81 CBC Standard for DES in CBC mode

Table 2 – Baltimore UniCERT Supported Algorithms & Standards

2.2.5 System Requirements UniCERT has the following system requirements:

• Each UniCERT component can be installed on a separate hardware platform if required. All communication between modules is secured for transit across public networks. UniCERT can also be completely installed on a single system – Windows 2000 Server SP2, 512Mb RAM, Pentium III – 1GHZ and 1Gb Hard drive space

• UniCERT 5.0.1 requires Oracle 8.1.7 • The CA, RA, Publisher, and Protocol Handlers all run as services on Windows 2000

17 Table 2 consists of information found in [BAL02-1].



• The CAO, WebRAO (using a standard browser) and Service Manager all run on Windows 2000 • UniCERT supports the following directory servers: Sun’s iPlanet Directory Server v5.1,

Microsoft’s Active Directory, Critical Path’s CP Directory Server v4.0 and Siemens DirX v6.0 • UniCERT Publisher is capable of publishing to Valicert’s Enterprise VA v4.2.2 • UniCERT requires a supported Web server in order to provide the necessary HTTP support for the

Web Handler and Web RAO components; IIS (Internet Information Server) v5.0 with Servlet_Exec v4.1.1 or iPlanet Web Server Enterprise Edition v6.0 (no servlet manager required)

• UniCERT supports the PKI capabilities provided in standard off the shelf desktop applications. No specific desktop client is required to be installed.

2.3 Entrust Authority Security Manager Entrust is a Texas-based security vendor. Entrust Authority Security Manager 6.0.1 is the latest release of their PKI software. Additional company and product information can be found at www.entrust.com. 2.3.1 Core Components Entrust Authority has a number of core components that are required to provide basic PKI services. Core components include Entrust Authority Security Manager, Entrust Authority Security Manager Administration, Entrust Entelligence Desktop Manager and its corresponding plug-ins.

• Entrust Authority Security Manager – Entrust Authority Security Manager is designed to manage the digital keys and certificates required to transparently automate all security related processes in an organization. It securely stores the certificate authority (CA) private key, issues certificates for users and devices, and publishes user and application certificate revocation lists (CRLs) to allow verifiable communications. It also maintains a database of users private key histories for recovery purposes in the event that users lose access to their keys.18

• Entrust Authority Security Manager Administration – Entrust Authority Security

Manager Administration is the Registration Authority for the Entrust PKI. It is used by administrators, security officers and auditors to manage users, control security policies and conduct reporting respectively.

• Entrust Entelligence Desktop Manager – The Entrust Entelligence Desktop Manager

provides the ability to easily add and manage security applied to enterprise desktop applications.19

i. E-mail Plug-in – The E-mail Plug-in is a key component of the Entrust Secure

Messaging Solution by providing security for internal and external e-mail communications when used with e-mail applications such as Microsoft Outlook, Microsoft XP and Lotus Notes.20

ii. File Plug-in – The File Plug-in provides security for files and folders that are

stored on and used by Microsoft Windows applications.21

18 paraphrased from http://www.entrust.com/authority/manager/features.htm 19 http://www.entrust.com/entelligence/desktop/index.htm 20 http://www.entrust.com/entelligence/email/index.htm 21 http://www.entrust.com/entelligence/file/index.htm



iii. Verification Plug-in for Adobe – The Verification Plug-in for Adobe may be distributed openly for public use and will automatically intervene to verify the signature on a digitally signed PDF document.22

iv. Web Plug-in – The Web Plug-in secures Web Communications by enabling

identification, verification and privacy of information on the Internet.23 2.3.2 Optional Components Optional components within Entrust Authority include advanced server components that provide enhanced functionality for specific user environments.

• Entrust TruePass – The Entrust TruePass portfolio provides end-to-end Web security with unmatched user transparency. It delivers a choice of strong identification methods to provide mobility, flexibility and ease of deployment when securing online communications.24

• Entrust Authority Self-Administration Server – The Entrust Authority Self-Administration

Server allows for easy enrolment, faster deployment, and simple recovery of digital IDs by providing users with Web-based self-registration and recovery capabilities.25

• Entrust Authority Roaming Server – The Entrust Authority Roaming Server allows users to log

in and have secure access to sensitive information – from any location – without having to carry the digital IDs necessary to establish a secure connection.26

• Entrust Authority Security Manager Proxy – The Entrust Authority Security Manager Proxy

allows customers to operate a CA over the Internet without making changes to existing firewall settings.27

• Entrust Authority Timestamp Server – The Entrust Authority Timestamp Server allows

organizations to establish trustworthy and traceable business transactions. It is a server application that acts as a trusted third party by issuing timestamps upon request to server and client-side applications.28

• Entrust Authority Enrolment Server for Smart Cards – The Entrust Authority Enrolment

Server for Smart Cards works with Entrust Authority Security Manager to issue digital certificates for leading third-party Card Management Systems (CMS).29

• Entrust Authority Enrolment Server for Web – The Entrust Authority Enrolment Server for

Web works with Entrust Authority Security Manager to issue digital certificates to applications and devices.30

• Entrust Authority Enrolment Server for VPN – The Entrust Authority Enrolment Server for

VPN works with Entrust Authority Security Manager to issue digital certificates to VPN gateways, remote access clients and routers from a wide range of industry leading vendors.31

22 http://www.entrust.com/entelligence/verification/index.htm 23 http://www.entrust.com/entelligence/web/index.htm 24 http://www.entrust.com/truepass/index.htm 25 http://www.entrust.com/authority/selfadmin/index.htm 26 http://www.entrust.com/authority/roaming/index.htm 27 http://www.entrust.com/authority/smproxy/index.htm 28 http://www.entrust.com/authority/timestamp/index.htm 29 http://www.entrust.com/authority/smartcards/index.htm 30 http://www.entrust.com/authority/web/index.htm



• Entrust Secure Transaction Platform – The Entrust Secure Transaction Platform will deliver a

set of fundamental security capabilities to enable Web services transactions to become trusted transactions.32

a) Identification Service – The Identification Service enables organizations to centrally

control which identities are trusted for automated Web service transactions.33 b) Entitlements Service – The Entitlements Service confirms that the entity trying to access a

Web service has the right to do so. Entrust is building the Entitlements Service using the SAML standard for authorization assertions.34

c) Verification Service – The Verification Service delivers integrity and accountability

capabilities for Web services transactions through centralized digital signatures and timestamping. It conforms to the XML digital signature standard.35

d) Privacy Service – The Privacy Service understands how to encrypt information so that

only specific entities can access that information.36

e) Messaging Server – The Entrust Messaging Server will be able to leverage the foundation security services delivered through the Entrust Service Transaction Platform to provide automated, server-based secure messaging capabilities.37

2.3.3 Architecture The basic Entrust PKI architecture can be seen in Figure 2.

SCEPRouter

Web ClientEntrustEntelligence

Desktop Manager

Directory

Entrust AuthoritySecurity Manager

Administration

Entrust AuthorityEnrolment Server

for Web


for VPN


(and Database)

SCEPRouter

Web ClientEntrustEntelligence

Desktop Manager

Directory


Administration


for Web


for VPN


(and Database)

Figure 2 - Entrust PKI Architecture

31 http://www.entrust.com/authority/vpn/index.htm 32 http://www.entrust.com/stp/index.htm 33 http://www.entrust.com/stp/identification.htm 34 http://www.entrust.com/stp/entitlements.htm 35 http://www.entrust.com/stp/verification.htm 36 http://www.entrust.com/stp/privacy.htm 37 http://www.entrust.com/stp/messaging.htm



2.3.4 Supported Standards Table 3 lists supported algorithms and standards within the Entrust product family.38

Algorithm/Standard Comment DES (56-bit) US FIPS PUB 46-2 and ANSI X3.92 CAST (40, 64, 80 and 128-bit) RFC 2144 Triple-DES (effective key size 168-bit) ANSI X9.52 RC2 (40 and 128-bit) RFC 2268 IDEA (128-bit) ISO/IEC 9979 Register of Cryptographic Algorithms RSA (1024 and 2048-bit) PKCS#1 Version 2.0, ANSI X9.31, IEEE P1363, ISO/IEC

14888-3, US FIPS PUB 186-2 DSA (1024-bit) Digital Signature Standard, US FIPS PUB 186-2, ANSI X9.30

Part 1, IEEE P1363 and ISO/IEC 14888-3 ECDSA (192-bit) ANSI X9.62, IEEE P1363, ISO/IEC 14888-3 and US FIPS

PUB 186-2 SHA-1 US FIPS PUB 180-1 and ANSI X9.30 Part 2 MD5 RFC 1321 MD2 RFC 1319 RIPEMD-160 ISO/IEC 10118-3:1998 RSA key transfer RFC 1421 and 1423 (PEM), PKCS#1v2 and IEEE P1363 Diffie-Hellman PKCS#3 X.509v3 ITU-T X.509 Recommendation PKCS#7 Encrypted data and message format LDAP v2 and v3 RFC 1777, 2559, 2251, 2587 PKCS#5 Private key storage PKCS#8 Private key storage PKIX-CMP RFC 2510 & 2511 PKCS#10 Certificate requests PKCS#11 Hardware cryptographic interface PKCS#12 Private key storage

Table 3 – Entrust PKI Supported Algorithms & Standards 2.3.5 System Requirements Entrust PKI has the following system requirements:

• Entrust Authority Security Manager – Windows 2000 Server SP1, 256Mb RAM, Pentium 300MHz+ and 2Gb Hard disk space

• Entrust Authority Security Manager Administration – Windows 2000 Professional, +32Mb RAM (if on the same system as the Security Manager), Pentium 300MHz+ and 5Mb Hard disk space

• Entrust Authority Security Manager requires Informix Database version 9.21 (comes included) • Entrust PKI supports the following directory servers: Critical Path Directory Server, Microsoft

Active Directory, Nexor Directory, Novell eDirectory and Siemens DirX – what about Sun ??? • Entrust Authority Security Manager is capable of publishing to the Valicert VA.

38 Table 3 consists of information found in [ENT02-1].



2.4 IDX-PKI/OpenSSL IDX-PKI is an Open Source implementation of a Public Key Infrastructure which aims to be IETF compliant for PKIX recommendations. The latest available release is IDX-PKI 1.6.1 however, IDX-PKI 1.8.x should be available in the immediate future. Additional information on IDX-PKI can be found at http://idx-pki.idealx.org or in the IDX-PKI documentation ([IDX01-1] and [IDX01-2]). IDX-PKI uses the protocol and cryptography libraries provided by OpenSSL. The Open SSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.39 Although OpenSSL can be used to create a CA and certificates using its own tools, it lacks much of the additional functionality provided by IDX-PKI. Additional information on OpenSSL can be found at http://www.openssl.org. 2.4.1 Core Components The core of IDX-PKI is a set of CGI scripts written in Perl. Each of these scripts is dedicated to an elementary task of the PKI.

• End Entity Module – The End Entity Module is used by users for certificate requests and to initiate certificate revocation.

• Registration Authority Module – The Registration Authority Module is used by certified

administrators to approve or reject requests initiated by an End Entity Module. Approved requests are forwarded on to the Certification Authority Module.

• Certification Authority Module – The Certification Authority Module generates, publishes and

revokes certificates. It is also responsible for the publication of the CRLs.

• Renewal Module – The Renewal Module consists of three renewal messages that can be configured to be sent a specified number of days before a user’s certificate expires.

• Repository LDAP Server – The Repository LDAP Server used by IDX-PKI is the OpenLDAP

LDAP directory. It is discussed in more detail in section 3.6. 2.4.2 Architecture The IDX-PKI architecture can be seen in Figure 3.

39 http://www.openssl.org



CA/RA/RenewalModules

End Entity

DirectoryCA/RA/Renewal

Modules

End Entity

Directory

End Entity

Directory

Figure 3 - IDX-PKI Architecture

2.4.3 Supported Standards Although IDX-PKI aims to be IETF compliant for PKIX recommendations there is no list of supported standards available either on the Web site or in the product documentation. 2.4.4 System Requirements IDX-PKI was tested with RedHat Linux 7.3 with the following packages added (these are not the minimal requirements, but were the latest available packages as of January 31st, 2003):

• apache (1.3.27-2) • make (3.79.1-8) • mod_perl (1.26-5) • mod_ssl (2.8.12-2) • openldap (2.0.23-4) • openldap-clients (2.0.23-4) • openldap-servers (2.0.23-4) • openssl (0.9.6b-28) • openssl-devel (0.9.6b-28) • perl (5.6.1-34.99.6) • perl-CGI (2.752-34.99.6) • perl-libwww-perl (5.63-9) • perl-MIME-Base64 (2.12-14) • php (4.1.2-7.3.6) • stunnel (3.22-1)

2.5 Microsoft Windows 2000 PKI Microsoft is a Seattle-based software company. Microsoft’s PKI is included as part of the Microsoft Windows 2000 Server and Advanced Server operating systems. Additional company and product information can be found at www.microsoft.com. 2.5.1 Core Components The primary components of the Windows 2000 PKI are:



• Certificate Services – Certificate Services are a core operating system service that allows

businesses to act as their own CAs and issue and manage their digital certificates. • Active Directory Service – The Active Directory Service is a core operating service that provides

a single place to find network resources; it serves as the publication service in the PKI.

• PKI-enabled Applications – PKI-enabled applications include Internet Explorer, Microsoft Money, Internet Information Server (IIS), Outlook and Outlook Express.

• Microsoft Management Console (MMC) – In Windows 2000, the MMC is the administrator’s

standard workspace for all administrative tasks, including those related to PKI management. From the Certificate Services MMC snap-in, administrators can easily perform all of the everyday tasks required for normal PKI maintenance:

i. They can revoke certificates when necessary ii. They can view the properties (including validity interval, last update time, and

certificate membership) for certificates or CRLs

iii. They can define templates for certificate attributes; newly created certificates inherit these attributes automatically

iv. With appropriate permissions, they can change group policy settings for users,

groups and computers 2.5.2 Optional Components Optional components of the Windows 2000 PKI include:

• Exchange Key Management Service (KMS) – KMS is a component of Microsoft Exchange that allows for archiving and retrieval of keys used to encrypt e-mail. In a future version of Windows, the KMS will become subsumed into the Windows operating system as an enterprise-wide KMS.

2.5.3 Architecture The Windows 2000 PKI architecture can be seen in Figure 4.



CA Administrator(MMC Snap-in Tools)

Web RegistrationIIS (Cert Server)

ActiveDirectoryService

ClientWeb Registration

BrowserRegistration

Win2000 Cert Client

Applications(IE, Outlook/Express,

EFS, Kerberos)

Key/Certificate Storage,Crypto-functionality (CryptoAPI,

Certificate Store, CSP)

CA CertificateService

CA Administrator(MMC Snap-in Tools)

Web RegistrationIIS (Cert Server)

ActiveDirectoryService

ClientWeb Registration

BrowserRegistration

Win2000 Cert Client

Applications(IE, Outlook/Express,

EFS, Kerberos)

Key/Certificate Storage,Crypto-functionality (CryptoAPI,

Certificate Store, CSP)

CA CertificateService

Figure 4 - Microsoft Windows 2000 PKI Architecture

2.5.4 Supported Standards Table 4 lists supported standards within Microsoft Windows 2000.40

Algorithm/Standard Comment LDAPv3 (RFC 2251) Communication with LDAP Directories PC/SC Smart card integration PKCS#1 Signature formats PKCS#7 Exchanging certificates and certificate chains PKCS#10 Certificate requests PKCS#12 Exchanging private keys PKIX (RFC 2459) Certificate revocation list format X.509v3 Certificate format

Table 4 – Microsoft Windows 2000 Supported Standards

2.5.5 System Requirements Microsoft Windows 2000 has the following system requirements:

• Windows 2000 Professional – 133MHz or higher Pentium, 64Mb RAM, 2Gb Hard Drive • Windows 2000 Server & Advanced Server – 133 MHz or higher Pentium, 256Mb RAM, 2Gb

Hard Drive

40 Table 4 consists of information found in [SEC02].



2.6 PGP Enterprise 8.0 PGP (Pretty Good Privacy) is a California-based security vendor. PGP 8.0 is the latest release of their software. Additional company and product information can be found at www.pgp.com. 2.6.1 Core Components PGP Enterprise is recommended for implementations of 20 seats or more, includes the configuration, installation and key management tools required for quick and successful implementation. PGP Enterprise provides mail and disk encryption as part of an existing PKI infrastructure or can also act as its own separate key management system.41 It includes the following components:

• PGP Admin – PGP Admin allows the configuration of PGP Mail and PGP Disk before installation on individual users’ machines. PGP Admin can pre-install corporate PGP keys into users’ keyrings as well as require the use of additional decryption keys to guarantee authorized access to confidential corporate data. It also defines the servers from which client installations automatically retrieve up to date settings and keyrings.42

• PGP Keyserver – PGP Keyserver is an LDAP server with integrated support for PGP keys. When

used in combination with the Keyserver Replication Engine, the PGP Keyserver can distribute and synchronize PGP keys across multiple servers. PGP Keyserver simplifies PGP key management in an enterprise by providing a web-based administration console for administrators to control both policies for keys as well as the policies of the PGP desktop clients in the enterprise. PGP’s enterprise products work with a variety of directory services, including Active Directory, iPlanet 4 and later, NDS/eDirectory and OpenLDAP servers. These servers can be used both to store keys of individual users, as well as serve as the deployment platform for configuration updates. 43

• PGP Mail – PGP Mail combines encryption, digital signatures, and key management to secure

electronic mail, files and instant messages.44

• PGP Disk – PGP Disk allows you to create encrypted disks whose entire contents are encrypted at all times.45

2.6.2 Architecture The PGP Enterprise architecture can be seen in Figure 5.

41 www.pgp.com 42 www.pgp.com 43 www.pgp.com 44 www.pgp.com 45 www.pgp.com



PGP AdminPGP Keyserver/

Directory

Client (PGPMail & Disk)

PGP AdminPGP Keyserver/

Directory

Client (PGPMail & Disk)

Figure 5 - PGP Enterprise Architecture

2.6.3 Supported Standards Table 5 lists supported algorithms and standards within PGP Enterprise.46

Algorithm/Standard Comments OpenPGP RFC 2440 Public key format X.50947 Public key format Diffie-Hellman Public key algorithm DSS Public key algorithm RSA v4 (up to 4096-bit) Public key algorithm AES (up to 256-bit) Symmetric key algorithm CAST Symmetric key algorithm Triple-DES Symmetric key algorithm IDEA Symmetric key algorithm Twofish Symmetric key algorithm SHA-1 Hash algorithm MD5 Hash algorithm RIPEMD-160 Hash algorithm PKCS#11 Hardware cryptographic interface LDAP Communications with LDAP directories TLS/SSL v3 with OpenPGP Extensions Network protocol IKE with OpenPGP Extensions Network protocol SECSH Network protocol

Table 5 – PGP Enterprise Supported Algorithms & Standards

2.6.5 System Requirements PGP Enterprise supports the following platforms and applications:

• Windows 98,98 SE, ME, NT SP6a, 2000 SP2 and SP3, XP • Microsoft Outlook 97, 98, 2000 and XP

46 Table 5 consists of information found on the PGP Technology Specifications page of the PGP website (www.pgp.com). 47 PGP is key format agnostic and works with both PGP keys and X.509 certificates. CA integration is possible with Sun, Microsoft, VeriSign, Entrust and others.



• Microsoft Outlook Express 4.x and 5.x • Lotus Notes 4.5x, 4.6x and R5.x • Novell GroupWise 5.5 and 6.0 client • Directory integration with iPlanet Directory Server, Microsoft Active Directory and Novell NDS

2.7 RSA Keon Certificate Authority RSA Security is a Massachusetts-based security vendor. RSA Keon 6.5 is the latest release of their PKI software. Additional company and product information can be found at www.rsa.com. 2.7.1 Core Components The core components of the RSA Keon CA are:

• Administration Server – The Administration Server is used to administer the PKI. PKI administrators use a Web browser to connect securely over an HTTPS connection to the Administration Server.48

• Enrolment Server – Users apply for digital certificate via the Enrolment Server.49

• Secure Directory – Certificate requests, issued certificates and access control lists are stored in

the Secure Directory to help ensure that they are kept from harm.50 The RSA Keon CA’s Administration and Enrolment Servers that need access to write to the Secure Directory, connect using a SSL-LDAP connection to help ensure data integrity and security. Using the SSL-LDAP connection, the Secure Directory Server may be implemented with certificate based access control. The Secure Directory is also where the RSA Keon CA’s signing engine is housed. The RSA Keon CA’s Secured Directory server is designed to provide token support for the use of HSM.51

• Logging Server – The Logging Server can be configured to record the actions of the

administrators, the requestors and other users to varying degrees.52 2.7.2 Optional Components Optional components of RSA Keon include:

• Registration Authority – The RSA Keon RA is an optional module designed to work with the RSA Keon CA to verify the credentials of certificate requests and to provide certificates to the requestor. The RA helps enable organizations to set up either remote or standalone enrolment centers for large user implementations at distributed geographic locations. The RA is built to contain the same architecture and functionality as the RSA Keon CA, except that it cannot sign certificate requests. Certificate requests must be passed to the RSA Keon CA for signing.53

48 [RSA02] p.5 49 [RSA02] p.4 50 [RSA02] p.4 51 [RSA02] p.7 52 [RSA02] p.4 53 [RSA02] p.8



• Key Recovery Module (KRM) – The RSA KRM employs a unique “m of n” collaborative key retrieval system to ensure tight control over stored private encryption keys. The private key used for recovery is divided up among the cards of several individual Key Recovery Operators (KROs). Each one holds a portion of the divided private key with the stipulation that a certain number (m) out of a total (n) of them must come together to participate in the key recovery.

• Web Sentry Plug-in – The RSA Keon Web Sentry Plug-in is an optional security solution that is

designed to work with the RSA Keon CA to enhance the certificate handling capabilities of a Web server.54

• Secure e-mail Module – The Secure e-mail Module secures e-mail for Microsoft Exchange

Server and Microsoft Outlook clients.

• Smart Badging Solution – RSA Smart Badging Solution combines the functionality of an RSA SecurID Java standards-based smart card with the characteristics of a physical ID badge, providing an integrated solution for managing access to PCs, networks and physical facilities.

• Web Server SSL Solution – The RSA Keon CA software provides capabilities for issuing and

managing SSL server certificates. The RSA Keon Root Signing Service enables RSA Security to “co-sign” private branded server certificates so they will be recognized by many widely used Web browsers and e-mail packages.

• Secure e-forms Signing – RSA e-Sign is a zero-footprint, downloadable applet that provides

digital signing capabilities based on globally recognized standards.

• Web PassPort – RSA Keon Web PassPort is an optional component that provides secure, remote storage of digital credentials, enabling anytime, anywhere secure e-forms signing.

2.7.3 Architecture The RSA Keon CA architecture can be seen in Figure 6.55

54 [RSA02] p.9 55 Figure 6 is based on the RSA architecture included in [RSA02] p.4.



OCSPResponder

SCEPServer

AdministrationServer

Web Server

EnrolmentServer

SecureDirectoryServer

CryptographicSigning Engine

Database

Logging Server

Administrator User

SSL-LDAP

httpshttps

SSL-LDAP SSL SSL-LDAP

OCSPResponder

SCEPServer

AdministrationServer

Web Server

EnrolmentServer

SecureDirectoryServer

CryptographicSigning Engine

Database

Logging Server

Administrator User

SSL-LDAP

httpshttps

SSL-LDAP SSL SSL-LDAP

Figure 6 - RSA Keon Certificate Authority Architecture

2.7.4 Supported Standards Table 6 lists supported algorithms and standards within the RSA Keon product family.56

Algorithm/Standard Comments RSA Certificates/key generation DSA Certificates/key generation ECDSA Certificates/key generation X.509 v1 and v3 Certificate format LDAP v2 and v3 Communication with LDAP and X.500 directories PKCS#11 Hardware cryptographic interface

Table 6 – RSA Keon Supported Algorithms & Standards

2.7.5 System Requirements RSA Keon has the following system requirements:

• The administration server, enrolment server, secure directory and logging server can, and usually do, reside on the same system

• Windows NT4.0 SP6a / 2000 SP2 – Pentium III 650MHz, 256Mb RAM & 100Mb Disk Drive • Sun Solaris 7 & 8 – Sparc Ultra 400MHZ, 256Mb RAM, 100Mb Disk Drive

56 Table 6 consists of information found on the RSA Keon Certificate Authority Technical Specifications page of the RSA website (http://www.rsasecurity.com/products/keon/techspecs/rsakeoncertificateauthority.html).



2.8 Sun One Certificate Server Sun is a California-based software/hardware company. Sun One Certificate Server 4.7 is the latest release of their PKI software. Additional company information can be found at www.sun.com, while product information is more readily found at http://wwws.sun.com/software/products/certificate_srvr/home_certificate.html. Note – Netscape, through AOL Strategic Business Solutions, sells the equivalent software as Netscape Certificate Management System. Until recently Sun marketed this product as iPlanet Certificate Management System. To avoid any confusion the product will be referred to as Sun One Certificate Server throughout this report. 2.8.1 Core Components The Sun ONE Certificate Server provides a full PKI solution for issuing, renewing, suspending, revoking, storing, and managing single-key and dual-key certificates. Its modular system allows organizations to deploy components in a flexible manner to address scalability, delegation, and business security practices.57 Core components of the Sun One Certificate Server include:

• Certificate Manager – The Certificate Manager issues signed certificates and maintains a database of issued certificates so that it can track renewal, expiration and revocation. This database is also used to synchronize with the directory server in case of unexpected failures.58

• Registration Manager – Registration Manager is as an optional component of the Sun ONE

Certificate Server. It performs registration authority functions, such as authenticating users, generating requests for certificates, and enforcing organizational security policies.59

• Data Recovery Manager - Data Recovery Manager serves as a secure encryption key archive

that can recover a key if the original is lost or the storage mechanism becomes damaged. Organizations can archive and escrow the encryption private key while maintaining the nonrepudiation of the security environment by never archiving the signature private key.60

• Online Certificate Status Manager – Online Certificate Status Manager checks and responds to

client requests for the status of certificates issued by Certificate Manager.61

• Agents - The designated agents for each subsystem are responsible for the everyday management of end-entity requests and other aspects of the PKI:

i. Certificate Manager agents manage certificate requests received by the Certificate

Manager subsystem, maintain and revoke certificates as necessary, and maintain global information about certificates.

ii. Registration Manager agents manage the certificate requests received by the

Registration Manager subsystem.

iii. Data Recovery Manager agents initiate the recovery of lost keys, and can obtain information about key service requests and archived keys.

57 http://wwws.sun.com/software/products/certificate_srvr/ds_certificate.html 58 http://wwws.sun.com/software/products/certificate_srvr/ds_certificate.html 59 http://wwws.sun.com/software/products/certificate_srvr/ds_certificate.html 60 http://wwws.sun.com/software/products/certificate_srvr/ds_certificate.html 61 http://wwws.sun.com/software/products/certificate_srvr/ds_certificate.html



iv. Online Certificate Status Manager agents can perform tasks such as checking which CAs are currently configured to publish their CRLs to the Online Certificate Status Manager, identifying a Certificate Manager to the Online Certificate Status Manager, adding CRLs directly to the Online Certificate Status Manager, and viewing the status of OCSP service requests submitted by OCSP-compliant clients.62

2.8.2 Optional Components

Optional components of the Sun One Certificate Server include:

a) Plug-in Modules – Plug-in modules help you configure and customize CMS, and use it for issuing

and managing certificates to various end entities, such as web browsers, servers, VPN clients and Cisco routers.

• Authentication Plug-in Modules – They are used for authenticating end-users during

certificate enrolment. • Job Plug-in Modules – They are used to automate certain certificate-related tasks such

as notifying agents when a request gets queued, notifying users before their certificates expire, and removing expired certificates from the directory to ease administration.

• Constraints Policy Plug-in Modules – They govern the formulation of certificate content, such as key size, signing algorithm, validity period, etc., and issuance of certificates.

• Certificate Extension Plug-in Modules – They enable you to add standard (X.509) and proprietary certificate extensions to certificate requests.

• Mapper Plug-in Modules – They are used to configure a Certificate Manager to locate directory entries for publishing certificates and CRLs to the directory.

• Publisher Plug-in Modules – They are used to configure a Certificate Manager to publish certificates to the correct attribute of the located directory entries.

• CRL Extension Plug-in Modules – They are used to configure a Certificate Manager to set CRL extensions in CRLs before generating them and publishing them to a directory.

• Log Plug-in Modules – They are used to configure Certificate Management System logs. 2.8.3 Architecture The Sun One Certificate Server Architecture can be seen in Figure 7.

DirectoryData Recovery

Manager

RegistrationManager

Client

CertificateManager

DirectoryData Recovery

Manager

RegistrationManager

Client

CertificateManager

Figure 7 - Sun One Certificate Server Architecture

62 [SUN02-2] p.15



2.8.4 Supported Standards Table 7 lists Sun One Certificate Server supported standards and algorithms.63

Standard Comments SCEP Simple Certificate Enrolment Protocol CRMF Certificate Request Message Format (PKIX) CMMF Certificate Management Message Format (PKIX) CMC Certificate Management Messages over CMS (PKIX) CMS Cryptographic Message Syntax (PKIX) FIPS 140-1 Federal Information Standards Publication (FIPS PUBS) 140-1 HTTP/HTTPS Hypertext Transport Protocol/Secure KEYGEN tag An HTML tag supported by Netscape browsers that generates a key pair for

use with a certificate LDAP v2 & v3 Lightweight Directory Access Protocol (LDAP) PKCS#7 Encrypted data and message format PKCS#10 Message format PKCS#11 API used to communicate with cryptographic hardware tokens X.509 v1 & v3 Digital certificate formats SSL 2.0 & 3.0 Secure Sockets Layer OCSP Online Certificate Status Protocol

Table 7 – Sun One Certificate Server Supported Algorithms & Standards

2.8.5 System Requirements Sun One Certificate Server has the following system requirements:

• Sun Solaris 8, Windows NT 4.0 SP6 or Windows 2000 Server • Ultra 1 or Pentium III 400MHz • 256Mb RAM and 350Mb Hard Drive

2.9 Valicert Validation Authority Valicert is a California-based software vendor. Valicert Enterprise VA 4.2.2 is the latest release of their validation software. Additional company and product information can be found at www.valicert.com. On 18 February 2003 Valicert issued a press release stating that they had been acquired by Tumbleweed Communications, a provider of secure messaging solutions. Additional company information can be found at www.tumbleweed.com. 2.9.1 Core Components The core products of the Valicert Enterprise Validation Authority include:

• Enterprise VA – The Enterprise VA can be administered locally or remotely from a standard web browser (SSL-based). It provides validity status responses for any X.509 certificate, and employs

63 Table 7 consists of information found in [SUN02-1].



today’s most widely used certificate status checking mechanisms. The Enterprise VA supports the following mechanisms:

i. Certificate Revocation Lists (CRLs) ii. CRL Distribution Points (CRLDPs) iii. Online Certificate Status Protocol (OCSP) iv. Simple Certificate Validation Protocol (SCVP) v. Certificate Management Protocol (CMP) vi. Instant Revocation (local CMP)

• VA Publisher – The VA Publisher obtains revocation data from a CA or a directory server

supporting LDAP, and then transports it to a Valicert VA. • Enterprise VA Administration Server (Admin Server) - The Admin Server provides web-

based installation and management of the Valicert product components.

• Validator Suite – The Validator Suite incorporates validation functionality into existing applications using Server Validators for common server software (such as Web servers) and Desktop Validators for common client-side applications (like e-mail and Web browsers).

2.9.2 Optional Components Optional components of the Valicert Enterprise Validation Authority include:

• Validator Toolkit – The Validator Toolkit adds digital certificate validation functionality to third-party and custom applications through a variety of mechanisms including CRLs, OCSP, SCVP and CRL distribution points.

2.9.3 Architecture Figure 8 illustrates the Valicert Validation Authority Architecture.

VA Publisher VA Publisher

Valicert Validator Valicert Validator

OCSP/CRL

RevocationData

ValidationAuthority

CA#1 CA#2

Client Client

VA Publisher VA Publisher

Valicert Validator Valicert Validator

OCSP/CRL

RevocationData

ValidationAuthority

CA#1 CA#2

Client Client

Figure 8 - Valicert Validation Authority Architecture



2.9.4 Supported Standards Table 8 lists the Valicert Validation Authority supported algorithms and standards.64

Algorithm/Standard Comments OCSP RFC 2560 SSL v2, v3, TLS Secure protocol FIPS 140-1 Level 1 Federal Information Processing Standard validation CMP RFC 2510 CRL v2 Certificate revocation list format Delta CRL revocation updates Certificate revocation list format X.509 Certificate format PKCS#1 Certificate creation, verification PKCS#7 Certificate reply PKCS#10 Certificate request PKCS#11 Hardware cryptographic interface CAPI Key generation and signing RSA Key generation and signing SCVP RFC Draft SHA-1 Hash function MD5 Hash function LDAP Communication with LDAP and X.500 directories

Table 8 – Valicert Validation Authority Supported Algorithms & Standards

2.9.5 System Requirements Valicert Enterprise Validation Authority has the following system requirements:

• Solaris, AIX 4.3.3, Windows NT and 2000 • Windows 2000, Disk Space 100Mb, Memory – minimum 64Mb, recommended 128Mb • Publisher - Windows 2000, Disk Space 20Mb, Memory – minimum 32Mb, recommended 64Mb • Works well with major CA products and services, including Baltimore, Entegrity, Entrust,

Microsoft and Sun

64 Table 8 consists of information found in [VAL02-1].



3.0 Directory Software Products

3.1 Overview The DRDC PKI Laboratory will initially contain seven leading directory services products. Of the seven products, four are Lightweight Directory Access Protocol (LDAP) directories and three are X.500 directories. Table 9 lists the products initially selected for inclusion in the lab. In any case this list will likely evolve according to specific DRDC projects, DND requirements and changing market conditions.65

Vendor Product Name Justification Type Critical Path Directory Server Prominent directory vendor X.500 Microsoft Active Directory DND standardizing on Windows

2000 LDAP

Nexor Directory Used within DND (MMHS) X.500 Novell eDirectory Prominent directory vendor LDAP OpenLDAP OpenLDAP Open source directory LDAP Siemens DirX Prominent directory vendor

Used within GoC X.500

Sun Sun One Directory Server Prominent directory vendor LDAP

Table 9 – Directory Vendors This section provides a brief introduction to each of the directory software products.

3.2 Critical Path Directory Server Critical Path is a California-based software vendor. Critical Path Directory Server 4.0 is the latest release of their X.500 directory. Additional company and product information can be found at www.cp.net. The Critical Path Directory Server is a highly scalable directory that enables the high speed access to user profiles and other data required by mission-critical systems and applications. Delivering reliable, easy-to-manage, distributed access to information, the Critical Path Directory Server is compatible with the industry's broadest range of applications and systems.66 iCon is a multi-server, single point management product that is controlled from a standard HTTP client. It allows the directory administrator to securely manage the directory system as a single entity.

3.3 Microsoft Active Directory

65 Oracle Internet Directory and Tivoli (IBM) SecureWay Directory are two prominent directory services initially excluded from the DRDC PKI Laboratory. 66 http://www.cp.net/solutions/directoryServer.html



Microsoft is a Seattle-based software company. Microsoft Active Directory is included as part of the Microsoft Windows 2000 Server operating system. It is an LDAP directory. Additional company and product information can be found at www.microsoft.com. The Windows 2000 Active Directory service plays many roles, from being the backbone of distributed security in Windows 2000 to providing a framework for publishing network services. It provides a central service for administrators to organize network resources; to manage users, computers, applications, and services; and to secure intranet and Internet network access. In a policy-based networking architecture, Active Directory additionally serves as the “policy store” where policies are defined and bound to objects or aggregates of objects.67 In Windows 2000, the Microsoft Management Console (MMC) is the administrator’s standard workspace for all administrative tasks, including those related to Directory management. The Active Directory Users and Groups snap-in allows administrators to manage Active Directory itself. Along with the standard directory management task you expect to see, administrators can create group policies to apply network-wide trust decisions, automatically enrol users or machines by issuing them certificates from a particular issuer, or manage the location and availability of individual certificates or CRLs.

3.4 Nexor Directory Nexor is a UK-based company. The Nexor Directory is used within DND as part of the Military Message Handling System (MMHS). Version 5.0 is the latest release of their X.500 directory. Additional company and product information can be found at www.nexor.com.

Nexor Directory is specifically designed for organizations where the sending and receiving of an email is critical, where the directory is an integral part of the existing infrastructure and high performance is absolutely key. These are environments where a failure in the directory would cause an overall system failure, a failure that could not be tolerated. These applications include PKI backbones, routing systems and ecommerce backbones.

Nexor Directory Administrator is an administrative directory user agent (ADUA) to facilitate browsing and modification of an X.500 directory. It uses the international standard Directory Access Protocol (DAP) to access the directory service. Nexor Directory Administrator is closely integrated into Windows 2000 Explorer, and introduces an "X.500 Neighbourhood" that allows access to multiple directory servers. Administrators can then manage the directory information in a similar manner to the files on the local computers' file system.68

3.5 Novell eDirectory Novell is a Utah-based company. Novell eDirectory 8.7 is the latest release of their LDAP directory. Additional company and product information can be found at www.novell.com.

67 http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/denad.asp

68 http://www.nexor.com/directory_products.asp



Note – Novell eDirectory used to be called Novell Directory Server (NDS). Novell eDirectory provides centralized identity management, infrastructure, Net-wide security, and scalability to all types of applications running behind and beyond the firewall. Novell eDirectory 8.7 introduces Web-based and wireless management capabilities, allowing you to access and manage the directory and users, access rights, and network resources from a Web browser and a variety of handheld devices.69 Novell iManager is a utility that supports secure directory administration through a Web browser. The TLS/SSL services provided are based on the OpenSSL source code. Note – Although Novell offers a certificate service of their own, it is not being used within the DRDC PKI Laboratory. The Novell PKI snap-in for ConsoleOne allows full management of all Novell certificates that it finds on the User object. Most if not all PKI systems that are LDAP-enabled publish their certificates this same way. Therefore, ConsoleOne can be used as a central place to view and manage certificates from a variety of PKI vendors70.

3.6 OpenLDAP OpenLDAP software is an open source implementation of LDAP Version 2 and Version 3. The latest version is OpenLDAP 2.1.12. The suite includes:

• slapd - stand-alone LDAP server • slurpd – stand-alone LDAP replication server • libraries – implementing the LDAP protocol • utilities, tools and sample clients

The OpenLDAP 2.x server does not support a number of LDAPv3 (RFC 3377) features and extensions. Specifically, it does not support:

• DIT Content Rules • DIT Structure Rules • Name Forms • Schema Updates (using LDAP)

The OpenLDAP server does not implement the following RFC-defined extensions:

• Dynamic Directory Services (RFC 2589) • Operational Signatures (RFC 2649) • Simple Paged Result Control (RFC 2696) • Server Side Sorting of Search Results (RFC 2891)

Additional information on OpenLDAP can be found http://idx-pki.idealx.org/.

3.7 Siemens DirX

69 http://www.novell.com/documentation/lg/edir87/index.html 70 [NOV99]



Siemens is a German-based company. DirX is in use by the Government of Canada. Government employees, via an Intranet, and the public, via the Internet, can retrieve names, addresses and areas of responsibility for 170,000 government employees. Siemens DirX 6.0 is the latest version of their X.500 directory. Additional company and product information can be found at www.siemens.com. DirXmanage is a graphical administration interface that combines a Windows Directory Browser and an administration tool. It allows system administrators to perform queries and to manage DirX LDAP servers and DSAs. DirX supports the X.509V3(97) standard for secure management of public key certificates. As a result, the storage of certificates and revocation lists which can be produced by Certification Authorities (CA) is also supported. DirX has been successfully tested with products from leading CA vendors.

3.8 Sun One Directory Server

Sun is a California-based software/hardware company. Sun One Directory Server 6.02 is the latest release of their LDAP directory. Additional company and product information can be found at www.sun.com.

Note – Sun One Directory Server is the new name for the iPlanet Directory Server.

The Sun One Directory Server is a software product that provides a central repository for storing and managing identity profiles, access privileges and application and network resource information. Information stored in the Sun ONE Directory Server can be used for the authentication and authorization of users to enable secure access to enterprise and Internet services and applications. The software helps improve security and protection of key corporate information assets by ensuring appropriate access control policies are enforced across all communities, applications, and services on a global basis71.

71 http://wwws.sun.com/software/products/directory_srvr/home_directory.html



4.0 Interoperability Initiatives

4.1 Overview Lack of interoperability is commonly viewed as the largest single impediment to the widespread adoption of PKI technology. Numerous standards initiatives and a variety of interoperability projects have all attempted to overcome this obstacle. It is an intention of the DRDC PKI Laboratory to not only learn from previous interoperability initiatives, but to build upon them and, where possible, collaborate with ongoing PKI interoperability efforts. This section briefly details a number of the more prominent standards activities and interoperability trials. The initiatives listed are either ongoing or recently completed. No attempt has been made to include initiatives that, although successful, have long since finished (e.g. the NACHA Internet Council Certificate Authority Pilot). While the initiatives in this section are not explained in great detail, readers that are interested in further information are encouraged to refer to the referenced documents and URLs. Interoperability initiatives detailed in this section include the following:

• Communications-Electronics Security Group • DoD Bridge CA Technology Demonstration • Internet Engineering Task Force • International Telecommunications Union • National Institute of Standards and Technology PKI Program • OASIS • PKI Challenge • Public-Key Cryptography Standards • World Wide Web Consortium

4.2 Communications-Electronics Security Group (CESG) The Communications-Electronics Security Group (CESG) established the Cloud Cover project to ensure that UK government departments had access to a whole range of interoperable PKI products. As part of this project, CESG conducted a secure messaging and PKI interoperability trial that started in April 2001 and concluded with the release of a final report in May 2002 [CESG02]. The aim of the trial was to determine the level of interoperability achievable between disparate PKI and messaging products. Additional information concerning Cloud Cover and the Secure Messaging and PKI Interoperability Trial can be found at http://www.cesg.gov.uk/cloudcover.

4.3 DoD Bridge Certification Authority Technology Demonstration The Federal Government sponsored a project tailored toward the implementation of a Bridge Certification Authority (BCA) as a means to provide interoperability among independently established and operated



public key infrastructures (PKIs). The project, which became known as the BCA demonstration, is designed to prove that the BCA concept and by association, the border directory concept, is technically possible and is useful and effective for facilitating trust relationships among many different PKIs which operate under different certificate policies.72 The BCA concept has value to the Department of Defense (DoD) both for its potential to enable interoperability between the DoD and other Federal government agencies, and because the connection of peer-level PKIs via a bridge is a good fit for situations involving allied military forces.73 Additional information concerning the DoD Bridge CA can be found at http://www.anassoc.com/BCA.html. 4.3.1 BCA Interoperability Test Suite The Bridge CA Interoperability Test Suite (BITS) is a test resource provided to facilitate development of secure, interoperable, public key enabled applications. The U.S. Department of Defense recently completed the BCA Technology Demonstration Phase II. As part of that demonstration, a number of demonstration scenarios and test data were documented and generated. This test data was subsequently compiled together into the BITS. The BITS provides a standard set of test data that can be used to determine a product's degree of interoperability (including error conditions) with the BCA Technology Demonstration Phase II architecture.74

4.4 Internet Engineering Task Force (IETF) The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.75 Additional information can be found at www.ietf.org. 4.4.1 IPSEC Internet Protocol Security (IPSec), the protocol used to implement Virtual Private Networks (VPNs), contains a protocol for key exchange between IP nodes for the purpose of authenticity, integrity and confidentiality.76 The Internet Key Exchange (IKE) protocol [RFC2409] is a subset of a more complex key management protocol, ISAKMP (Internet Security Association and Key Management Protocol [RFC2408]), and a key exchange protocol (Oakley [RFC 2412]). IKE provides for certificate-based authentication at the IP layer and, to this end, specifies a profile of X.509 certificates suitable for its purposes.77 Note: I don’t think this is true. I can’t find any X.509 certificate profile specification in RFC 2409. Please correct this statement. Relevant IPSEC RFCs are listed in Table 10 below: Note: In footnotes 76, 77, what is the meaning of CA&SL??

72 http://www.anassoc.com/BCA.html 73 [BCA01] p.3 74 http://bcatest.atl.getronicsgov.com/bits.htm 75 http://www.ietf.org/overview.html 76 p.210 CA&SL 77 p.210 CA&SL



RFC # RFC Title Date RFC 2401 Security Architecture for the Internet Protocol November 1998 RFC 2402 IP Authentication Header November 1998 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH November 1998 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH November 1998 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV November 1998 RFC 2406 IP Encapsulating Security Payload (ESP) November 1998 RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP November 1998 RFC 2408 Internet Security Association and Key Management Protocol

(ISAKMP) November 1998

RFC 2409 The Internet Key Exchange November 1998 RFC 2410 The NULL Encryption Algorithm and Its Use With IPSec November 1998 RFC 2411 IP Security Document Roadmap November 1998 RFC 2412 The OAKLEY Key Determination Protocol November 1998

Table 10 – Relevant IPSec RFCs Additional information on the IPSec working group can be found at www.ietf.org/html.charters/ipsec-charter.html. 4.4.2 Lightweight Directory Access Protocol (LDAP) The Lightweight Directory Access Protocol (LDAP) was originally conceived as a simple-to-describe, simple-to-implement subset of the capability of the X.500 Directory Access Protocol (DAP). Over time, this “subset” of useful functions and features has expanded to incorporate the needs of the many different environments that have chosen to use LDAP as the access protocol for their repository (X.500-compliant directory or otherwise).78 The LDAPv3 core specification is RFC 2251-2256 and 2829-2831. RFC 3384 specifies a standard for directory replication. These RFCs are listed in Table 11 below:

RFC # RFC Title Date 2251 Lightweight Directory Access Protocol (v3) December 1997 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax

Definitions December 1997

2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names

December 1997

2254 The String Representation of LDAP Search Filters December 1997 2255 The LDAP URL Format December 1997 2256 The Summary of the X.500 (96) User Schema for use with LDAPv3 December 1997 2829 Authentication Methods for LDAP May 2000 2830 Lightweight Directory Access Protocol (v3): Extensions for

Transport Layer Security May 2000

2831 Using Digest Authentication as a SASL Mechanism May 2000 3384 LDAPv3 Replication Requirements October 2002

Table 11 – Core LDAPv3 RFCs Additional information on the LDAPv3 working group can be found at www.ietf.org/html.charters/ldapbis-charter.html.

78 [ADA99] p.208



4.4.3 OpenPGP PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information “objects”. As such it is well suited for any store and forward application79. OpenPGP is an open specification for Pretty Good Privacy (PGP). The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols.80 The OpenPGP RFCs are listed in Table 12 below:

RFC RFC Title Date RFC 2440 OpenPGP Message Format November 1999 RFC 3156 MIME Security with OpenGPG August 2001

Table 12 – OpenPGP RFCs Additional information on the OpenPGP working group can be found at http://www.ietf.org/html.charters/openpgp-charter.html. 4.4.4 Public Key Infrastructure X.509 The PKIX Working Group was established in the Fall of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. The scope of PKIX work has expanded beyond this initial goal. PKIX not only profiles ITU PKI standards, but also develops new standards apropos to the use of X.509-based PKIs in the Internet.81 The PKIX RFCs are listed in Table 13 below:

RFC RFC Title Date RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management

Protocols March 1999

RFC 2511 Internet X.509 Certificate Request Message Format March 1999 RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and

Certification Practices Framework March 1999

RFC 2528 Internet Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates

March 1999

RFC 2559 Internet X.509 Public Key Infrastructure Operational Protocols – LDAPv2

April 1999

RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP

June 1999

RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

May 1999

RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema June 1999 RFC 2797 Certificate Management Messages over CMS April 2000 RFC 2875 Diffie-Hellman Protocol Possession Algorithms July 2000 RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and

Certification Server Protocols February 2001

RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates June 2001 79 http://www.ietf.org/html.charters/openpgp-charter.html 80 http://www.ietf.org/html.charters/openpgp-charter.html 81 http://www.ietf.org/html.charters/pkix-charters.html



Profile RFC 3161 Internet X.509 Public Key Infrastructure Time Stamp Protocols

(TSP) August 2001

RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile

April 2002

RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

April 2002

RFC 3281 An Internet Attribute Certificate Profile for Authorization April 2002 RFC 3379 Delegated Path Validation and Delegated Path Discovery Protocol

Requirements September 2002

Table 13 – PKIX RFCs

Additional information about the PKIX working group can be found at http://www.ietf.org/html.charters/pkix-charters.html. 4.4.5 S/MIMEv3 The Secure Multipart Internet Mail Extensions (S/MIME) specifications, originally developed by RSA, have been further developed and incorporated into the IETF. They define a digital signature wrapper and an encryption wrapper for securing MIME electronic mail. The S/MIMEv3 specifications include discussion of PKI concepts such as certificate format, certificate processing and CRLs. These specifications give a profile for X.509 certificates that is compliant with PKIX [RFC2459] but that specifies the extensions relevant to S/MIME. Furthermore, provision is made in the message envelope to carry arbitrary numbers of certificates and CRLs to assist the recipient with the task of path construction and certificate validation.82 The relevant subset of S/MIMEv3 RFCs is listed in Table 14 below:

RFC RFC Title Date RFC 2630 Cryptographic Message Syntax June 1999 RFC 2632 S/MIME Version 3 Certificate Handling June 1999 RFC 2633 S/MIME Version 3 Message Specification June 1999 RFC 2634 Enhanced Security Services for S/MIME June 1999

Table 14 – Relevant S/MIMEv3 RFCs

Additional information on the S/MIMEv3 working group can be found at http://www.ietf.org/html.charters/smime-charter.html. 4.4.6 Transport Layer Security (TLS) The TLS Working Group was established in 1996 to standardize a ‘transport layer’ security protocol. The working group began with SSL version 3.0, and in 1999, RFC 2246, TLS Protocol Version 1.0 was published as a Proposed Standard.83 The primary goal of the TLS Protocol is to provide privacy and data integrity between two communications applications.84 The relevant subset of TLS RFCs is listed in Table 15 below:

82 [CAR99] p.209 83 http://www.ietf.org/html.charters/tls-charter.html 84 http://www.ietf.org/rfc/rfc2246.txt



RFC RFC Title Date RFC 2246 The TLS Protocol Version 1.0 January 1999 RFC 2818 HTTP over TLS May 2000

Table 15 – Relevant TLS RFCs

Additional information on the TLS working group can be found at http://www.ietf.org/html.charters/tls-charter.html.

4.5 International Telecommunications Union (ITU) The International Telecommunications Union (ITU), headquartered in Geneva, Switzerland is an international organization within the United Nations System where governments and the private sector coordinate global telecom networks and services.85 Two relevant standards are as follows:

• X.500 The Directory: Overview of concepts, models and services • X.509 The Directory: Public-key and attribute certificate frameworks

Additional information on these and other ITU standards can be found at www.itu.org.

4.6 National Institute of Standards and Technology PKI Program The National Institute of Standards and Technology (NIST) is taking a leadership role in the development of a Federal Public Key Infrastructure that supports digital signatures and other public key-enabled security services. NIST is coordinating with industry and technical groups developing PKI technology to foster interoperability of PKI products and projects.86 Relevant NIST projects include the following:

• Application Programming Interface • Common Signed Information Format • Federal Bridge Certification Authority • Minimum Interoperability Specifications for PKI Components • PKI Component Testing • PKI Interoperability Testbed • PKI Technical Working Group

4.6.1 Application Programming Interface (API)

The PKI Group is currently working with the Federal Deposit Insurance Corporation (FDIC) to develop a high-level Application Programming Interface (API) for public-key based cryptographic services. Currently, PKI-enabled applications must use proprietary, vendor-provided APIs to interface with their 85 http://www.itu.org 86 http://csrc.nist.gov/pki/



PKI, thus making support across multiple PKI products difficult. To facilitate the development and wide-deployment of PKI-enabled applications, NIST and FDIC are working to make this interface to a PKI consistent, regardless of the PKI product being used.87

4.6.2 Common Signed Information Format The objective of this research is to develop a common signed information format that could be used independently from the signing application. This would enable interoperability of digital signature generation and verification regardless of the application used to generate the digital signature and would result in greater end user acceptance, since users will not be required to manage multiple or special signature verification applications. The method employed by the research is to work with a particular commercial industry (i.e. the healthcare industry) to develop a standard, interoperable format for digitally signed information that can ultimately be used not only in the healthcare industry, but for all digital signatures employed across all industries.88

4.6.3 Federal Bridge CA The Federal Bridge CA program is managed by the General Services Administration (GSA) under the direction of the Federal PKI Steering Committee and focuses on developing and fielding an operational Federal PKI.89 The challenge facing the Federal PKI is to meld the individual agency initiatives that use PKI products from a variety of commercial vendors, into an integrated PKI that is interoperable internally as well as with state and local governments, foreign governments, businesses and the general public.90 The X.509 Certificate Policy for the FBCA (DRAFT) defines five certificate policies for use by the FBCA to facilitate Agency CA interoperability with the FBCA and with other Agency PKI domains. The five policies represent four different assurance levels (Rudimentary, Basic, Medium, and High) for public key digital certificates, plus one assurance level used strictly for testing purposes (Test).91

4.6.4 Minimum Interoperability Specification for PKI Components NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten CRADA partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. The specification includes support for multiple signature algorithms and transactions to support a broad range of security policies.92

4.6.5 PKI Component Testing

87 http://csrc.nist.gov/pki/pkiapi/welcome.htm 88 http://csrc.nist.gov/pki/signed_info_format/welcome.htm 89 http://bcatest.atl.getronicsgov.com/faq.htm 90 [FBCA00-02] p.3 91 http://csrc.nist.gov/pki/fbca/welcome.html 92 http://csrc.nist.gov/pki/mispc/welcome.html



NIST worked with Cygnacom Solutions and Getronics Government Solutions, LLC to develop a suite of tests that will enable developers and validation laboratories to determine a PKI client application's conformance to the path processing rules as specified in X.509.93 Version 1.07 of the X.509 Path Validation Test Suite is available at http://csrc.nist.gov/pki/testing/x509paths.html.

4.6.6 PKI Interoperability Testbed The PKI Interoperability Testbed project is designed to test the interoperability and overall functionality attained using current PKI technology. The project includes PKI components for in-house testing and configuration into different PKI architectures.94

4.6.7 PKI Technical Working Group The PKI-TWG is an open group focusing on technical obstacles to implementation and use of public key infrastructures by government agencies. NIST chairs the TWG, which is composed of technical participants from Federal agencies and industry.95

4.7 OASIS OASIS is a not-for-profit, global consortium (over 600 corporate and individual members in 100 countries) that drives the development, convergence and adoption of e-business standards. OASIS produces worldwide standards for security, web services, XML conformance, business transactions, electronic publishing, topic maps and interoperability within and between marketplaces.96 On 4 November 2002 the PKI Forum (www.pkiforum.org) became the OASIS PKI Technical Committee (TC). The purpose of the PKI TC is to address issues related to the successful deployment of digital certificates to meet business and security requirements, as well as technical and integration/interoperability issues. The TC will increase the awareness of digital certificates as an important component when managing access to network resources, delivering secured electronic messages and conducting secure electronic transactions, and will provide a forum for a broad community utilizing PKI and digital certificates in application-focused standards and projects, as well as a mechanism for the creation of documents related to the implementation of PKI.97

4.8 PKI Challenge

93 http://csrc.nist.gov/pki/ 94 http://csrc.nist.gov/pki/rootca/welcome.html 95 http://csrc.nist.gov/pki/twg/welcome.html 96 http://www.oasis-open.org/who/ 97 http://www.oasis-open.org/committees/pki/



The PKI Challenge is a two year project funded by the European Commission and the Swiss Government. Led by EEMA98as part of a 13-strong consortium team, the pki Challenge involves PKI technology vendors and other interested parties with the aim of solving interoperability problems between PKI/PKA technologies.99 The project started in January 2001 and was scheduled for completion by December 2002.100 The project has the following characteristics:

• Directory – pkiC is not a directory interoperability challenge, and has little resources to address this issue101; The interoperability of Directories within a PKI is an issue in itself. For the purpose of the pki Challenge, the testing participants will use their preferred directory system for ‘publication’ of certificates and certificate revocation information by their CA / RA, and each application will only need to access one central ‘meta’ directory which, when queried, will take care of all of the complexities of distributing LDAP requests to the other vendors’ directories in a way that can be understood.102

• Lead Application (S/MIMEv3) - There are many potential applications that might be taken into

consideration, however, the scope and scale of the pkic project dictates the selection of a small set that all (or most) vendors can be expected to implement in time for interoperability testing during Q1-2, 2002.103

• Other Applications – Within the context of the PKIC other applications can be tested to establish

that they can interoperate with the PKIC PKI reference implementation. For such applications there will be no PKIC reference application, however participants may demonstrate the inter-working of their own applications whilst interfacing to the PKIC PKI reference implementation.104

• Reference – Each testing participant will test their selected product(s) remotely against a

reference implementation.105 Additional information on the EEMA PKI Challenge can be found at https://www.eema.org/pki-challenge/index.asp.

4.9 Public-Key Cryptography Standards The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography. First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the PKCS documents have become widely referenced and implemented. Contributions from the PKCS series have become part of many formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/MIME, and SSL.106 The relevant PKCS standards can be seen in Table 16.

PKCS # PKCS Title

98 EEMA – European Forum for Electronic Business 99 https://www.eema.org/pki-challenge/index.asp 100 At the time of writing, the pki Challenge final report had not been made publicly available. 101 [PKIC01-02] p.1 102 [PKIC02-01] p.5 103 [PKIC01-01] p.2 104 [PKIC01-04] p.19 105 [PKIC02-01] p.5 106 http://www.rsasecurity.com/rsalabs/pkcs/



PKCS #7 Cryptographic Message Syntax Standard PKCS #10 Certification Request Syntax Standard PKCS #11 Cryptographic Token Interface Standard PKCS #12 Personal Information Exchange Syntax Standard

Table 16 – Relevant PKCS Standards

Additional information on the PKCS standards can be found at http://www.rsasecurity.com/rsalabs/pkcs/.

4.10 World Wide Web Consortium (W3C) The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. It is an international industry consortium (nearly 450 organisations) jointly run by the MIT Laboratory for Computer Science (MIT LCS) in the USA, the National Institute for Research in Computer Science and Control (INRIA) in France and Keio University in Japan.107 XML Encryption WG The mission of this Working Group (WG) is to develop a process for encrypting/decrypting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intended recipient to decrypt it.108 XML Key Management WG The mission of this working group is to develop a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service. This specification will be based on the XML Key Management Specification (XKMS).109 XKMS specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature [XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption. The XML Key Management Specification (XKMS) comprises two parts – the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). The X-KISS specification defines a protocol for a Trust service that resolves public key information contained in XML-SIG clients. … A key objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients and thereby to be shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. The underlying PKI may be based upon a different specification such as X.509/PKIX, SPKI or PGP. The X-KRSS specification defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS.110 XML Signature WG The mission of this working group is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URL) and 107 http://www.w3.org 108 http://www.w3.org/encryption/2001/ 109 http://www.w3.org/2001/xkms/ 110 http://www.w3.org/TR/xkms



procedures for computing and verifying such signatures. This is a joint Working Group of the IETF and W3C.111

111 http://www.w3.org/signature/



5.0 PKI-Enabled Applications The adoption of PKI technology by organizations and companies worldwide has been slowed by the limited availability of applications capable of leveraging this infrastructure. This lack of PKI-enabled applications has drastically reduced the potential return on investment and made it difficult to make a business case for the technology. In order to maximize their investment many organizations attempted to use the myriad of product-specific APIs and toolkits available to PKI-enable their own in-house applications. This was found to be an expensive proposition that tied the organization to one particular PKI vendor. With the inclusion of PKI functionality in Windows 2000 and XP Professional, and a common API (CryptoAPI) with which to access PKI services, this is all starting to change. It is now the software vendors, not PKI vendors, who are PKI-enabling applications. This should have the effect of increasing the number of PKI-enabled applications available, thus improving the return on investment for organizations contemplating the use of this technology. These advances should also facilitate the process of PKI-enabling in-house applications and ultimately make them supportable long into the future. This section provides an overview of a number of PKI-enabled applications that are available off of the shelf. Organizations typically have a large number of in-house applications requiring security services. These applications are outside of the scope of this report.

5.1 File Security Sensitive information stored on desktop computers is susceptible to theft. This risk is compounded if the system is connected to a network or if the system itself is physically located in an insecure area. Personal digital assistants (PDAs) and laptop computers are perhaps even more susceptible to information theft given the high rate at which they are physically targeted. Encrypting sensitive files is the preferred method to mitigate the risk of information theft. While a PKI is not required for file security it does facilitate the process of recovering encrypted files in the event of a user forgetting their password or leaving the organization. PKIs accomplish file recovery through the retention of users’ private decryption keys in the CA’s database.

5.2 Secure Document Management Document Management Systems (DMS) provide the necessary infrastructure for organizations to centrally manage information resources. Documents are typically published to a central file server where access to these information resources is maximized. DMS also provide the opportunity to control access to sensitive information resources through the use of a privilege management infrastructure (PMI). PKI provides the means with which users can be authenticated to the DMS, and ultimately to the PMI. Providing the user is entitled to access a sensitive information resource the underlying PKI can also be used to secure the resource for that particular user. This capability, known as content-based encryption, mitigates the risk of document compromise while it is in transit to the user. PKIs can also provide a digital signature capability that could be used as part of the publishing component of a DMS.

5.3 Secure E-mail E-mail is as indispensable in today’s business environment as the telephone. Unfortunately, e-mail travelling over a company’s network is susceptible to interception, modification and fraud. E-mail travelling over the Internet is even more at risk. PKI provides a scalable infrastructure with which to encrypt and digitally sign e-mail messages and their attachments. Encryption ensures that electronic communications between two parties remain confidential. Digital signatures ensure that e-mail messages



are not modified in transit and that the sender’s identity is verifiable. In conjunction with certificate revocation checking and timestamping, digital signatures can be used for non-repudiation purposes and to facilitate third-party notarisation of electronic correspondence. S/MIMEv3 (section 4.4.5) is the de-facto standard for secure e-mail.

5.4 Secure Single Sign-On Most organizations require users to remember multiple passwords in order to access disparate applications and systems. Each of the applications has different password rules and protects user’s passwords differently. A user required to remember a different password for each system is likely to write them down or choose passwords that are easy to remember, yet inherently insecure. If the same password is permitted for use on each of the systems, an attacker need only compromise the weakest system in order to effectively compromise all of the systems. In either case, the user is likely to forget these passwords periodically, necessitating the laborious process of re-setting the user’s password on each, or a subset, of the systems. PKI-based authentication can be used in a secure single sign-on capacity, where users use their PKI credentials to log on to the various applications and systems. Users are required to remember a single, strong password that is adequately protected. In the event of a user forgetting their password, access to each of the applications and systems could be restored by recovering the user’s digital credentials. Likewise, if the user were to depart the organization, their access to the systems could be blocked by revoking their digital credentials.

5.5 Trusted Computing A trusted platform (TP) is a computing platform that has a trusted component, probably in the form of built-in hardware, and uses this to create a foundation of trust for software processes112. This trusted component ensures that only authorized applications are running on the system and no unauthorized changes have been made to the system. This has the effect of mitigating malicious code such as viruses and trojan horses. A PKI is required to take full advantage of trusted platform properties. It provides evidence about the integrity of a platform to third parties with which the user wishes to conduct business.

5.6 Virtual Private Networks Organizations, in an effort to cut telecommunication costs, are increasingly relying on public networks such as the Internet. Unfortunately, information travelling over these networks is at risk unless precautions are taken to protect it. VPNs are an increasingly popular way to protect sensitive information travelling over insecure networks. They can be used for remote access by telecommuters, to secure data exchange between satellite offices, to establish an extranet for customers and suppliers, etc. VPNs provide a secure tunnel between two entities by encrypting all of the information travelling between them. Although a VPN can be established without a PKI, a PKI is required in order for it to scale. If for example, an organization wished to establish a VPN between two routers they would require a single shared secret. If the organization had three routers they would need three shared secrets, with four routers they would require six such secrets, etc. With a PKI, each user or device is issued with digital credentials that are used to authenticate it to other users and devices in the trust domain. If a user or device is compromised the CA merely has to revoke its digital credentials to remove it permanently from the trusted network. IPSec (section 4.4.1) is the de-facto standard for VPNs.

112 [PEA03] p.5



5.7 Web Security Web security refers to the encrypted link between Web browsers and servers. This link is secured using TLS (section 4.4.6). In order to establish this link the Web server needs to authenticate itself to the Web browser. This is accomplished through the use of digital certificates; a server certificate retained by the Web server and a corresponding CA certificate stored in the Web browser. Once this secure link has been established, the user is required to enter a username and password in order to authenticate to the Web server and access user-specific Web content. Provided the Web browser has a digital certificate of its own, TLS supports mutual authentication, where both parties authenticate to one another. In this scenario, the Web server is then able to use the user’s certificate information to identify the user and provide user-specific Web content. A third scenario involves the use of a zero-footprint java PKI client to improve the authentication process and add additional functionality such as file encryption and non-repudiation. In all three cases a CA, and consequently a PKI, is required to issue the digital certificates.

5.8 Wireless Communications The Wired Equivalent Privacy (WEP) protocol was an attempt by the wireless community to encrypt and provide authentication to 802.11b (IEEE standard) wireless communications. Unfortunately, in the spring of 2001 researchers at the University of California, Berkeley and at the University of Maryland determined that with enough wireless data packets an attacker could determine the keys used to encrypt the traffic. Since then this attack has been implemented and tools (AirSnort and WEPCrack) developed to facilitate it.113 Perhaps even more disconcerting is the fact that the majority of wireless implementations are being deployed without even WEP enabled. Until subsequent versions of 802.11 and WEP are secure, external security measures are absolutely critical. Almost no security is offered at the data link layer. It is safe to assume that if any wireless access points are placed inside a firewall on a corporate network, anyone within physical range of your wireless network can act as a legitimate user on that network.114

To remedy this situation, the IEEE has decided that a new security standard, known as 802.1x, should be added to future generations of 802.1. Using a standard known as EAP (Extensible Authentication Protocol), 802.1x operates so that upon first attempting to connect to an access point, the mobile device will be restricted to sending data only to a dedicated “authentication” server. Only after the mobile user has been cleared by this server as a legitimate user will the mobile device be able to hook into the enterprise network. … Under the 802.1x standards networks can employ identity verification using digital certificates (known as EAP-TLS). When these certificates are created under a PKI infrastructure, they provide the same degree of security, flexibility and ease of management as with VPN overlay with enhanced identification through digital identities.115

5.9 Workflow Many electronic documents, such as contracts, expense forms, non-disclosure agreements, etc. need to be printed so that the relevant parties can sign them. Once signed, these documents must be shipped to the interested parties, stored for a period of time, and later disposed of. This process is not only time consuming but costly as well. A PKI provides the underlying infrastructure to digitally sign electronic documents and provide non-repudiation so that a party cannot later deny having signed the document. It also facilitates the process of securely transmitting, storing and disposing of records.

113 Interim patches for WEP have since been approved by the IEEE that purport to rectify these security deficiencies. 114 [SWA03] p.48 115 [ENT02-03] p.10



6.0 Interoperability Considerations

6.1 Overview The largest single inhibitor to the widespread adoption of this technology has been the lack of interoperability among products from multiple vendors. Standards have been somewhat ineffective in most cases as they allowed too much vendor interpretation and have not kept pace with product development functionality. DND and GoC have attempted to minimize interoperability problems by standardizing on the Entrust suite of products. In such a homogeneous environment the issue of interoperability between PKI domains would seem to be a moot point.116 While PKI interoperability between federal departments may have been simplified in the short-term, it is likely to get increasingly complex in the not-too-distant future. As domestic PKI implementations mature and expand in scope, there will be increasing pressure to include outside agencies, allies and trading partners. In a military context this could be used to facilitate NATO and NORAD commitments, multinational exercises, coalition operations and daily communications with our allies. In any case, communications between allied countries will result in heterogeneous PKI environments that will require considerable expertise to facilitate in a timely manner. According to a PKI Forum white paper [PKI01-2] there are three areas that need to be considered in order to achieve interoperability between PKI domains:

• Legal Considerations – Legal considerations include the acceptance of digital signatures in a multi-jurisdictional environment, issues associated with responsibilities and liability, and legal notice.

• Policy Considerations – Policy considerations encompass non-technical details, such as business

relationships, necessary to establish relationships between PKI domains.

• Technical Considerations – Technical considerations include non-business issues such as component functionality, protocols, data structures, etc.

While all three areas of interoperability are important and worthy of further research, the DRDC PKI Laboratory will focus on the technical considerations needed to achieve interoperability between PKI domains. According to another PKI Forum white paper [PKI01-1] there are three major technical interoperability areas:

• Component-Level Interoperability • Application-Level Interoperability • Inter-Domain Interoperability

These three technical interoperability areas, which are illustrated in Figure 9, will each be examined in some detail.

116 Given that DND has chosen to standardize on the Microsoft Windows 2000 platform, which includes integrated PKI functionality, there is no guarantee that Entrust will remain the only PKI vendor within the department.



Application-Level

ValidationAuthority

DirectoryServices

TimestampServer

RegistrationAuthority

CertificationAuthority

CryptographicEngine

Applications

CryptographicEngine

Applications



Component-Level

Inter-Domain

End EntityEnd Entity

Application-Level

ValidationAuthority

DirectoryServices

TimestampServer



CryptographicEngine

Applications

CryptographicEngine

Applications



Component-Level

Inter-Domain

End EntityEnd Entity

Figure 9 - Technical Interoperability Areas

6.2 Component-level Interoperability Component-Level Interoperability governs the interactions between components in a single PKI domain. In the past, all PKI components would need to be provided by a single vendor in order to interoperate. With the advent of common algorithms, message/certificate formats and protocols there exists the possibility of using best-of-breed components from multiple vendors. It is apparent that component-level interoperability has not advanced to the state where any PKI component from one vendor can be swapped out with the same component from another vendor. While this may hold true for some PKI components (Directory, Validation Authority, etc.) it likely does not for others. Although vendors may have standardized on algorithms, protocols, certificate formats, message formats, etc. they have not standardized on component functionality. 6.2.1 CA & RA CA to RA interoperability between PKI services would enable an RA from one PKI vendor to be able to request a certificate from a CA of another vendor. In practice the detailed interaction between RAs and CAs has been proprietary to particular PKI vendors, though components of the interaction may be standards based. There are mixed views in the industry regarding the market demand for such



interoperability. Scenarios have been quoted whereby a devolved RA within an organisation would wish to request certificates from multiple CAs without requiring separate RA systems.117 6.2.2 VAs, Directory Services & Timestamp Servers Directory services, Validation Authorities and to a lesser extent Timestamp Servers offer an opportunity for true component-level interoperability. In each case the server performs well defined functions and communicates with other components via a standard protocol. 6.2.3 End Entities Assuming that the client-side software is generic certificate-aware software such as Web browsers and e-mail clients, the issue that arises is the interoperability of digital credentials. If the digital credentials are stored in a standardized software format (e.g. PKCS#12) or hardware format (e.g. PKCS#11 compliant smart card) then the possibility for interoperability greatly increases. 6.2.4 XKMS Depending on how you look at it Component-Level Interoperability will either become more complicated or will be simplified through the introduction of XKMS. At the client level XKMS will let applications delegate the retrieval, parsing and validation of X.509 digital certificates to trusted servers, thereby reducing the PKI-enabled business logic that must be installed on clients. However, XKMS will require retrofitting clients to support new standards such as Simple Object Access Protocol (SOAP) and Web Services Description Language.118 Although requiring additional development these standards should ultimately facilitate client interoperability. At the server level XKMS defines two principal new infrastructure components, Registration Servers and Assertion Servers, which support all traditional PKI functions but do so through exchange of standardized XML-based messages.119

6.3 Application-level Interoperability Application-Level Interoperability governs the interaction between two end-entities of a PKI in a single domain. It is dependent as much on communications protocol interoperability as it is on the PKI services utilized by the application. These PKI services include certificate formats, certificate status, algorithms, data encapsulation, etc. Suitable applications for testing PKI interoperability include:

• IPSec VPNs • S/MIME e-mail • TLS Web browser to server communications • Wireless (EAP-TLS) communications • XML-based Web services

117 [PKIC01-03] p.5 118 [KOB01] p.3 119 [KOB01] p.3



6.4 Inter-Domain Interoperability Inter-Domain Interoperability governs the interaction between distinct PKI domains. As one would expect, it encompasses aspects of Component-Level Interoperability and Application-Level Interoperability, as well as inter-domain trust relationships. In addition the following issues must also be addressed:

• A method for establishing trust relationships between the PKI domains is required • Appropriate PKI-related information in one domain must be made available to the other, and vice

versa (as applicable based on the associated trust relationship) • Each PKI domain must agree to adhere to certain policies (e.g., what a given certificate is to be

used for), and each PKI needs to have mechanisms in place to enforce adherence to the agreed-upon policies120

6.4.1 Trust Relationships Trust relationships between PKI domains are usually (PGP is an exception, see Note – PGP Trust Model) established using cross-certification. The process of cross-certification involves one CA issuing a certificate to its counterpart CA and, in the case of mutual cross-certification, this process is reciprocated. This process can either be accomplished online or offline. Online cross-certification uses secure protocols to enable real-time interaction between the two CAs. Offline cross-certification does not require real-time interaction between the two CAs. It is used when online cross-certification is not supported or when communications restrictions, such as firewalls or offline CAs, preclude direct communications between the CAs. Note – PGP Trust Model PGP operates on a different trust model than other products discussed in the preceding sections. Previous products are based on an hierarchical model of trust in which a CA is the central trusted authority within some domain for processing requests to issue keys, and for signing, publishing and revoking certificates. The trust in the CA derives from the policies and procedures under which it operates and the fact that the procedures are subject to audit. In PGP, by contrast, there is no central trusted authority comparable to a CA and no domain of trust governed by published policies and procedures. Instead, individual users generate their own public and private key pairs, and publish their public key on selected PGP key servers. PGP adopts a web model of trust in which any user or users can sign another PGP user’s public key certificate. A certificate is only valid to another user if the relying party recognizes the validator as a trusted introducer. In other words, no central authority is responsible for certifying that a public key can be trusted. Another feature of the PGP trust model is that trust is transitive. A user will trust another user’s certificate if it has been signed by someone that the user trusts. That is, Fred will trust a certificate from someone he doesn’t know because Joe, whom Fred knows and trusts, signed that person’s certificate. Finally, in PGP there is no mechanism for revoking certificates once they have expired or because of a possible key compromise. It is up to the individual users to announce to others that a particular certificate should no longer be trusted.121 In order for disparate CAs to cross-certify they must each support a common standard in each of the following four areas:

• Certificate Format – The format and contents of the certificate must be standardised. Although in the case of X.509v3 certificates the use of non-critical extensions is usually ignored by PKIs other than the originating one. (see Note – PGP Certificate Format)

120 [PKI01-01] p.5 121 [LAM01] p.13



• Message Format – Cross-certification message formats must be standardised. These include PKCS#7, PKCS#10, Certificate Request Message Format (CRMF) and Certificate Message Syntax (CMS).

• Message Transfer Protocol – Cross-certification message transfer protocols must be standardised.

These include Certificate Management Messages (CMC) over CMS specification and Certificate Management Protocol (CMP).

• Transport Protocol – The transport protocol used to carry cross-certification messages must be

standardised. These include S/MIME for CMC and TCP, HTTP, SMTP/MIME, etc. for CMP. Note – PGP Certificate Format X.509 certificates and PGP certificates (often called PGP keys, for historic reasons) differ in several syntactic ways: • They use different data formats to encode the elements of the certificate. • An X.509 certificate contains exactly one public key, whereas a PGP certificate commonly contains at least two public keys—one for signing and one for encrypting. • An X.509 certificate contains exactly one certification, usually not a self-signed certification. On the other hand, a PGP certificate contains a collection of certifications, usually at least one self-certification and one third-party certification.122 The two most popular means of achieving cross-certification, and in all likelihood the two that will be used initially in the DRDC PKI Laboratory, are as follows:

• CMP Cross-Certification – CMP cross-certification is an online form of cross-certification that consists of a CRMF request, a CMP response and uses TCP as the transport protocol.

• Manual Cross-Certification – Manual cross-certification is an offline form of cross-certification

that consists of a PKCS#10 request, a CMS/PKCS#7 response and uses a floppy disc or e-mail as the transport protocol.

Note – PGP Interoperability Although PGP is not capable of cross-certification with other PKIs, it is possible to enable X.509 features in PGP. PGP can create a certificate request for an X.509 CA from keys it manages. However, before PGP can create a certificate request it needs to know what sort of CA it will be creating it for. This involves selecting the manufacturer of the CA, providing the URL of the CA, providing the URL for revocation information and importing the root certificate for that CA. 6.4.2 Information Sharing In order for two disparate PKI domains to interoperate, PKI information, specifically user public encryption certificates, CRLs, CA certificates, cross-certificates and Authority Revocation Lists (ARLs) must be shared between domains. This can be accomplished a number of different ways:

122 [PGP02] p.2



• Border Repository – Each PKI domain replicates the pertinent PKI information to a border repository located outside of the corporate firewall.

• Chaining/Referrals – The two PKI domains establish either chaining agreements, in the case of

X.500 directories, or cross-references, in the case of LDAP directories, between their respective repositories. In the case of X.500 directories, the necessary certificate information is passed from one directory to the other using X.500 Directory System Protocol (DSP). In the case of LDAP directories, the initial directory provides a reference of the other directory to the client. The client, which must be capable of understanding referrals, must then retrieve the necessary certificate information from the second directory.

• Direct Directory Access – Each PKI domain provides direct access to its directory by the end users

in the other domain. This solution requires that PKI clients are aware of the use of multiple repositories.

• Manual – PKI information is shared by users manually using e-mail or diskette.

• Protocol – PKI information is shared as part of the protocol exchange. For example, user public

verification certificates are automatically sent as part of the S/MIME protocol.

• Replication – Each PKI domain replicates the necessary PKI information to the other domain’s repository using LDUP (LDAPv3 Duplication/Replication/Update Protocol).

• Shared Repository – Each PKI domain publishes or replicates the necessary PKI information to a

shared repository. End users in each PKI domain then access this shared repository for all PKI information.

• Validation Authority – In order for an end user to validate a certificate from a user in another PKI

domain he must retrieve the corresponding CRL, validate the CRL and then search the CRL. CRL distribution points simplify this process considerably by breaking up monolithic CRLs into manageable chunks but they are not supported by all vendors. In either case, depending on the information sharing method used, there is no guarantee that the CRL information has not changed since it was last published. Validation authorities use a protocol called OCSP to provide real-time revocation information directly to end-users.

• Virtual Directory – Each PKI domain maintains the necessary PKI information in their own

repository. Using meta-directory technology this information is shared with the other PKI domain, giving the impression of a single virtual directory.

In order to greatly simplify the process, interoperability efforts of the past have used either a shared repository or a virtual directory for information sharing. While both approaches facilitate interoperability efforts they do not necessarily represent the most realistic scenario. Chaining/referrals, likely between border repositories, although more complicated to initially establish, are in many ways easier to maintain (and eventually dissolve) and consequently represent a more realistic approach to information sharing. Validation authorities offer a scalable mechanism to share real-time revocation information between PKI domains. 6.4.3 Policy Enforcement There are several extensions that can be populated within a given certificate or cross-certificate in order to convey and control policies between PKI domains. These extensions can be used to convey policy equivalencies between two separate PKI domains (applies to cross-certification only), policy constraints which can be used to prevent the undesirable (or unacceptable) cascading of trust from one domain to another, etc.



• Name Constraints – can be used to specify one or more permissible name space(s) associated with

subjects in the foreign PKI domain (e.g. finance department) • Policy Constraints – can be used to limit the use of certificates issued to subjects in the foreign

PKI domain and/or to prohibit policy mappings • Path Length Constraints – used to limit the number of cross-certificates in the certificate path123

6.5 Interoperability Lab Initially a PKI domain based on each product, including its associated directory, will be established. Once the PKI domain has been established an end entity will make a certificate request. Provided that everything has been configured correctly the certificate request will be approved (either automatically or manually) and the certificate issued. It should become quickly apparent from the relative success of this operation whether or not the PKI is working as it should. The next step necessary to achieve basic PKI lab interoperability is to either chain the corresponding directories together or include the appropriate cross-references within the directories to facilitate the sharing of PKI information. Once this has been successfully accomplished, cross-certification can occur between each of the CAs, using either online or offline methods. At this point the Validation Authority will need to be implemented. Not only will agreements between each of the CAs and the VA need to be established, but the appropriate client-side and server-side software will need to be installed. After the successful implementation of each of these steps, we will have achieved basic interoperability and will be ready to conduct more advanced interoperability testing secure in the knowledge that the lab setup/configuration is not the limiting factor. The only way to verify these assumptions is to choose a suitable application capable of testing all three facets of interoperability. S/MIME e-mail has been selected as the sole application in almost every PKI interoperability trial. This is not a coincidence. S/MIME is well understood, easy to setup and consequently an ideal test application to validate the DRDC PKI Laboratory before more challenging interoperability efforts are pursued. This interoperability test would examine the ability of a limited number of S/MIMEv3-compliant e-mail clients to successfully send and receive S/MIME encrypted and digitally signed e-mail to one another, as well as their ability to validate the digitally signed e-mail. An extremely limited number of S/MIMEv3-compliant e-mail clients will be used due to the fact that we are testing PKI interoperability and not e-mail client interoperability. By minimizing the number of S/MIMEv3- compliant e-mail clients we greatly simplify the interoperability test and maximize our chances of success.

123 [PKI01-2] p.4



7.0 Vulnerability Considerations

7.1 Overview The purpose of investigating the security and vulnerability of PKI products is to identify potential weaknesses and vulnerabilities of particular PKI implementations and configurations. Ultimately the results of this work will be used to assist DND and the Government of Canada to better secure their PKIs. PKI security and vulnerability issues can be divided into two basic classes:

• Security and vulnerability of the cryptographic services • Security and vulnerability of the infrastructure providing the services

The first class addresses the strength and vulnerabilities of the cryptographic algorithms. These issues are addressed primarily by the evaluation and certification process of national security agencies such as the Canadian Communications Security Establishment (CSE) and the U.S. National Security Agency (NSA). Therefore the PKI laboratory investigations will not address this class of security issues. The second class of issues, dealing with the security and vulnerabilities of the public key infrastructure, is the principal focus of the lab investigations. Even though the cryptographic mechanisms and implementations may be sound, a PKI includes many additional software and hardware components, as well as policies and procedures, which must work together to provide the necessary security and levels of assurance. It is primarily in the interactions among these components that the potential exists to compromise the security of the PKI.124 While a great deal of publicly available research has been conducted into the security of cryptographic algorithms, considerably less has been conducted on the subject of the vulnerability of the underlying infrastructure (see Note – PKI Vulnerability Research). Any work in this area has likely been conducted by the PKI vendors themselves, who have not been forthcoming in making it available for public consumption. While ‘security through obscurity’ is anathema in the world of cryptography, where algorithms are published and then scrutinized for years, it seems to be embraced by PKI vendors who are less than forthcoming in sharing their vulnerability research. Any valid examination of the vulnerabilities of commercial PKI implementations must start with a properly configured and validated PKI implementation. It is for this reason that we will use the Entrust subnet, which is implemented in a high availability, hardened architecture, as the basis for vulnerability testing. Only by employing accepted best practices and then attempting to compromise the implementation, using the latest security tools and techniques, in conjunction with in-depth knowledge of PKI, can meaningful research be conducted. This section on Vulnerability Considerations will detail information operations tools and techniques, and examine how they can be adopted for the PKI environment. In order to better examine the vulnerabilities of commercial PKI implementations the second class of issues, dealing with the security and vulnerabilities of the PKI itself, has been sub-divided into four parts. They are as follows:

• Component Security • Inter-Component Communications • Key & Certificate Management • User Registration & Administration

124 [LAM01] p.16



Note – PKI Vulnerability Research Two papers of note in this area are 50 Ways to Defeat Your PKI and Other Cryptosystems ([COH99]) and Ten Risks of PKI: What You’re Not Being Told about Public Key Infrastructure ([ELL]). Both papers, which are highly theoretical in nature, were released at the height of PKI hype and consequently received a great deal of publicity. [COH99] composed a list of fifty theoretical attack scenarios, most, if not all of which, could be mitigated through the use of a properly configured and validated PKI. [ELL] was a more reasoned approach to countering the hype surrounding PKI. The arguments raised in this particular paper are almost as relevant today as the day they were written.

7.2 Information Operations While there appear to be few, if any, techniques and tools specifically targeted at commercial PKI implementations, that doesn’t mean that generic techniques and tools cannot be adopted for just this purpose. This section will examine both a methodology and the corresponding tools which can be used to compromise computer systems. Subsequent sections will examine their applicability to PKI implementations. It is important to remember that attacks on information systems typically take advantage of poorly configured systems with known vulnerabilities. Commercial PKI systems on the other hand, have been specifically engineered with security being the prime consideration. When properly implemented, the components are located on hardened operating systems, communicate using secured protocols and are situated behind extremely restrictive firewalls. 7.2.1 Techniques The techniques listed below are ones typically employed by hackers to compromise computer systems. They are based on the hacker methodology detailed in [SCA01].

• Footprinting – Footprinting is basically used to determine the scope of the attack. Upon completion of this phase of the operation, the attacker will have a specific range of domain names, network blocks, and individual IP addresses for targeted systems. In a commercial PKI implementation the component systems are generally well understood. In such a case footprinting would be used to determine the range of IP addresses on which the PKI components could be found.

• Scanning – Scanning is used to determine the susceptibility of the systems to attack. Using ping

sweeps, port scans and automated discovery tools, the attacker can determine not only the systems, but the specific ports, available to launch information operations against. In a commercial PKI implementation accessible PKI components and their available ports are well documented. In such a case, scanning would be used to validate this information.

• Enumeration – Enumeration is used to list points of attack. These include user accounts and

resource shares. A properly implemented PKI will utilize system hardening, where superfluous services and extraneous user accounts have been disabled. In such a case, enumeration would be used to list valid PKI accounts and user shares to target.

• Gaining Access – Gaining access leverages the vulnerabilities identified in the scanning and

enumeration phases to get a foothold on the target system. While theoretically it should be difficult to gain access to properly configured PKI systems, not only should this be attempted but it should be deemed successful at some point in order to study how the compromise of one component affects the integrity of the system as a whole.



• Escalating Privilege – Escalating Privilege is used to leverage the initial foothold in order to

compromise the system entirely. This technique is quite relevant to a PKI implementation. For example, can an attacker who manages to gain access to a subset of users through the registration authority, leverage this privilege to gain access to additional users or even security policies.

• Pilfering – Pilfering is the process of stealing information from the compromised system in order

to identify system vulnerabilities or additional target systems. In a PKI implementation, an attacker could pilfer key files, initialization files, etc. in order to better target trusted PKI systems.

• Covering Tracks – Covering Tracks is used to erase any evidence of the attacker’s presence on

the compromised system. This is typically accomplished by disabling/altering auditing, clearing the event log and hiding files. In a PKI implementation the complexity of this step would likely be compounded due to the use of protected audit logs.

• Creating Back Doors – Creating back doors is the process of introducing vulnerabilities into the

compromised system that will be used to facilitate future access.

• Denial of Service (DoS) – Denial of Service attacks are used to disrupt or deny service to legitimate users. In a PKI implementation DoS attacks are likely to attack critical systems involved in day-to-day operations, such as the Directory, rather than systems involved in specific processes, such as the CA or the RA. PKI vulnerability research would need to examine the possibility of developing DoS attacks specifically engineered for PKI components and consequently how to protect components from these same attacks.

7.2.2 Tools The tools listed below are typically used by hackers to compromise computer systems.

• Automated Discovery Tools – Automated Discovery Tools are all-inclusive network mapping tools that integrate ping, trace route, port scanning and operating system capabilities into a single package. Ping performs ping sweeps on a range of IP addresses in order to determine which targeted systems are alive. Port scans scan common ports on targeted systems in order to identify active ports.

• Packet Sniffer – A packet sniffer simply scans all traffic on the network looking for specific data

such as user names and passwords either travelling in the clear or weakly protected.

• Password Crackers – Most systems are protected by passwords chosen by security-ignorant users who tire of having to remember three or four different passwords that are constantly required to change. To make it easier on themselves the users choose easy to remember passwords that are typically based on English words, family names or birthdays. Password crackers methodically try variations of all the most popular passwords including the entire English dictionary.

• Keystroke Monitor – A keystroke monitor is an hardware device that sits between the keyboard

and the computer. It stores all keystrokes typed into the computer until such time as the buffer is full. At this time it either overwrites the old data or stops recording the keystrokes.

• Denial of Service Tools – There are a great many tools that attempt to flood equipment such as

routers or systems themselves with vast quantities of data or improperly formatted packets in the hopes of rendering them unavailable for the duration of the attack. In the case of a distributed denial of service attack the attack originates from multiple, usually compromised, systems.



i. Bandwidth Consumption – This DoS attack consumes all available bandwidth to a particular network.

ii. Resource Starvation – This DoS attack consumes all available system resources (CPU

utilization, memory, etc.).

iii. Programming Flaws – This DoS attack leverages programming flaws in applications, operating systems, embedded logic chips, etc.

iv. Routing and DNS Attacks – This DoS attack manipulates routing table entries to deny

service to legitimate systems or networks.

• Session Hijacking – This tool allows the insertion of a TCP/IP packet into a stream, thereby enabling commands to be executed on the remote host.

• Trojan Horses – A Trojan horse is simply a program that hibernates until such time as it is

activated and performs its undesirable action. It can be a program on its own or an undesirable feature of legitimate code. Once activated the Trojan horse can be used to steal passwords, delete files or perform other insidious actions.

• Viruses – A virus is a self-replicating fragment of code that attaches itself to other pieces of code

in order to get executed and unleash its nefarious payload.

• Worms – A worm is code that propagates itself over networks. This differs from viruses which rely on users to do their work for them. The worm propagates itself by using known holes in poorly configured systems.

7.3 Component Security A PKI is a collection of highly specialized systems that work in harmony to provide cryptographic services to a large number of end-entities, be it users or hardware devices. If any of its component parts are compromised this will have ramifications throughout the PKI. Depending on the component compromised and the extent to which it has been compromised the consequences can range from unfortunate (client compromise) to unrecoverable (CA compromise). It is for this reason that great pains are taken to ensure that PKI components are adequately protected. System hardening and the use of firewalls are two of the general mechanisms used to achieve this. System Hardening – System hardening is the removal of superfluous operating system functionality and user accounts in order to better secure the underlying operating system. “Computer hackers are aware of the multitude of vulnerabilities associated with standard configurations. They will exploit them at every opportunity to cause damage to systems and organizations. System hardening reduces this system vulnerability to the extent possible, and maximizes the amount of security protection. It provides a PKI with a last line of defence from a network-based attack. Hardening usually involves, but is not limited to, the following activities:

• Removing all unnecessary hardware (e.g. modems, network interface cards) • Installing minimum configurations • Changing all default passwords • Disabling or removing all unnecessary user accounts • Disabling login as ‘root’ • Renaming the administrator account(s)



• Establishing a dummy administrator account target • Removing all unnecessary diagnostic services • Disabling all unnecessary network services such as telnet and ftp • Disabling all unnecessary protocols (e.g. routable network protocols such as PPTP) • Disabling all unnecessary applications (e.g. send mail, chat, Hyper Terminal) • Removing all unnecessary simple TCP/IP services (e.g. coho, daytime, and quote of the day) • Eliminating all unnecessary shares • Closing all unnecessary ports • Applying all appropriate security-related vendor service packs, patches and hot-fixes • Reviewing and carefully set all security configuration settings appropriate for the environment

in which the computer will be operating125 Firewalls – Firewalls are used to block all unauthorized access to PKI component systems. Only specific protocols on specific ports are allowed to access protected systems. 7.3.1 Certification Authority The foundation of trust within a PKI originates from the Certification Authority. It is the entity that is ultimately responsible for the integrity of the public key certificates that are used in all of the secure transactions within the organization. The CA’s private signing key must be protected against malicious intent, inadvertent errors and system failures. A hardware security module (HSM) facilitates this task by storing the private signing key in a validated cryptographic module complete with physical tamper protection, attack resistance and trusted path access. While the CA should be protected to the maximum extent possible disconnecting it from the network entirely is not a realistic proposition given that it is required to publish certificate revocation information periodically. Given the critical nature of the CA’s secret key, tight physical security is necessary to maintain the integrity of the CA. Thus, the host that houses the CA should be kept offline and, if possible, be surrounded by an “air-gap” so that no physical (or wireless) network connections can be made.126 7.3.2 Client Securing the client workstation is one of, if not the most, challenging aspect of component security. Efforts to harden the operating system and install anti-virus/personal firewall software can be rendered ineffective if the user fails to update the virus signature files, installs unapproved third-party software and carelessly opens e-mail attachments. While hardware tokens, such as smart cards, offer a mobile platform in which to transport private keys they are of little use if the client workstation has been completely compromised. One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don’t own a secure computing system with physical access controls, TEMPEST shielding, “air wall” network security, and other protections; you store your private key on a conventional computer. There, it’s subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it’s protected by a password, how hard is it to guess that password? If your key is stored on a smart card, how attack-resistant is the card? [Most are very weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn’t intent to sign?127 125 [ENT02-4] p.2 126 [HON00] p.3 127 [ELL]



7.3.3 Directory Within a PKI the Directory is used as a repository for a variety of certificate information. Fortunately, certificates are inherently protected, against modification or substitution, through the use of digital signatures. However, the majority of transactions involving cryptographic services require the Directory to be available in order to retrieve the necessary information from the Directory and ultimately complete the transaction. It is for this reason that the Directory is considered a critical component within the PKI when continuous availability must be guaranteed.

• Master Directory – The Master Directory is a trusted copy of the Directory that is only accessible by trusted systems. It replicates all or a subset of its information to geographically dispersed Shadow Directories. If it were to be corrupted then this corrupted information would be disseminated globally.

• Shadow Directory – Shadow Directories are replications of all or a part of the Master Directory.

In the case of PKI they are used to provide users with 24x7 access to user public encryption certificates and CRLs. Since they themselves do not replicate, the corruption of one Shadow Directory does not affect the others.

By making the directory server unavailable, an intruder can effectively disable the PKI application’s ability to authenticate its users, which can result in the use of a fallback (and often less secure) authentication mechanism and, consequently, in the compromise of the data being secured by the application.128 7.3.4 Registration Authority Depending on the PKI implementation, RAs serve different roles. These range from automated servers that approve certificate requests by comparing user provided information against an existing database to manually operated workstations where users are pre-approved for certificate issuance. Component security for RAs is highly dependent on its functionality.

7.4 Inter-Component Security A PKI consists of a distributed architecture in which systems must communicate with one another in a timely and secure manner. These inter-component communications are, for the most part, based on existing and emerging standards (e.g. PKIX-CMP, LDAPv3, XKMS, etc.) that should be hardened against attack. Possible attacks against protocols include replay attacks, man-in-the-middle attacks, etc.

7.5 Key & Certificate Management The core functionality provided by a PKI is transparent key and certificate management. This includes key generation, key storage, key distribution, certificate issuance, key usage, certificate validation, key update, key expiry, key recovery, certificate revocation and key & certificate archival. Each and every segment of key and certificate management must be 100% secure. Any compromise of a segment of key and certificate management can potentially compromise the entire PKI.

128 [HON00] p.5



7.6 User Registration & Administration The user registration process and subsequent administration of the user is fraught with the potential for abuse. There is no need for an attacker to break the symmetric algorithm protecting sensitive communications if he can just recover the cryptographic key necessary to decrypt the protected communications. Security is a chain; it’s only as strong as the weakest link. The security of any CA-based system is based on many links and they’re not all cryptographic. People are involved.129

129 [ELL]



8.0 PKI Lab Architecture

8.1 Overview The purpose of the DRDC Ottawa PKI laboratory is to provide a facility to develop expertise in PKI technology, and to investigate PKI security mechanisms and other related issues relevant to the deployment of a PKI in both the military environment and the wider government environment. This laboratory will evolve as the PKI technologies and the investigations require.130 Figure 10 illustrates the initial PKI laboratory architecture. It consists of ten separate subnets; an administrative subnet, seven PKI subnets, a validation subnet (Valicert) and a vulnerability subnet. Each of the PKI subnets includes a certification authority/registration authority, a directory server and a single system running client applications. The Entrust subnet, which will serve as the basis for vulnerability testing, is implemented in a high availability, hardened architecture. The subnets are interconnected via a router.

VulnerabilitySubnet

AdministrativeSubnet

Router

VulnerabilitySubnet

AdministrativeSubnet

Router

Figure 10 - DRDC PKI Lab Architecture

Directory software has been paired with PKI software in each of the seven subnets with the intent of minimizing component-level interoperability problems. All software has previously been tested together with the exception of the RSA Keon Certificate Authority and the Nexor Directory. The seven PKI subnets are listed in Table 17.

130 [LAM01] p.7



Subnet PKI Directory Baltimore Subnet i Baltimore UniCERT Siemens DirX Entrust Subnet ii Entrust Authority Security Manager Critical Path Directory Server IDX Subnet iii IDX-PKI / OpenSSL OpenLDAP Microsoft Subnet iv Microsoft Windows 2000 PKI Microsoft Active Directory PGP Subnet v PGP Enterprise Novell eDirectory RSA Subnet vi RSA Keon Certificate Authority Nexor Directory Sun Subnet vii Sun One Certificate Server Sun One Directory Server

Table 17 – PKI Subnets

Notes

i. Siemens DirX has been successfully tested with Baltimore UniCERT. Furthermore, it should not require schema modifications as Baltimore can publish directly to default schemas.

ii. Critical Path Directory Server has been extensively tested with Entrust Authority Security

Manager. Furthermore, Entrust re-sells the Critical Path Directory Server as part of its PKI solution.

iii. IDX-PKI, OpenSSL and OpenLDAP are all open source software. Furthermore, IDX-PKI has

been tested specifically with OpenSSL and OpenLDAP.

iv. Both Microsoft Windows 2000 PKI and Active Directory are integrated components of Microsoft Windows 2000 Server.

v. Novell eDirectory has been tested to work with PGP Enterprise as a replacement for the PGP

KeyServer. It can be used both to store keys of individual users, as well as serve as the deployment platform for configuration updates.

vi. Nexor Directory has not been tested for use with RSA Keon Certificate Authority. However,

nothing precludes these products successfully working together.

vii. Sun One Certificate Server and Directory Server have been engineered to work together.

8.2 Administrative Subnet The administrative subnet architecture is illustrated in Figure 11.

Router

Hub

172.17.1.1

AdministrativeConsole

TapeBackup

Router

Hub

172.17.1.1

AdministrativeConsole

TapeBackup

Figure 11 - Administrative Subnet Architecture



The administrative subnet system requirements are listed in Table 18.

System Name AdminCon Processor Pentium 650MHz RAM 256Mb Hard Drive 2Gb Network Card(s) 1 Subnet Administrative IP Address 172.17.1.1 Software Windows 2000 Professional Symantec Ghost Corporate

Edition 7.5 • Ghost Console • GhostCast Server

Microsoft Internet Explorer 6.0 Hardware Tape Backup 2 Monitors Keyboard Mouse

Table 18 – Administrative Subnet System Requirements

8.2.1 Symantec Ghost Installing and configuring a large number of systems with a common operating system and a number of common applications is a time consuming and tedious effort. A better approach is to install the base operating system and the required applications on a model system and then replicate this configuration. Ideally, the model system would represent the standard hardware configuration in use. Once the system has been successfully configured an image of the hard drive would be made. This image would be used reproduce this particular configuration the required number of times. The process would be repeated for each different configuration within the lab environment. Not only would this deployment method initially save time, it would facilitate future deployment and/or system recovery. The lab environment will be used for different research projects. Once a given research project has completed the lab needs to be restored to a known state so that it can be used for subsequent projects. Each system will need to be restored, ideally remotely, from a stable image file. During the research project itself, systems will need to be modified/re-configured. If these systems are not periodically backed up throughout the project then these changes may be lost, causing potentially irreparable harm to the research project. The basis of Symantec Ghost is a cloning function that creates an image file containing all of the information required to recreate a complete disk or partition. Image files store and compress images of model system configurations (computers with all of the necessary software installed and configured), or create backup copies of complete drives or partitions. The image file is cloned onto one or more partitions or disk, replacing existing data.131 The primary components of Symantec Ghost Corporate Edition 7.5 are as follows:

• Symantec Ghost Console – Symantec Ghost Console is a Windows server-based application for remote management of cloning operations, post-cloning configuration, and AutoInstall configuration.132

131 [SYM02] p.19 132 [SYM02] p.26



• Symantec Ghost Console Client – The console client is comprised of a Windows agent and a Ghost partition. The client is installed on all Windows 9x/NT/XP/Me/2000 computers, enabling remote control from the Symantec Ghost Console. The Windows agent is an unobtrusive application that lets the computer start from the Ghost partition when required by the Console. The Ghost partition is a hidden DOS partition installed on the computer that lets the Symantec executable perform cloning operations.133

• Symantec Ghost GhostCast Server – The GhostCast Server delivers an image file to multiple

computers simultaneously using a single IP GhostCast transmission. This minimizes the impact on network bandwidth. The GhostCast Server sends or receives images to or from one or more computers rather than accessing a mapped network drive, which is slower than GhostCasting.134

8.2.2 Virtual Network Computing (VNC) In a lab environment, with many workstations and servers, it is not feasible, from both a cost and space perspective, to have a monitor, keyboard and mouse for each system. In the past DRDC has resolved this problem through the use of KVM (Keyboard Video Mouse) switches. Using a KVM switch enables multiple systems to share a single keyboard, monitor and mouse. The user cycles between systems by pressing the appropriate buttons on the front of the switch. Remote display software can be used as an alternative to the KVM switch. This software, consisting of a client and server component, allows a user at a workstation to centrally control any of the systems on the lab network. Commercially available versions of this software, such as Symantec’s PCanywhere, while full-featured tend to be quite expensive. Fortunately there is a freeware version, produced by AT&T Labs, that is widely deployed. VNC “is a remote display system which allows you to view a computing ‘desktop’ environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures.”135 The server component of VNC is available for Windows 2000 (WinVNC) and Linux (VNC server for X). The windows version is capable of running as a service. The client component can either consist of a platform specific viewer or merely a Web browser.

8.2.3 Operating System Builds As discussed previously, Symatec Ghost enables you to build a model system complete with operating system and applications, and then replicate this configuration to other systems with identical requirements. Given that the PKI Laboratory will initially have twelve Microsoft Windows 2000 Server-based systems and ten Microsoft Windows 2000 Professional-based systems this type of functionality is a necessity. Since the software is unavailable for the Linux platform, the four Red Hat Linux 8.0 Professional and two Red Hat Linux 8.0 Personal systems will each need to be individually configured. The Windows Server build and Windows Workstation build will be configured as follows: 133 [SYM02] p.27 134 [SYM02] p.28 135 http://www.uk.research.att.com/vnc



Windows Server Build Windows Workstation Build Windows 2000 Server Windows 2000 Professional Windows 2000 Service Packs136 Windows 2000 Service Packs Internet Information Server 5.0 Internet Explorer 6.0 Symantec Ghost Console Client Outlook 2002 WinVNV Symantec Ghost Console Client WinVNC

Note – Windows 2000 • Windows 2000 Professional – Windows 2000 Professional is the Windows operating system for

business desktop and laptop systems. It is used to run software applications, connect to Internet and Intranet sites, and access files, printers, and network resources.137 Windows 2000 Professional will serve as the base operating system for the majority of client systems within the Lab.

• Windows 2000 Server – Windows 2000 Server integrates standards-based directory, Web,

application, network, file and print services with powerful end-to-end management and reliability to provide the best foundation for integrating your business with the Internet.138 Windows 2000 Server will serve as the base operating system for the majority of servers within the Lab. The operating system includes Active Directory, Certificate Services and Internet Information Services (IIS) 5.0.

• Windows 2000 Advanced Server – Windows 2000 Advanced Server contains all the functionality and

reliability of the standard version of Windows 2000 Server, plus additional features for applications that require higher levels of scalability and availability.139 Windows 2000 Advanced Server will serve as the base operating system for the Entrust Security Manager and CriticalPath Master Directory. The operating system includes Cluster Service.

8.2.4 Domain Name Service (DNS) Given that each subnet will be acting for the most part autonomously it was decided against implementing a common Domain Name Server. Within each subnet a HOSTS file containing IP addresses and domain names of each of the systems can be used if warranted. The exception to this is the Microsoft subnet where the implementation of DNS is likely to occur as the implementation of a domain controller is a prerequisite for Active Directory. Note: I would like to see a DNS as a goal in the PKI lab setup even if it is not done immediately. Eventually DNS security issues can be investigated.

8.3 Baltimore Subnet The Baltimore subnet architecture is illustrated in Figure 12.

136 At the time of writing, the latest service pack for Microsoft Windows 2000 was SP3. It can be downloaded at http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/default.asp 137 http://www.microsoft.com/windows2000/professional/evaluation/business/overview/default.asp 138 http://www.microsoft.com/windows2000/server/evaluation/business/review/datasheet.asp 139 http://www.microsoft.com/windows2000/advancedserver/evaluation/business/overview/advanced.asp



Router

172.16.1.1

Hub

172.16.1.2 172.16.1.3

ClientCA/RA X.500

Directory

Router

172.16.1.1

Hub

172.16.1.2 172.16.1.3

ClientCA/RA X.500

Directory Figure 12 - Baltimore Subnet Architecture

The Baltimore subnet system requirements are listed in Table 19.

System Name BaltClient BaltCA Siemens Processor Pentium 650MHz Pentium III – 1GHz Pentium 1GHz RAM 256Mb 512Mb 512Mb Hard Drive 2Gb 1Gb 1Gb Network Card(s)

1 1 1

Subnet Baltimore Baltimore Baltimore IP Address 172.16.1.1 172.16.1.2 172.16.1.3 Software Windows 2000

Professional Windows 2000 Server Windows 2000 Server

Internet Explorer 6.0 Oracle 8.1.7140 Siemens DirX Microsoft Outlook

2002 Microsoft Internet Information Server v5.0 (with Servlet_Exec v4.1.1)

Symantec Ghost Console Client


Baltimore UniCERT 5.0.1

• CA • CAO • Publisher • RA • WebRAO • RAeXchange • Protocol

Handlers141

WinVNC

WinVNC Symantec Ghost Console Client

Valicert Validator WinVNC Valicert Publisher

Table 19 – Baltimore Subnet System Requirements

140 The Baltimore Database Wizard will be used to create the required tables and user accounts in the Oracle database. 141 The Protocol Handlers required will be dependent on the modules undertaken. Initially, the WebPH will be required.



8.4 Entrust Subnet Given that the Entrust CA will be used for vulnerability testing, in addition to interoperability testing, it must be implemented in as secure a manner as possible given the obvious budgetary constraints endemic to a lab environment. For this reason physical security will not be addressed. The Entrust subnet is illustrated in Figure 13.

Router

172.16.2.1

172.16.2.2

136.16.1.1

172.16.2.9

172.16.2.5172.16.2.6

172.16.2.8

172.16.2.7

172.16.2.4172.16.2.3

136.16.1.2

Hub

Hub

Firewalls

ShadowDirectoryClient

RA

#2

#1

Primary CA/Master Directory

Backup CA/Master Directory

SharedRAID

Array

Ethernet Heartbeat Link

Router

172.16.2.1

172.16.2.2

136.16.1.1

172.16.2.9

172.16.2.5172.16.2.6

172.16.2.8

172.16.2.7

172.16.2.4172.16.2.3

136.16.1.2

Hub

Hub

Firewalls

ShadowDirectoryClient

RA

#2

#1

Primary CA/Master Directory

Backup CA/Master Directory

SharedRAID

Array

Ethernet Heartbeat Link

Figure 13 - Entrust Subnet Architecture

The Entrust subnet contains two firewalls. The first firewall restricts access to the subnet as a whole while the second is used to specifically protect the CA and the Master Directory. Access to the Master Directory should be restricted to trusted systems. All other systems requiring directory access will access the Shadow Directory. All systems in the Entrust subnet will be appropriately hardened. Good papers on the subject of system hardening include the following:

• Entrust PKI Deployment Methodology Annex F – System Hardening • Installing and Securing a New Windows 2000 System142 • Security Operations Guide for Windows 2000 Server143

Both Entrust Authority Security Manager and the Master Directory will be implemented in a high availability configuration using cluster software. In this architecture both the primary and backup node are connected to a shared RAID array and to one another using an Ethernet heartbeat monitor. The backup node monitors specific services on the primary node, ready to takeover if a failure is detected.

This is accomplished using clustering software. Before installing Entrust/CriticalPath, the cluster should be configured according to the cluster software documentation. The cluster software used is dependent on the platform and in the past has included SUN Cluster, HP MC/ServiceGuard, Veritas Cluster and Legato Cluster. Given that the lab high availability requirements are fairly limited it was decided to use the cluster service native to Windows 2000 Advanced Server. Cluster service does fail-over but not load balancing. For more information refer to:

142 http://www.microsoft.com/technet/security/tools/tools/w2knew.asp 143 http://www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp



• Entrust PKI Deployment Methodology Annex D – High Availability • Step-by-Step Guide to Installing Cluster Service144 • Windows 2000 Clustering Technologies: Cluster Service Architecture White Paper

The system requirements for the Entrust subnet are listed in Table 20.

System Name Firewall1 EntrClient ShadCPDir EntrRA Processor Pentium 650MHz Pentium 650MHz Pentium 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb 256Mb Hard Drive 650Mb 2Gb 2Gb 2Gb Network Card(s) 2 1 1 1 Subnet Entrust Entrust Entrust Entrust IP Address(es) 172.16.2.1 172.16.2.3 172.16.2.4 172.16.2.5

172.16.2.2 Software Red Hat Linux 8.0

Professional Windows 2000 Professional

Windows 2000 Server

Windows 2000 Professional

CheckPoint Firewall-1 Small Office

Entrust Entelligence Desktop Manager 6.0 & Mail Plug-in

CriticalPath Directory Server 4.0

Entrust Authority Security Manager Administration 6.0

VNC server for X Valicert Validator Symantec Ghost Console Client


Internet Explorer 6.0 WinVNC WinVNC Outlook 2002 Symantec Ghost Console

Client

WinVNC Hardware Datakey Smart Card

Reader Datakey Smart

Card Reader

System Name Firewall2 EntrPCADir EntrBCADir Processor Pentium 650MHz Pentium 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb Hard Drive 650Mb 2Gb 2Gb Network Card(s) 2 2 2 Subnet Entrust Entrust Entrust IP Address(es) 172.16.2.6 172.16.2.8 172.16.2.9 172.16.2.7 136.16.1.1 136.16.1.2 Software Red Hat Linux 8.0

Professional Windows 2000 Advanced Server

Windows 2000 Advanced Server

CheckPoint Firewall-1 Small Office

Entrust Authority Security Manager 6.0

Entrust Authority Security Manager 6.0

VNC server for X CriticalPath Directory

Server 4.0 CriticalPath Directory Server 4.0

VA Publisher VA Publisher Symantec Ghost Console

Client Symantec Ghost Console Client

WinVNC WinVNC

Table 20 – Entrust Subnet System Requirements Note – Entrust 7.0

144 http://www.microsoft.com/windows2000/techinfo/planning/server/clustersteps.asp



The Entrust PKI will be used, along with other PKI products, for interoperability testing and will serve, at least initially, as the sole PKI for vulnerability testing. Given its prominence within the PKI Lab every effort should be made to ensure that the latest version of this software is used in order to maximize the benefits of the resulting research to GoC departments. Entrust 7.0 software is scheduled for release in April 2003. It will consist initially of Entrust Authority Security Manager 7.0 and Entelligence Security Provider 7.0, with additional Entrust products, such as Entrust TruePass 7.0, to follow.

8.5 IDX-PKI Subnet The IDX-PKI subnet architecture is illustrated in Figure 14.

Router

172.16.3.1

Hub

172.16.3.2 172.16.3.3

ClientCA/RA LDAP

Directory

Router

172.16.3.1

Hub

172.16.3.2 172.16.3.3

ClientCA/RA LDAP

Directory

Figure 14 - IDX-PKI Subnet Architecture

The IDX-PKI subnet system requirements are listed in Table 21.

System Name IDXClient IDXCA OpenLDAP Processor Pentium 650MHz Pentium 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb Hard Drive 650Mb 650Mb 650Mb Network Card(s) 1 1 1 Subnet IDX-PKI IDX-PKI IDX-PKI IP Address 172.16.3.1 172.16.3.2 172.16.3.3 Software Red Hat Linux 8.0

Personal Red Hat Linux 8.0 Professional

Red Hat Linux 8.0 Professional

Netscape 7.01 (including Navigator & Mail)

IDX-PKI 1.6.1 • Certification

Authority Module • Registration

Authority Module • Renewal Module • End Entity Module

Open LDAP 2.1.12

OpenSSL 0.9.7a VNC server for X Apache Web Server 2.0.44 VNC server for X Netscape Navigator 7.01 VNC server for X

Table 21 – IDX-PKI Subnet System Requirements



8.6 Microsoft Subnet The Microsoft subnet architecture is illustrated in Figure 15.

Router

172.16.4.1

Hub

172.16.4.2 172.16.4.3

ClientCA/RA LDAP

Directory

172.16.4.4

MailServer

Router

172.16.4.1

Hub

172.16.4.2 172.16.4.3

ClientCA/RA LDAP

Directory

172.16.4.4

MailServer

Figure 15 - Microsoft Subnet Architecture

The Microsoft subnet system requirements are listed in Table 22.

System Name MicrClient MicrCA ActiveDir MicrExch Processor 650MHz Pentium 650MHz Pentium 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb 256Mb Hard Drive 2Gb 2Gb 2Gb 2Gb Network Card(s) 1 1 1 1 Subnet Microsoft Microsoft Microsoft Microsoft IP Address 172.16.4.1 172.16.4.2 172.16.4.3 172.16.4.4 Software Windows 2000

Professional Windows 2000 Server

• CA Certificate Service

• CA Administration (MMC Snap-in Tools)

Windows 2000 Server • Active Directory

Server145

Windows 2000 Server

Internet Explorer 6.0 Internet Information Server 5.0


Microsoft Exchange 2000 Server

Valicert Validator VA Publisher WinVNC Symantec Ghost Console Client

Outlook 2002 Symantec Ghost Console Client

WinVNC


WinVNC

WinVNC

Table 22 – Microsoft Subnet System Requirements

145 Microsoft Active Directory runs only on a domain controller. For this reason the ActiveDir server will also act as the primary domain controller for the Microsoft Subnet.



8.7 PGP Subnet The PGP subnet architecture is illustrated in Figure 16.

Router

172.16.6.1

Hub

172.16.6.2 172.16.6.3

Client LDAPDirectory

Router

172.16.6.1

Hub

172.16.6.2 172.16.6.3

Client Admin LDAPDirectory

Router

172.16.6.1

Hub

172.16.6.2 172.16.6.3

Client LDAPDirectory

Router

172.16.6.1

Hub

172.16.6.2 172.16.6.3

Client Admin LDAPDirectory

Figure 16 - PGP Subnet Architecture

The PGP subnet system requirements are listed in Table 23.

System Name PGPClient PGPAdmin NovelleDir Processor 650MHz Pentium 650MHz Pentium 650MHz Pentium RAM 256Mb 256Mb 256Mb Hard Drive 2Gb 2Gb 2Gb Network Card(s) 1 1 1 Subnet PGP PGP PGP IP Address 172.16.6.1 172.16.6.2 172.16.6.3 Software Windows 2000

Professional Windows 2000 Professional Windows 2000 Server

PGP Enterprise 8.0 • PGP Mail • PGP Disk

PGP Enterprise 8.0 • PGP Admin

Novell eDirectory

Internet Explorer 6.0 Symantec Ghost Console Client


Outlook 2002 WinVNC WinVNC Symantec Ghost Console

Client

WinVNC

Table 23 – PGP Subnet System Requirements



8.8 RSA Subnet The RSA subnet architecture is illustrated in Figure 17.

Router

172.16.7.1

Hub

172.16.7.2 172.16.7.3

ClientCA X.500

Directory

Router

172.16.7.1

Hub

172.16.7.2 172.16.7.3

ClientCA X.500

Directory

Figure 17 - RSA Subnet Architecture

The RSA subnet system requirements are listed in Table 24.

System Name RSAClient RSACA NexorDir Processor Pentium 650Mhz Pentium III 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb Hard Drive 2Gb 2Gb 2Gb Network Card(s) 1 1 1 Subnet RSA RSA RSA IP Address 172.16.7.1 172.16.7.2 172.16.7.3 Software Windows 2000


Internet Explorer 6.0 RSA Keon CA • Admin Server • Enrolment Server • Logging Server

Nexor Directory 5.0

Valicert Validator VA Publisher Symantec Ghost Console Client


WinVNC


WinVNC

WinVNC

Table 24 – RSA Subnet System Requirements



8.9 Sun Subnet The Sun subnet architecture is illustrated in Figure 18.

Router

172.16.5.1

Hub

172.16.5.2 172.165.3

ClientCM/RM LDAP

Directory

Router

172.16.5.1

Hub

172.16.5.2 172.165.3

ClientCM/RM LDAP

Directory

Figure 18 - Sun Subnet Architecture

The Sun subnet system requirements are listed in Table 25.

System Name SunClient SunCS SunDir Processor Pentium 650MHz Pentium III 650MHz Pentium 650MHz RAM 256Mb 256Mb 256Mb Hard Drive 2Gb 2Gb 2Gb Network Card(s) 1 1 1 Subnet Sun Sun Sun IP Address 172.16.5.1 172.16.5.2 172.16.5.3 Software Windows 2000


Internet Explorer 6.0 Sun One Certificate Server 4.7

• Certificate Manager

• Registration Manager

• Data Recovery Manager

• Plug-in Modules

Sun One Directory Server 5.1

Valicert Validator Internet Information Server 5.0



WinVNC


VA Publisher

WinVNC WinVNC

Table 25 – Sun Subnet System Requirements



8.10 Valicert Subnet The Valicert subnet architecture is illustrated in Figure 19.

Router

Hub

172.16.8.1

ValidationAuthority

Router

Hub

172.16.8.1

ValidationAuthority

Figure 19 - Valicert Subnet Architecture

The Valicert subnet system requirements are listed in Table 26.

System Name ValicertVA Processor Pentium 650MHz RAM 256Mb Hard Drive 2Gb Network Card(s) 1 Subnet Valicert IP Address 172.16.8.1 Software Windows 2000 Server Valicert Enterprise VA

4.2.2 Valicert VA

Administration Server Internet Information

Server 5.0 Internet Explorer 6.0 Symantec Ghost Console

Client WinVNC

Table 26 – Valicert Subnet System Requirements

8.11 Vulnerability Subnet Vulnerability tools are available in two forms; commercial and freeware. Commercial vulnerability tools are produced for organizations wishing to test their own in-house security. They tend to be well-documented, have a nice GUI interface and are usually available for Windows-based systems. Hacker tools, on the other hand, are freely available to everyone. They tend to be poorly documented, with limited GUI interface and are generally available for Unix-based systems (specifically Linux). In order to accommodate both sets of tools the vulnerability subnet will consist of two workstations. The first will be a Windows 2000-based system which will be equipped with best-of-breed commercial vulnerability tools. The second will be a Linux-based system which will be equipped with best-of-breed freeware vulnerability tools. The Vulnerability subnet architecture is illustrated in Figure 20.



Router

Hub

172.17.2.1

WindowsClient

LinuxClient

172.17.2.2

Router

Hub

172.17.2.1

WindowsClient

LinuxClient

172.17.2.2

Figure 20 - Vulnerability Subnet Architecture

The Vulnerability subnet system requirements are listed in Table 27.

System Name VulWClnt VulLClnt Processor Pentium 650Mhz Pentium 650MHz RAM 256Mb 256Mb Hard Drive 2Gb 650Mb Network Card(s) 1 1 Subnet Vulnerability Vulnerability IP Address 172.17.2.1 172.17.2.2 Software Windows 2000

Professional Red Hat Linux 8.0 Personal

ISS Internet Scanner 6.2.1 i

Nmap 3.00 iii

ISS System Scanner 4.2 ii Tcpdump 3.7 iv Internet Explorer 6.0 dsniff 2.3 v Symantec Ghost Console

Client John the Ripper 1.6 vi

WinVNC Netscape Navigator 7.01 VNC server for X

Table 27 – Vulnerability Subnet System Requirements

Notes

i. The Internet Scanner application, an integrated part of Internet Security Systems' security management platform, provides comprehensive network vulnerability assessment for measuring online security risks. Internet Scanner performs scheduled and selective probes of communication services, operating systems, applications and routers to uncover and report systems vulnerabilities that might be open to attack146.

ii. The System Scanner application, an integrated part of Internet Security Systems' security management platform, ensures policy compliance and detects vulnerabilities that leave servers open to compromise. System Scanner measures, manages and enforces security

146 http://www.iss.net/products_services/enterprise_protection/vulnerability_assessment/scanner_internet.php



policies across a wide range of operating systems through a unique, server-to-network view of critical systems and servers.147

iii. Nmap ("Network Mapper") is an open source utility for network exploration or security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (ports) they are offering, what operating system (and OS version) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics.148

iv. A powerful tool for network monitoring and data acquisition This program allows you to dump the traffic on a network. It can be used to print out the headers of packets on a network interface that matches a given expression. You can use this tool to track down network problems, to detect "ping attacks" or to monitor the network activities.149

v. dsniff is a collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.150

vi. John the Ripper is a fast password cracker, currently available for many flavors of Unix (11 are officially supported, not counting different architectures), DOS, Win32, BeOS, and OpenVMS. Its primary purpose is to detect weak Unix passwords. Besides several crypt(3) password hash types most commonly found on various Unix flavors, supported out of the box are Kerberos AFS and Windows NT/2000/XP LM hashes, plus several more with contributed patches.151

147 http://www.iss.net/products_services/enterprise_protection/vulnerability_assessment/scanner_system.php 148 http://www.insecure.org/nmap/ 149 http://www.insecure.org/tools.html 150 http://naughty.monkey.org/~dugsong/dsniff/ 151 http://www.openwall.com/john/



9.0 Project Plan 9.1 Overview The DRDC PKI Laboratory project is quite large and complex so the project plan has been sub-divided into four distinct phases in order to facilitate planning and budgeting. The four phases are as follows:

• Phase 1 – Acquisition, Base Configuration & Networking: All hardware and software will be acquired as part of Phase 1 so that subsequent phases can proceed without interruption. Phase 1 also includes configuration and networking components.

• Phase 2 – PKI Configuration: This phase will involve the implementation and configuration of

both the PKI and the directory software.

• Phase 3 – Cross-Certification & Validation: Prior to cross-certification being able to occur the directories will need to be linked using either chaining or cross-references. This phase also includes the implementation and configuration of the Validation Authority.

• Phase 4 - Test Application: Phase 4 includes implementing the messaging infrastructure, as well as

performing the S/MIMEv3 interoperability testing.



9.2 Proposed Timetable & Activities 9.2.1 Phase 1 – Acquisition, Base Configuration & Networking Task Duration

(hours) Start Finish Ownership

Acquisition

Acquire hardware (Table 32) 15.0 Day 1 Day 2 DRDC Acquire software (Table 33) 22.5 Day 3 Day 5 DRDC Establish necessary contracts for professional services for phases 2, 3 & 4

15.0 Day 6 Day 7 DRDC

(Assume 4 weeks to acquire hardware & software) Day 8 Day 35 Base Configuration & Networking

Build racks 3.75 Day 36 Day 36 DRDC Install router 1.0 Day 36 Day 36 DRDC Install workstation and server hardware 15.0 Day 37 Day 38 DRDC Install hubs and cabling 7.5 Day 39 Day 39 DRDC Configure router 7.5 Day 40 Day 40 DRDC Windows Server Build

• Build Windows Server • Ghost Windows Server • Replicate Windows Servers (11)


Windows Workstation Build • Build Windows Workstation • Ghost Windows Workstation • Replicate Windows Workstations

(9)


Install Linux Servers (4) 15.0 Day 45 Day 46 DRDC Install Linux Workstations (2) 7.5 Day 47 Day 47 DRDC Configure systems for networking (28) 15.0 Day 48 Day 49 DRDC Test networking 7.5 Day 50 Day 50 DRDC Test VNC 7.5 Day 51 Day 51 DRDC Test Ghost (remote backup & restore) 7.5 Day 52 Day 52 DRDC

TOTAL HOURS 177.5 DRDC Total Hours 177.5

Table 28 – Phase 1 Timetable & Activities



9.2.2 Phase 2 – PKI Configuration Task Duration


Baltimore Subnet Siemens

Install Siemens DirX 6.0 7.5 Day 1 Day 1 Consultant BaltCA

Install Oracle 8.1.7 7.5 Day 2 Day 2 Consultant Install Servlet_Exec 4.1.1 3.75 Day 3 Day 3 Consultant Install/Configure Baltimore UniCERT 5.0.1

• CA • CAO • Publisher • RA • WebRAO • RA eXchange • Protocol Handlers

15.0 Day 3 Day 5 Consultant

Test Baltimore Subnet 3.75 Day 5 Day 5 Consultant Entrust Subnet EntrPCADir

Install Windows 2000 Advanced Server 7.5 Day 6 Day 6 Consultant Harden Windows 2000 Advanced Server 7.5 Day 7 Day 7 Consultant Install shared array 7.5 Day 8 Day 8 Consultant Install/configure Ethernet heartbeat link 7.5 Day 9 Day 9 Consultant Install Critical Path Directory Server

• DSA on shared array • LDAP on shared array • PERL5 on local disk • Make Entrust schema modifications


Install Entrust Authority Security Manager • Informix on shared array • Security Manager on shared array • Configure to use Automatic

Services Logon • Configure Security Manager


EntrBCADir Install Windows 2000 Advanced Server 3.75 Day 13 Day 13 Consultant Harden Windows 2000 Advanced Server 3.75 Day 13 Day 13 Consultant Install Critical Path Directory Server

• PERL5 on local disk 3.75 Day 14 Day 14 Consultant

Install Entrust Authority Security Manager • Configure to use Automatic

Services Logon


Install/configure Microsoft Cluster Service 22.5 Day 15 Day 17 Consultant ShadCPDir

Harden Windows 2000 Server 3.75 Day 18 Day 18 Consultant Install Critical Path Directory Server 6.5 Day 18 Day 19 Consultant Make Entrust Schema Modifications 1.0 Day 19 Day 19 Consultant Establish Directory Shadowing Agreements 7.5 Day 20 Day 20 Consultant

EntrRA



Task Duration (hours)

Start Finish Ownership

Harden Windows 2000 Professional 3.75 Day 21 Day 21 Consultant Install Datakey Smart Card Reader 1.0 Day 21 Day 21 Consultant Install Entrust Authority Security Manager Administration 6.0


EntrClient Harden Windows 2000 Professional 3.75 Day 21 Day 22 Consultant Install Datakey Smart Card Reader 1.0 Day 22 Day 22 Consultant Install Entrust Desktop Designer 6.0 1.0 Day 22 Day 22 Consultant Design Entrust client build 1.5 Day 22 Day 22 Consultant Install Entrust Entelligence Desktop Manager 6.0


Firewall1 Harden Red Hat Linux 8.0 Professional 7.5 Day 23 Day 23 Consultant Install Checkpoint Firewall-1 Small Office 3.75 Day 24 Day 24 Consultant Configure Firewall-1 3.75 Day 24 Day 24 Consultant

Firewall2 Harden Red Hat Linux 8.0 Professional 3.75 Day 25 Day 25 Consultant Install Checkpoint Firewall-1 Small Office 3.75 Day 25 Day 25 Consultant Configure Firewall-1 3.75 Day 26 Day 26 Consultant

Test Entrust Subnet 7.5 Day 26 Day 27 Consultant

IDX-PKI Subnet OpenLDAP

Update OpenLDAP operating system with required Open Source Libraries (e.g. OpenSSL, Berkeley DB, etc.)


Install OpenLDAP 2.1.12 3.75 Day 28 Day 28 Consultant IDXCA

Update IDXCA operating system with required Open Source packages (including OpenSSL 0.9.7a)


Install IDX-PKI 1.6.1 • CA Module • RA Module • Renewal Module • End Entity Module


Test IDX-PKI Subnet 3.75 Day 30 Day 30 Consultant

Microsoft Subnet ActiveDir

Install Active Directory Server 7.5 Day 31 Day 31 Consultant MicrCA

Install CA Certificate Service 7.5 Day 32 Day 32 Consultant Install CA Administration 3.75 Day 33 Day 33 Consultant Configure CA Certificate Service 3.75 Day 33 Day 33 Consultant

Test Microsoft Subnet 3.75 Day 34 Day 34 Consultant

PGP Subnet NoveDir

Install Novell eDirectory 7.5 Day 35 Day 35 Consultant PGP Admin

Install PGP Admin 1.0 Day 36 Day 36 Consultant





Configure PGP 1.75 Day 36 Day 36 Consultant PGPClient

Install PGP Mail & Disk 1.0 Day 36 Day 36 Consultant Test PGP Subnet 3.75 Day 36 Day 36 Consultant RSA Subnet NexorDir

Install Nexor Directory 7.5 Day 37 Day 37 Consultant Make any required schema modifications 3.75 Day 38 Day 38 Consultant

RSACA Install/Configure RSA Keon CA

• Administration Server • Enrolment Server • Logging Server


Test RSA Subnet 3.75 Day 40 Day 40 Consultant Sun Subnet SunDir

Install Sun One Directory Server 7.5 Day 41 Day 41 Consultant SunCA

Install/Configure Sun One Certificate Server 15.0 Day 42 Day 43 Consultant Test Sun Subnet 3.75 Day 44 Day 44 Consultant Vulnerability Subnet VulWClnt

Install ISS System Scanner 3.75 Day 45 Day 45 Consultant Install ISS Internet Scanner 3.75 Day 45 Day 45 Consultant

VulLClnt Install Misc. Hacker Tools 7.5 Day 46 Day 46 Consultant

Report – PKI Configuration 30.0 Day 47 Day 50 Consultant

TOTAL HOURS 359.0 Consultant Total Hours 359.0




9.2.3 Phase 3 – Cross-Certification & Validation Task Duration


Establish Chaining Agreements

Critical Path Directory Server (ShadCPDir) & Siemens DirX (Siemens)


Critical Path Directory Server (ShadCPDir) & Nexor Directory (NexorDir)


Siemens DirX (Siemens) & Nexor Directory (NexorDir)


Establish Cross-References

Critical Path Directory Server (ShadCPDir) & OpenLDAP (OpenLDAP)


Critical Path Directory Server (ShadCPDir) & Microsoft 2000 Active Directory (ActiveDir)


Critical Path Directory Server (ShadCPDir) & Novell eDirectory (NoveDir)


Critical Path Directory Server (ShadCPDir) & Sun One Directory Server (SunDir)


Siemens DirX (Siemens) & OpenLDAP (OpenLDAP)


Siemens DirX (Siemens) & Microsoft 2000 Active Directory (ActiveDir)


Siemens DirX (Siemens) & Novell eDirectory (NoveDir)


Siemens DirX (Siemens) & Sun One Directory Server (SunDir)


OpenLDAP (OpenLDAP) & Microsoft 2000 Active Directory (ActiveDir)


OpenLDAP (OpenLDAP) & Novell eDirectory (NoveDir)


OpenLDAP (OpenLDAP) & Nexor Directory (NexorDir)


OpenLDAP (OpenLDAP) & Sun One Directory Server (SunDir)


Microsoft 2000 Active Directory (ActiveDir) & Novell eDirectory (NoveDir)


Microsoft 2000 Active Directory (ActiveDir) & Nexor Directory (NexorDir)


Microsoft 2000 Active Directory (ActiveDir) & Sun One Directory Server (SunDir)


Novell eDirectory (NoveDir) & Nexor Directory (NexorDir)


Novell eDirectory (NoveDir) & Sun One Directory Server (SunDir)


Nexor Directory (NexorDir) & Sun One Directory Server (SunDir)


Establish Cross-Certification Agreements

Baltimore UniCERT & Entrust Authority 7.5 Day 13 Day 13 Consultant





Security Manager Baltimore UniCERT & IDX-PKI 7.5 Day 14 Day 14 Consultant Baltimore UniCERT & Microsoft Windows 2000 PKI


Baltimore UniCERT & PGP Enterprise 7.5 Day 16 Day 16 Consultant Baltimore UniCERT & RSA Keon 7.5 Day 17 Day 17 Consultant Baltimore UniCERT & Sun One Certificate Server


Entrust Authority Security Manager & IDX-PKI


Entrust Authority Security Manager & Microsoft Windows 2000 PKI


Entrust Authority Security Manager & PGP Enterprise


Entrust Authority Security Manager & RSA Keon


Entrust Authority Security Manager & Sun One Certificate Server


IDX-PKI & Microsoft Windows 2000 PKI 7.5 Day 24 Day 24 Consultant IDX-PKI & PGP Enterprise 7.5 Day 25 Day 25 Consultant IDX-PKI & RSA Keon 7.5 Day 26 Day 26 Consultant IDX-PKI & Sun One Certificate Server 7.5 Day 27 Day 27 Consultant Microsoft Windows 2000 PKI & PGP Enterprise


Microsoft Windows 2000 PKI & RSA Keon 7.5 Day 29 Day 29 Consultant Microsoft Windows 2000 PKI & Sun One Certificate Server


PGP Enterprise & RSA Keon 7.5 Day 31 Day 31 Consultant PGP Enterprise & Sun One Certificate Server 7.5 Day 32 Day 32 Consultant RSA Keon & Sun One Certificate Server 7.5 Day 33 Day 33 Consultant

Validation Install Valicert Enterprise VA 7.5 Day 34 Day 34 Consultant Install Valicert VA Administration Server 3.75 Day 35 Day 35 Consultant Configure Valicert Enterprise VA 3.75 Day 35 Day 35 Consultant Install/Configure VA Publisher on each CA (5)


Install/Configure VA Validator on each client (5)


Report – Cross-Certification & Validation 52.5 Day 39 Day 45 Consultant





9.2.4 Phase 4 –Test Application Task Duration


E-Mail Configuration MicrExch

Install/Configure Microsoft Exchange 2000 Server


Configure Outlook 2002 • BaltClient • EntrClient • MicrClient • PGPClient • RSAClient • SunClient

Configure Netscape Mail • IDXClient


Test lab e-mail 3.75 Day 2 Day 2 Consultant S/MIME Testing – Encryption (CRL)

Send encrypted message from BaltClient 3.75 Day 3 Day 3 Consultant Send encrypted message from EntrClient 3.75 Day 3 Day 3 Consultant Send encrypted message from IDXClient 3.75 Day 4 Day 4 Consultant Send encrypted message from MicrClient 3.75 Day 4 Day 4 Consultant Send encrypted message from PGPClient 3.75 Day 5 Day 5 Consultant Send encrypted message from RSAClient 3.75 Day 5 Day 5 Consultant Send encrypted message from SunClient 3.75 Day 6 Day 6 Consultant Assess Results 3.75 Day 6 Day 6 Consultant Troubleshoot 7.5 Day 7 Day 7 Consultant Re-send failed messages 3.75 Day 8 Day 8 Consultant

S/MIME Testing – Digital Signatures (CRL) Send digitally signed message from BaltClient


Send digitally signed message from EntrClient


Send digitally signed message from IDXClient


Send digitally signed message from MicrClient


Send digitally signed message from PGPClient


Send digitally signed message from RSAClient


Send digitally signed message from SunClient


Assess Results 3.75 Day 10 Day 10 Consultant Troubleshoot 7.5 Day 10 Day 11 Consultant Re-send failed messages 3.75 Day 11 Day 11 Consultant

S/MIME Testing – Encryption (OCSP) Send encrypted message from BaltClient 3.75 Day 12 Day 12 Consultant Send encrypted message from EntrClient 3.75 Day 12 Day 12 Consultant Send encrypted message from IDXClient 3.75 Day 13 Day 13 Consultant





Send encrypted message from MicrClient 3.75 Day 13 Day 13 Consultant Send encrypted message from PGPClient 3.75 Day 14 Day 14 Consultant Send encrypted message from RSAClient 3.75 Day 14 Day 14 Consultant Send encrypted message from SunClient 3.75 Day 15 Day 15 Consultant Assess Results 3.75 Day 15 Day 15 Consultant Troubleshoot 7.5 Day 16 Day 16 Consultant Re-send failed messages 3.75 Day 17 Day 17 Consultant

S/MIME Testing – Digital Signatures (OCSP) Send digitally signed message from BaltClient


Send digitally signed message from EntrClient


Send digitally signed message from IDXClient


Send digitally signed message from MicrClient


Send digitally signed message from PGPClient


Send digitally signed message from RSAClient


Send digitally signed message from SunClient



S/MIME Testing – Encryption & Digital Signatures (CRL/OCSP)

Send encrypted & digitally signed message from BaltClient


Send encrypted & digitally signed message from EntrClient


Send encrypted & digitally signed message from IDXClient


Send encrypted & digitally signed message from MicrClient


Send encrypted & digitally signed message from PGPClient


Send encrypted & digitally signed message from RSAClient


Send encrypted & digitally signed message from SunClient



S/MIME Testing - Revocation Revoke each user’s public encryption certificate


Re-perform S/MIME Testing – Encryption (CRL)






Re-perform S/MIME Testing – Encryption (OCSP)


Revoke each user’s public verification certificate


Re-perform S/MIME Testing – Digital Signatures (CRL)


Re-perform S/MIME Testing – Digital Signatures (OCSP)


Report – S/MIME Interoperability 52.5 Day 29 Day 35 Consultant





9.3 Cost Estimate The cost estimate for the DRDC PKI Laboratory will consist of hardware, software and professional services components. 9.3.1 Hardware There are considerable physical space constraints at the Information Operations Lab within DRDC Ottawa. While conventional desktop systems may be less expensive they take up considerably more room than rack-mounted systems. Given that the PKI Interoperability & Vulnerability Lab will consist of approximately 30 systems this must be factored into the decision making process. Laptops, although occupying considerably less space than conventional desktop systems, are considerably more expensive than even rack-mounted systems and are not meant to be stacked one on top of the other. Dell hardware was used for pricing estimates throughout this report. This is not meant to endorse Dell products and services in any way. Dell products were chosen due to the fact that pricing/product information was readily available (www.dell.ca). DRDC should purchase the required hardware from its preferred supplier. Annex B – Quoted Hardware contains product descriptions for the quoted hardware. Table 32 lists the anticipated hardware costs for the DRDC PKI Laboratory.

Hardware # Individual Price

Total Price

Datakey Smart Card Reader152 2 $0.00 $0.00 Hub 11 $95.00 $1045.00 Rack 2 $275.00 $550.00 RAID Array (rack-mounted) 1 $5384.00 $5384.00 Router – 10 port (rack-mounted)153 1 $10,000.00 $10,000.00 Server (rack-mounted) 20 $2438.00 $48,760.00 Tape Backup 1 $1350.00 $1350.00 Workstation (rack-mounted) 9 $1981.00 $17,829.00 Workstation (high-end with two monitors, keyboard & mouse)

1 $4105.00 $4105.00

TOTAL $89,023.00

Table 32 – Hardware List

152 DND has standardized on Datakey smart card readers. Two should be available within DRDC at no additional cost. 153 Router prices vary significantly depending on the vendor selected and the functionality included. The price listed is based on the Cisco 3640 router.



9.3.2 Software Table 33 lists the anticipated software costs for the DRDC PKI Laboratory. They do not include annual maintenance costs.

Software # of Copies Price / Copy Total Price Apache Web Server 2.0.44154 1 $0.00 $0.00 Baltimore UniCERT 5.0.1155 1 $18,000US $18,000US CheckPoint Firewall-1 Small Office 2 $450.00US $900.00US Critical Path Directory Server 4.0156 3 $0.00 $0.00 Entrust PKI 6.0 2 $0.00 $0.00 IDX-PKI 1.6.1 1 $0.00 $0.00 ISS Internet Scanner 6.2.1157 1 (10 IP

addresses) $999.00US $999.00US

ISS System Scanner 4.2158 1 $695.00US $695.00US Microsoft Exchange 2000 Server159 1 server / 7

users $699.00US + $67.00US/user

$1168.00US

Microsoft Internet Explorer 6.0 9 $0.00 $0.00 Microsoft Internet Information Server 5.0160 4 $0.00 $0.00 Microsoft Outlook 2002161 6 $0.00 $0.00 Microsoft Windows 2000 Advanced Server 2 $6026.00 $12,052.00 Microsoft Windows 2000 Professional 10 $484.00 $4840.00 Microsoft Windows 2000 Server 12 $1511.00 $18,132.00 Netscape 7.01 3 $0.00 $0.00 Nexor Directory 5.0162 1 $16,516.00 $16,516.00 Novell eDirectory 8.7 1-User License 1 server / 100

users $2US/user $200US

OpenLDAP 2.1.12 1 $0.00 $0.00 OpenSSL 0.9.7a 1 $0.00 $0.00 Oracle 8.1.7163 1 $475.00 $475.00 PGP Enterprise 8.0164 1 $260.00US $260.00US Red Hat Linux 8.0 Personal 2 $39.95US $79.90US Red Hat Linux 8.0 Professional 4 $149.95US $599.80US RSA Keon165 1 $5000.00US $5000.00US ServletExec v4.1.1166 1 $695.00US $695.00US

154 http://httpd.apache.org/download.cgi 155 The cost of the Baltimore UniCERT software was taken from a quote provided by John Bys, Baltimore Account Manager, on 22 January 2003. This quote can be seen in its entirety in Annex C. 156 It was assumed that the Critical Path Directory Server was included in the Entrust site license. 157 http://www.isp-planet.com/services/ids/iss.html 158 http://www.isp-planet.com/services/ids/iss.html 159 Microsoft Exchange 2000 Server costs $699US + $67US per device accessing the server. However, this price includes the rights for Microsoft Outlook. 160 Microsoft Internet Information Server 5.0 is included with Microsoft Windows 2000 Server. 161 The rights to Microsoft Outlook 2002 are included in the price of Microsoft Exchange 2000 Server. 162 The Nexor quote was provided by Pam Ferenbach, the Nexor Country Manager, on 28 February 2003. It is for their smallest directory amount (1000 entries). 163 Oracle Database Standard Edition – Named User Plus Perpetual (www.oracle.com) 164 This price is for a perpetual license. The annual cost is $125.00US. (www.pgp.com) 165 The RSA Keon quote was provided by Ray Campbell on 3 February 2003. It is for 25 users. 166 ServletExec is a Java-based Web application server that implements the Java Servlet API and JavaServer Pages (JSP) standards defined by Sun Microsystems. It can be purchased directly from New



Siemens DirX167 1 $7800.00 $7800.00 Sun One Certificate Server 4.7168 1 server / 10

users $7.95/user $79.50

Sun One Directory Server 5.1 1 server / 100 users

$3.18/user $318.00

Symantec Ghost Corporate Edition 7.5 23 desktops $32.09US/desktop $738.07US Valicert Enterprise VA 4.2.2169 1 $10,000US $10,000US Virtual Network Computing – WinVNC 23 $0.00 $0.00 Virtual Network Computing – VNC server for X

6 $0.00 $0.00

TOTAL $119,214.66

Table 33 – Software List 9.3.3 Professional Services It has been assumed that a part-time DRDC resource will be allocated to the PKI Interoperability & Vulnerability Lab in order to acquire the necessary hardware and software components, perform base configuration of the workstations and servers, perform networking and to manage the lab environment. This cost, although substantial, is not exclusive to the PKI Interoperability & Vulnerability Lab and as a result will not be included in its budget. It has also been assumed that DRDC will need the services of an outside consultant to perform the majority of the work in Modules 2, 3 and 4. Therefore, the cost estimate for professional services is as follows:

• Phase 1 177.5 hours @ $0.00/day = $0.00 • Phase 2 359.0 hours @ $850.00/day = $40,686.67 • Phase 3 337.5 hours @ $850.00/day = $38,250.00 • Phase 4 253.5 hours @ $850.00/day = $28,730.00

Atlanta Communications (www.newatlanta.com/servletexec/pricing.jsp). ServletExec is free for development, debugging and testing. 167 Annex C contains the complete Siemens quote provided by Erica Hughes on 29 January 2003. 168 Annex D contains the complete Sun One Certificate Server quote provided by Mike Fortier on 29 January 2003. 169 Annex E contains the complete Valicert quote provided by Joel Eaves, Valicert Sales Manager on 22 January 2003.



9.3.4 Summary The cost estimate for the initial PKI Interoperability & Vulnerability Lab setup and configuration is as follows:

Phase 1 • Hardware $89,023.00 • Software $119,214.66

Phase 2

• Professional Services $40,686.67

Phase 3 • Professional Services $38,250.00

Phase 4

• Professional Services $28,730.00

Sub-Total $315,904.33 10% Contingency Fund $31,590.43 TOTAL $347,494.76



10.0 Further Research

10.1 Overview Establishing the DRDC PKI Laboratory is just the first step. Meaningful PKI-related research can take place only after the lab has been fully configured. Further research will largely be dictated by DRDC customers and other DRDC projects, although research collaboration with other agencies is also quite likely. Initial research activities will focus on interoperability issues and the vulnerability of commercial PKI implementations. The Information Operations Group within DRDC – Ottawa will not be conducting PKI interoperability and vulnerability testing/research in isolation. Not only do they need to participate in relevant standards activities but they need to establish relationships with their counterparts in other agencies. Specifically, DRDC will need to track the proceedings in the IETF – PKIX working group, and to a lesser extent the XML Encryption, Key Management and Signature working groups within the World Wide Web Consortium. Furthermore, DRDC will need to establish formal relationships with NIST (including joining the PKI Technical Working Group) and their counterparts within DoD and CESG. Lastly, DRDC should monitor the developments within the OASIS PKI Technical Committee in order to assess the benefits of ultimately joining. This section outlines a number of specific research projects in these broad areas.

10.2 Interoperability Research Potential interoperability research activities are shown below under the three interoperability categories discussed in Section 5. 10.2.1 Component-Level Interoperability One area of particular interest in the component-level interoperability category is the universality of digital credentials. To what degree can credentials issued by one CA be used in an entirely distinct PKI environment? To rephrase this question in a real world context - to what extent would an American exchange officer be able to use his Common Access Card (CAC) in the Canadian Defence Electronic Messaging System (DEMS) environment? Aside from the obvious inter-domain interoperability issues, this scenario raises a number of component-level interoperability issues such as certificate format, common algorithms and hardware token interoperability to name but a few. 10.2.2 Application-Level Interoperability

• Wireless (EAP-TLS) – The PKI Lab could be utilized to test the ability of disparate clients and access points to establish EAP-TLS secured communications. In any case this research module has a great deal of synergy with current Information Operations research activities and would be largely dictated by the wireless within the Information Operations section.

• XKMS – The use of XKMS, XML digital signatures and XML encryption for Web services is an

exciting area of PKI interoperability that poses some unique challenges for vendors. While a number of PKI vendors have developed, or are in the process of developing, the necessary servers to enable Web services others have not. It will be interesting to see if these servers are PKI



independent, in that they are capable of fronting any PKI, or whether they are PKI specific (component-level interoperability). It will also be interesting to see the extent to which a user with credentials from one PKI domain can interact with XML-based Web servers in another PKI domain (application-level interoperability).

10.2.3 Inter-Domain Interoperability Policy enforcement (Section 5.4) is perhaps the least understood aspect of inter-domain interoperability. This is due in part to the fact that PKI implementations have not reached sufficient size to warrant the complexity of policy enforcement. Research examining the ability of disparate PKI products, both server and client components, to support policy enforcement would be of interest. It would also be worth examining the effectiveness of the three policy enforcement extensions to meet the needs of a variety of trust architectures.

10.3 Vulnerability Research

• Entrust 7.0 - Entrust Authority Security Manager 7.0 is scheduled for release in April 2003. There will likely be a lag between this release date and its adoption within DND and throughout the Government of Canada. It is during this period of time that DRDC should conduct extensive vulnerability testing of the Entrust product. This vulnerability testing should encompass each of the four categories discussed in Section 6.

• Workstation Security - Although hardware tokens (such as smart cards) go a long way in

providing a secure, tamper-resistant storage platform for users’ private keys, they do not entirely mitigate the threat of a workstation security compromise in a PKI environment. A compromised workstation will enable an attacker to steal passwords/PINs (to access their private keys, Windows 2000, etc.), documents in cleartext, screen shots and keyboard entries. The attacker could even get the unwitting user to provide access to classified resources and digitally sign fraudulent transactions. Further research needs to be undertaken to determine best workstation security practices for PKI environments. This research could also examine the effects of trusted computing initiatives such as the Trusted Computing Platform Alliance (TCPA) and Palladium (Microsoft) on PKI workstation security.

10.4 Related Research The PKI Laboratory can, and likely will, be used for research other than PKI interoperability and vulnerability. Examples of such likely research areas include:

• Privilege Management Infrastructure - DRDC has recently been sponsored by DDCEI for further research into the area of PMI for the purposes of caveat separation. Given that the initial effort in this area relied quite heavily on PKI services, it seems quite likely that further research into this area will require similar services. Since DND is standardizing on the Windows 2000 platform, it remains somewhat unclear whether Entrust will be used to provide these services or whether Windows 2000 Certificate Services will be used.

• Simple Certificate Enrolment Protocol (SCEP) – Although IPSec is commonly used to

secure communications between routers, the link is rarely established using digital certificates for authentication. While SCEP and PKCS#10 are both used by Certification Authorities to issue certificates to these devices, neither standard is capable of providing the key and certificate management capability required for large-scale implementations. Previous efforts



to incorporate this functionality in these hardware devices failed due to the complexity of the software and the memory/storage limitations of the routers.



11.0 References [ADA99] Understanding Public-Key Infrastructures – Concepts, Standards, and Deployment

Considerations, Carlisle Adams and Steve Lloyd, Macmillan Technical Publishing, 1999 [BAL02-1] UniCERT v5.0 Product Overview – Core Technology, Baltimore Technologies, 2002 [BAL02-2] Baltimore UniCERT Version 5.0 Product Overview, Baltimore Technologies, 2002 [BAL02-3] Baltimore UniCERT Core Version 5.0 – Installation Guide, Baltimore Technologies,

2002 [BAL02-4] Baltimore UniCERT Version 5.0 – Administrator’s Guide, Baltimore Technologies, 2002 [BCA01] Phase II Bridge Certification Authority Interoperability Demonstration Final Report,

A&N Associates, 9 Nov 2001 [CESG02] CESG Advanced Security Technologies, Secure Messaging and PKI Interoperability

Trial Final Report, Issue 1.2, 1 May 2002 [COH99] “50 Ways to Defeat Your PKI and Other Cryptosystems”, Dr. Fred Cohen, 1999 annual

CSI conference in Washington [DAL00] Windows 2000 PKI: Contender or Pretender?, Curtis E. Dalton, Network Magazine, 5

Oct 2000 [DEL99] Certificate Authority Root Key Protection: Recommended Practices, Deloitte & Touche,

July 1999 [DEL00] Best Practices: The Key to Ultimate Trust, June 2000, Deloitte & Touche LLP, Chrysalis-

ITS [ELL] Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure, Carl

Ellison and Bruce Schneier, www.counterpane.com/pki-risks-ft.txt [ENT99-1] An Introduction to the Windows 2000 Public-Key Infrastructure – White Paper, Entrust,

1999 [ENT99-2] Microsoft Windows 2000 Public-Key Infrastructure – White Paper, Entrust, 1999 [ENT00-1] Entrust and Microsoft Windows 2000: An Interoperability Overview – White Paper,

Entrust, 2000 [ENT00-2] The Power of Entrust on the Windows Platform, Entrust, 26 Oct 2000 [ENT02-1] Entrust PKI Deployment Methodology Annex M – Security Standards and Entrust,

Entrust, June 2002 [ENT02-2] The Federal Bridge: A Foundation of Trust, Entrust, 11 Sep 2002 [ENT02-3] Bringing Trust and Security to Wireless LANs, Entrust, 25 Oct 2002 [ENT02-4] Entrust PKI Deployment Methodology Annex F – System Hardening, Entrust, 2002



[FBCA00-1] Applying for Interoperability with the Federal Bridge Certification Authority, Richard A.

Guida, 12/8/2000 [FBCA00-2] Report of Federal Bridge Certification Authority Initiative and Demonstration –

Electronic Messaging Association Challenge, 2000, Draft 101500 [FBCA01] Federal Bridge Certification Authority Product Interoperability Guidelines, Sep 28, 2001 [GLA02] “Are You Being Watched?”, Brett Glass, April 23, 2002, PC Magazine [HON00] Ramon J. Hontanon, Network Magazine, Oct 5, 2000 – “Keeping PKI Under Lock and

Key” [HOU01] Planning for PKI – Best Practices Guide for Deploying Public Key Infrastructure, Russ

Housley and Tim Polk, Wiley, 2001 [IDX01-1] IDX-PKI Installation Guide, Nov 29 2001, Project IDX-PKI v1.5, Gerald Macinenti [IDX01-2] IDX-PKI User Guide, Oct 22 2001, Project IDX-PKI v1.5, Gerald Macinenti [KOB01] James Kobielus, Network World, 5/7/01, Simplification, not XML, is the key to PKI

success [LAM01] Lam, S., Zeber, S. November 2001. Concepts for a DREO Public Key Infrastructure

Laboratory. DREO-TN-135-2001. [MAG99] The Role of PKI & PMI in Defensive Information Warfare, Alan Magar, Royal

Holloway, 1999 [NOV99] Novell Certificate Server 2.0 White Paper, 1999 [OPEN] OpenLDAP 2.1 Administrator’s Guide, www.openldap.org [PEA03] Siani Pearson, et al., “Trusted Computing Platforms”, Prentice Hall PTR, 2003 [PGP02] Using an X.509 PKI with PGP 8: Protecting Existing Investments in an X.509 PKI,

Revision 2, PGP Corporation, December 2002 [PKI01-01] PKI Interoperability Framework Whitepaper, Editor Steve Lloyd, March 2001, PKI

Forum [PKI01-02] CA-CA Interoperability Whitepaper, Editor Steve Lloyd, March 2001, PKI Forum [PKI02] Understanding Certification Path Construction Whitepaper, Sep 2000, PKI Forum, Editor

Steve Lloyd [PKIC00] The ‘pki Challenge’ Description of Work, EEMA, 2000 [PKIC01-01] WP2 N003 – Secure Applications for PKI Support, Robert Willmott, EEMA, 31 January

2001 [PKIC01-02] WP2 N004 – Overview of Directory Issues, Robert Willmott, EEMA, 18 February 2001 [PKIC01-03] WP2 N005 – Overview of PKI Interoperability Issues, Martin Getliffe, EEMA, 15

February 2001



[PKIC01-04] WP2 N013 – Interoperability Test Criteria, Martin Getliffe et al., EEMA, 29 August 2001 [PKIC02-01] pki Booklet for EEMA 2002, EEMA, June 2002 [PKIC02-02] WP4 D4.3.3 Test Plan for Enrolment, Chris Gilbert & Kevin Blackman, EEMA, 26 April

2002 [PKIC02-03] WP4 D4.3.1 Test Plan for Cross Certification, Chris Gilbert & Kevin Blackman, EEMA,

15 August 2002 [PKIC02-04] WP4 D4.3.4 Test Plan for Certificate Validation, Chris Gilbert et al., EEMA, 19 August

2002 [RSA02] RSA Keon Certificate Authority Product Overview, Technology Whitepaper, RSA

Security, 2002 [SCA01] Joel Scambray, Stuart McClure and George Kurtz, “Hacking Exposed – Network

Security Secrets & Solutions”, 2nd Edition, Osborne/McGraw-Hill, 2001 [SEC02] PKI Support in Windows 2000 – Secorvo White Paper Version 1.1, Holger Mack, 12

February 2002 [SIE] Siemens DirX 6.0 Technical Datasheet [SIE01] Siemens DirX 6.0 Product Information, 2001 [SUN02-1] Sun One Certificate Server – Installation and Setup Guide, Sun, September 2002 [SUN02-2] Sun One Certificate Server – Agent’s Guide, Sun, September 2002 [SUN02-3] Sun One Certificate Server – Plug-Ins Guide, Sun, September 2002 [SWA03] Wireless Security and Privacy – Best Practices and Design Techniques, Tara M.

Swaminatha & Charles R. Elden, 2003, Addison-Wesley [SYM02] Symantec Ghost Implementation Guide version 7.5, Symantec, 2002 [VAL01-1] Valicert VA Publisher Installation and Configuration Guide, version 4.2.2, Nov 2001,

Valicert [VAL01-2] Valicert Enterprise VA Installation and Configuration Guide, version 4.2.2, Nov 2001,

Valicert [VAL02-1] Valicert Validation Authority, 2002, Valicert [W3C01] XML Key Management Specification (XKMS), W3C Note 30 March 2001, Warwick

Ford et al [ZEB02] Zeber, S. 2001. Statement of Work for a Contract to Develop A Plan to Implement a PKI

Interoperability Vulnerability Laboratory

Defence R&D Canada PKI Interoperability & Vulnerability Plan

______________________________________________________________________________________ Magar Security Architecture Inc. A-1 March 3, 2002

Annex A – Glossary of Terms 3DES Triple Data Encryption Standard ADUA Administrative Directory User Agent AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface ARM Advanced Registration Module BCA Bridge Certification Authority BITS Bridge Certification Authority Interoperability Test

Suite CA Certification Authority CAO Certification Authority Operator CAPI Crypto Application Programming Interface CAST Carlisle Adams Stafford Tavares CESG Communications-Electronics Security Group CF Canadian Forces CGI CMC Certificate Management Messages over CMS CMMF Certificate Management Message Format CMP Certificate Management Protocol CMS Card Management System CMS Cryptographic Message Syntax CRL Certificate Revocation List CRLDP Certificate Revocation List Distribution Point CRMF Certificate Request Message Format CSP Cryptographic Service Provider DAP Directory Access Protocol DDCEI Directorate Distributed Computing Engineering and

Integration DEMS Defence Electronic Messaging System DIT Directory Information Tree DMS Document Management System DN Distinguished Name DND Department of National Defence DoD Department of Defense DoS Denial of Service DRDC Defence Research and Development Canada DSA Digital Signature Algorithm DSS Digital Signature Standard DUA Directory User Agent EAP-TLS Extensible Authentication Protocol – Transport

Layer Security ECDSA Elliptic Curve Digital Signature Algorithm EFS Encrypting File System EMA Electronic Messaging Association ESP Encapsulating Security Payload FDIC Federal Deposit Insurance Corporation FIPS Federal Information Processing Standard FTP File Transfer Protocol GOC Government of Canada



GSA General Services Administration GUI Graphical User Interface HSM Hardware Security Module HTML HyperText Markup Language HTTP Hypertext Transport Protocol HTTPS Hypertext Transport Protocol/Secure IDEA International Data Encryption Algorithm IE Internet Explorer IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IIS Internet Information Server IKE Internet Key Exchange INRIA National Institute for Research in Computer Science

and Control IO Information Operations IPA Information Protection & Assurance IPSec Internet Protocol Security ISAKMP Internet Security Association and Key Management

Protocol ITU International Telecommunications Union JITC Joint Interoperability Test Command JSP Java Server Pages KEA Key Exchange Algorithm KMS Key Management Service KRM Key Recovery Module LDAP Lightweight Directory Access Protocol LDUP LDAPv3 Duplication/Replication/Update Protocol MD2 Message Digest 2 MD5 Message Digest 5 MISPC Minimum Interoperability Specifications for PKI

Components MIT LCS MIT Laboratory for Computer Science MMC Microsoft Management Console MMHS Military Message Handling System NATO North Atlantic Treaty Organization NDS Novell Directory Server (renamed Novell

eDirectory) NIST National Institute of Standards and Technology Nmap Network Mapper NORAD North American Aerospace Defence Command NTFS OCSP Online Certificate Status Protocol OS Operating System PC/SC Personal Computer / Smart Card PDA Personal Digital Assistant PEK Protection Encryption Key PEM Privacy Enhanced Mail PGP Pretty Good Privacy PH Protocol Handler PKCS Public-Key Cryptography Standards PKI Public Key Infrastructure pkiC Public Key Infrastructure Challenge PKIX Public Key Infrastructure X.509 POP3 Post Office Protocol 3



PSE Personal Secure Environment RA Registration Authority RAM Random Access Memory RAO Registration Authority Operator RC2 Rivest Cipher 2 RFC Request for Comments RIPEMD RACE Integrity Primitives Evaluation Message

Digest RSA Ranald L. Rivest, Adi Shamir, Leonard Adleman S/MIME Secure Multipart Internet Mail Extensions SCEP Simple Certificate Enrolment Protocol SCVP Simple Certificate Validation Protocol SECSH Secure Shell SET Secure Electronic Transaction SHA-1 Secure Hash Algorithm 1 SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol SP Service Pack SPKI Simple Public Key Infrastructure SQL Structured Query Language SSL Secure Sockets Layer TC Technical Committee TCP/IP Transmission Control Protocol/Internet Protocol TCPA TEMPEST Transient Electromagnetic Pulse Emanation

Standards TLS Transport Layer Security TSP Time Stamp Protocol TWG Technical Working Group URL Uniform Resource Locator VA Validation Authority VNC Virtual Network Computing VPN Virtual Private Network W3C World Wide Web Consortium WEP Wired Equivalent Privacy WG Working Group X-KISS XML Key Information Service Specification X-KRCS XML Key Registration Service Specification XKMS XML Key Management Specification XML Extensible Markup Language XML-SIG XML Signature



Annex B – Quoted Hardware Dell hardware was used for pricing estimates throughout this report. This is not meant to endorse Dell products and services in any way. Dell products were chosen due to the fact that pricing/product information was readily available (www.dell.ca). DRDC should purchase the required hardware from its preferred supplier. Hub 3COM Office Connect Dual Speed Hub 5-port $95.00 10/100Mbps Rack Belkin 19” Aluminum Distribution Rack 84” Height 56 Rack Units $275.00 750lbs Maximum Rack Mountable Weight RAID Array Dell PowerVault 220S 14 Disc SCSI Storage (36GB & 73GB Ultra 160 HD) $5384.00 Enhanced protection or performance offered through RAID 0,1,5,1/0,5/0 Server Power Edge 1650 Dimensions: 1.67”H (1U rack height) x 17.6”W x 27.0”D Intel Pentium III – 1.40 GHz with 512K cache 512Mb RAM 80Gb Hard Drive $2438 Intel Pro 100S with IPSec Network Adaptor 24x CDROM 1.44 Mb Diskettte Drive Rapid Rails for Dell Rack 3-Year Next Business Day On-Site Service No operating system, monitor, mouse or keyboard

Figure B-1 – Dell Power Edge 1650 (Front & Back)



Tape Backup PowerVault 100T DDS4 Drive High capacity data storage device using 4mm DAT

(Digital Audio Tape) technology $1350 Internal 20GB capacity 2.4MBps data transfer rate Requires ultra wide SCSI port Workstation Power Edge 350 Dimensions: 1.70”H (1U rack height) x 16.7”W x 24.0”D Intel Pentium III – 1.0 GHz with 256K cache 256Mb RAM 40Gb Hard Drive $1981 Intel Pro 100S with IPSec Network Adaptor 24x CDROM 1.44 Mb Diskettte Drive 4-post Rack Kit for Dell Rack 3-Year Next Business Day On-Site Service No operating system, monitor, mouse or keyboard

Figure B-2 – Dell Power Edge 350 (Front & Back) Workstation (high-end) Precision 350 Intel Pentium 4 – 2.26 GHz 256Mb RAM 40Gb Hard Drive $4105 1.44Mb Diskettte Drive Dual monitor capable video board Two 17” flat panel displays 3-Year Next Business Day On-Site Service Windows 2000 Professional





Annex C – Baltimore Technologies Quote

A Price Quote to Provide a UniCERT Test System & Support Services

Prepared for:

Magar Security Architecture Inc.

January 22, 2003

Prepared by:

Baltimore Technologies Needham Heights, Massachusetts



January 22, 2003 Alan Magar Information Security Architect Magar Security Architecture Inc. Suite 310, 95 Beech St. K1S 3J7 Dear Alan:

On behalf of Baltimore Technologies (Baltimore), I am pleased to forward a price quote to provide a UniCERT™ Test System for Defence Research & Development Canada (DRDC). Baltimore understands that UniCERT will be deployed in a PKI Interoperability Lab for the Information Operations Group at DRDC, and will not be used in a “live” or production environment. Historically, UniCERT provides superior operation when measured against our competitors in such test environments, offering specific technology wins in user-friendly operation, scalability, policy management robustness, and open server-based architecture design. Recognizing the significance of the DRDC PKI Interoperability Testing, Baltimore conveys a competitive Government discount for UniCERT software. Baltimore also includes our One! Bronze Support coverage to address service questions DRDC may experience during PKI Interoperability Testing. Baltimore optionally proposes 3 days of implementation and training, as we have found these services to be of benefit in establishing similar test evaluations. Baltimore also provides pricing for the optionally proposed SureWare™ Keyper Hardware Security Module. The SureWare Keyper HSM is designed to ensure the security of private keys in PKI applications, offering protected key storage, high-speed signature, and hardware key generation. Should you have any immediate questions regarding the quote, please do not hesitate to contact me. Thank you providing the opportunity to submit this quote to your organization. Sincerely, John Bys Phone: (860) 688-7711 Mobile: (860) 985-9400 Facsimile: (925) 871-4905



Baltimore’s Price Quote to Provide a UniCERT Test System & Support Services to Defense Research & Development Canada

Table of Contents

Section 1. UniCERT Test System and Support Services Price Quote............................ 104

Optional Installation and Training Services ............................................................... 105 Optional SureWare Keyper Hardware Security Module ............................................ 115

This document is protected under the copyright laws of the United States and other countries as an unpublished work. This proposal contains information that is proprietary and confidential to Baltimore Technologies, Inc., which shall not be disclosed outside the recipient's company or duplicated, used or disclosed in whole or in part by the recipient for any other purpose than to evaluate this proposal. Any other use or disclosure in whole or in part of this information without the express written permission of Baltimore Technologies, Inc. is prohibited.



Section 1. UniCERT Test System and Support Services Price Quote In the table below, Baltimore provides a Price Quote for the UniCERT Test System and Support Services proposed for the DRDC PKI Test Lab.

Baltimore Price Quote – UniCERT Test System & Support Services

Software and Services Pricing

UniCERT Test System, including the following core software modules: • Certificate Authority (with Publishing Module and Certificate Authority

Operator) • Registration Authority (with 1 Registration Authority Exchange) • 1 Web-based Registration Authority Operator client software module (for

Web-based registration) • Registration Handlers (Web, email, VPN) • Management Pack (Token Manager, Drivers, Reports) • 100-user license to support testing purposes

US $18,000

Baltimore One! Bronze Level Support for UniCERT Test System, including: • Interactive Web Support • Baltimore Global Support Center-provided Telephone/FAX Assistance,

Monday through Friday; 9 a.m. to 5 p.m. (Eastern Time) • Use of Baltimore’s online Knowledge Base • Two DRDC support contacts, secured via digital certificates to conduct

support communications with Baltimore Global Support Service resources

US $900 (for every 30-day period of the Test System lifecycle)

Pricing Notes:

• All pricing quoted in US Dollars.

• Baltimore understands the UniCERT system proposed for the DRDC project will be used for test and evaluation purposes only, and not as a production-level system.

• Oracle is employed as the UniCERT RDBMS. If DRDC does not have an Oracle license

to support the UniCERT test platform, one can provided.

Optional Installation and Training Services



Baltimore optionally proposed to provide UniCERT Core Installation and Training services to support DRDC’s establishment of the test environment.

Baltimore Systems Engineer services, including installation support for the following UniCERT components:

• 1 CA (includes CAO and Publisher) • 1 RA (includes RAX) • 1 WebRAO clients (for administrators to process certificate requests) • 1 WebHandler (for users to request certificates) • Setup of up to 3 certificate policies (e.g., SSL, VPN, etc.) • Integration with 1 LDAP or 1 OCSP server • Integration with Oracle

US $6,000

Pricing Notes

• Baltimore Systems Engineering Installation Activities do not include travel & expenses, which will be relayed to DRDC at cost.

• If DRCD identifies the need for additional UniCERT Installation and Training services,

Baltimore can provide such efforts at our standard rates.

Optional SureWare Keyper Hardware Security Module As an option, Baltimore can also provide SureWare Keyper Hardware Security Module technology. SureWare Keyper and host adapter software provide complete hardware cryptography support for UniCERT and other CAs via a PKCS #11 interface. Each SureWare Keyper Professional is supplied with the following components:

• PKCS#11 software • Power supply • LAN cables • Installation and user manuals • 2 Security Officer smart cards (16K) • 2 Application Key Back-up smart cards (128K) • 4 AAK Back-up smart cards (16K) • 4 SMK smart cards.

Pricing for optionally proposed SureWare Keyper Professional Hardware Security Module

US $17,500

Baltimore One! Bronze Support for SureWare Keyper HSM – 30 day period US $265



Annex C – Siemens Quote

Siemens Canada Limited

To: Alan Magar Quoted by: Erica Hughes Attn: Consultant to

DRDC

Quoted Date: Jan 29 2003 Expiration Date: 30 days from quote

date

Software Total: $7,924.80 Services Total: $3,000.00 Standard Maintenance Total: $1,584.96 TOTAL: $12,509.76

Quantity Order Number Description Short

Description Long Price per Unit

Extended Price

CD-ROM Meta Directory

1 P50015-P4522-X3 DirX Meta Directory CD Edition 07/01 Volume 1

CD-ROM with the latest releases of DirX, DirXweb, DirXmobile, DirXdiscover; associated licenses are required separately

$ 124.80 $124.80

Licenses (Rights of use) for enterprise intranets

DirX V6.0 and DirXweb V6.0: entry-based pricing model

1 P50015-P4600-V600 DirX-1K V6.0 Right of use for 1.000 master entries for one DirX V6.0 and DirXweb server

$ 7,800.00 $ 7,800.00

Professional Services for DirX Meta Directory

2 PS Govt Rate1500 DirX Meta Directory Consulting

Consulting for Directory products Quantity in days (a day is 7.25 hours)

$ 1,500.00 $ 3,000.00

Service for DirX Meta Directory products

1 YEAR 1 Year standard maintenance (DRDC lab)

DirX Meta Directory Service

Service for Directory products Quantity in number of years 5X12 Support, includes telephone support (8-5, M-

24% OF SOFTWARE LIST PRICE

$1,584.96



F), software upgrades and bug fixes.

Notes: 1) Any and all applicable taxes are not included in this quote 2) Prices are guaranteed for the 30 days past the quote date 3) PO should be faxed to Erica Hughes at 613-591-8731



Annex D – Sun One Certificate Server Sales Quotation Quote Number: T-CA-33688-A Quote Date: 29/01/03 Validity Period: 60 Days Credit Terms: NET 3O FRM INV DATE Shipping Terms: Ex Works To: From: ALAN MAGAR Mike Fortier MAGAR SECURITY ARCHITECTURE INC Sun Microsystems of Canada 95 BEECH ST International Americas Sun Center STE 310 27 Allstate Parkway OTTAWA, ON K1S 3J7 Markham, ON L3R 5A4 CA CANADA Ph/Fax:6132330199/6132366803 Ph:1-800-786-0404 Fax:1-800-263-9757 [email protected] Unit Unit Extended Product List Net Net Item Number Description Qty Price Disc Price Price(CAN$) --------------------------------------------------------------------------------------------------------------- 1 CMSD9-LCO Sun ONE Certificate 1 $7.95 0 $7.95 $7.95 -JA01 Server, License Only, pricing per entry, 1 - 49,999 entries 2 CMSDM-470 Sun ONE Certificate 1 $79.50 0 $79.50 $79.50 CJAK9 Server,v4.7 Media and Softcopy Doc Kit (no license), for Windows 2K, NT, Solaris, Worldwide (128 Bit) $87.45 PLEASE READ THE FOLLOWING: THIS SUN QUOTATION AND ANY ORDER YOU SUBMIT FOR PRODUCTS OR SERVICES IS SUBJECT TO: (1) THE TERMS OF ANY EXISTING SALES AGREEMENT YOU HAVE WITH SUN GOVERNING THAT PRODUCT OR SERVICE, OR, IF NONE, BY SUN'S SALES TERMS FOUND AT http://www.sun.com/sales/salesterms, THE GENERAL TERMS OF WHICH ARE EITHER ATTACHED OR ON THE REVERSE SIDE HEREOF, AND (2) APPLICABLE SUN SERVICE LISTINGS AND STATEMENTS OF WORK FOUND AT http://www.sun.com/service/servicelist [(1) AND (2) COLLECTIVELY BEING CALLED "SUN SALES TERMS."] ALL ORDERS MUST REFERENCE EITHER YOUR SALES AGREEMENT NUMBER OR THIS SALES QUOTATION AND BE IN CONFORMANCE WTIH SUN SALES TERMS. ORDERS ARE SUBJECT TO ACCEPTANCE BY SUN EITHER THROUGH ISSUANCE OF AN ORDER ACKNOWLEDGEMENT OR



DELIVERY OF THE PRODUCTS OR SERVICES. THIS QUOTATION REMAINS FIRM FOR THE PERIOD LISTED ABOVE, EXCEPT THAT SUN MAY MODIFY THIS SALES QUOTATION IF THERE IS A TYPOGRAPHICAL ERROR OR THE AVAILABILITY OF PRODUCTS SERVICES, OR CREDIT CHANGE. VOICI LES CONDITIONS GÉNÉRALES APPLICABLES À VOTRE COMMANDE. VOUS TROUVEREZ LES CONDITIONS ADDITIONNELLES QUI S'APPLIQUENT À VOTRE COMMANDE À L'ADRESSE SUIVANTE http://www.sun.com/sales/salesterms/.



Annex E – Valicert Quote Alan, It was nice talking with you on the phone today. Per our conversation the pricing on our Validation Authority product would be $10,000 plus annual maintenance at 20% or $2000. This would include the Validation Authority Server license, 100 users, 10 Desktop Validators and 2 Server Validators. Our normal list price on this would be $48,450 plus maintenance at 20%. We can provide the extensive discounts based on the fact that you would be using this for Lab work/non production environment. Once you have a nod on the funds please let me know. If you need anything else please give myself or Ted McKendall a call. I have listed our contact information below. Thanks, Joel Eaves Ted McKendall Valicert Valicert District Sales Manager Security Specialist phone 630 859-2972 phone 773 935-0352 email [email protected] email [email protected]

UNCLASSIFIED SECURITY CLASSIFICATION OF FORM

(highest classification of Title, Abstract, Keywords)

DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified)

1. ORIGINATOR (the name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Establishment sponsoring a contractor’s report, or tasking agency, are entered in section 8.)

Magar Security Architecture Inc. 95 Beech Street, Suite 310 Ottawa, K1S 3J7

2. SECURITY CLASSIFICATION (overall security classification of the document,

including special warning terms if applicable) UNCLASSIFIED

3. TITLE (the complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S,C or U) in parentheses after the title.)

A Plan to Implement a Public Key Infrastructure (PKI) Interoperability and Vulnerability Laboratory (U)

4. AUTHORS (Last name, first name, middle initial)

Magar, Alan

5. DATE OF PUBLICATION (month and year of publication of document)

March 2003

6a. NO. OF PAGES (total containing information. Include Annexes, Appendices, etc.)

114

6b. NO. OF REFS (total cited in document)

62

7. DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.)

Contract Report

8. SPONSORING ACTIVITY (the name of the department project office or laboratory sponsoring the research and development. Include the address.)

DRDC Ottawa/IO Section 3701 Carling Avenue Ottawa K1A 0Z4

9a. PROJECT OR GRANT NO. (if appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant)

5BF27

9b. CONTRACT NO. (if appropriate, the applicable number under which the document was written)

W7714-2-08309

10a. ORIGINATOR’S DOCUMENT NUMBER (the official document number by which the document is identified by the originating activity. This number must be unique to this document.)

DRDC-2003-02

10b. OTHER DOCUMENT NOS. (Any other numbers which may be assigned this document either by the originator or by the sponsor)

DRDC Ottawa CR 2003-027

11. DOCUMENT AVAILABILITY (any limitations on further dissemination of the document, other than those imposed by security classification) ( x ) Unlimited distribution ( ) Distribution limited to defence departments and defence contractors; further distribution only as approved ( ) Distribution limited to defence departments and Canadian defence contractors; further distribution only as approved ( ) Distribution limited to government departments and agencies; further distribution only as approved ( ) Distribution limited to defence departments; further distribution only as approved ( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (any limitation to the bibliographic announcement of this document. This will normally correspond to

the Document Availability (11). However, where further distribution (beyond the audience specified in 11) is possible, a wider announcement audience may be selected.)

Full Unlimited

UNCLASSIFIED

SECURITY CLASSIFICATION OF FORM DDCCDD0033 22//0066//8877

UNCLASSIFIED SECURITY CLASSIFICATION OF FORM

13. ABSTRACT ( a brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual).

This report proposes, and includes the necessary plans for, the implementation of a world class PKI Laboratory and Testbed Facility (PKI Lab). The PKI lab would be used to investigate and evaluate security mechanisms and the issues arising from its deployment and operation in a military environment. The PKI lab would enable DRDC to further develop practical expertise in this field, to conduct research activities related to PKI and to provide expert advice to DND and other government departments. Initial research activities will focus on interoperability issues and the vulnerability of commercial implementations. (U)

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus-identified. If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

Authentication Certification Authority Directory Interoperability Lab LDAP PKI Public Key Infrastructure Vulnerability Lab X.500

UNCLASSIFIED

SECURITY CLASSIFICATION OF FORM