Intel s View of Business Requirements and Future Work on the APKI

Transcription

1 Intel s View of Business Requirements and Future Work on the APKI April, 1998 May 6, 1998

2

3 Table of Contents 1 BUSINESS REQUIREMENTS INTRODUCTION TAXONOMY OF BUSINESS REQUIREMENTS FUTURE WORK PKI DEVELOPMENT User Authentication Services Verification Services Local Audit Services PERVASIVE USE OF CDSA CDSA Portability and Interoperability Testing INCREASING ACCESS TO CDSA-BASED SERVICES Other Language Interfaces to CDSA...5 i May 6, 1998

4

5 1 Business Requirements 1.0 Introduction At the Amsterdam meeting of the Security Program Group, Denise Ecklund of Intel presented a number of proposals for the future work of the group. There was debate about the Business Requirements for some of the work; especially for the new technologies being proposed. This document presents the business requirements motivating the proposals, and in the process, clarifies and expands them. 1.1 Taxonomy of Business Requirements The business requirements for security technology (and technology in general) are necessarily indirect, since the intention is to make technology as invisible to users as possible. Given that the technology under discussion is intended to build a Public Key Infrastructure (PKI), it is possible to put requirements in the categories defined below. This list is intended to be in order of importance. 1. Facilitate Application & Middleware Development Buyers require secured, interoperable application products for the broad range of platforms deployed in their organizations. To reduce cost, the option to select among competing products is desired, but interoperability among the selected products is required. To increase application development and reduce the cost of that development, the PKI must provide the services of a trusted computing base. Making it a ubiquitous infrastructure, the burden of development is taken from the application developers (thus giving them more time and resources to concentrate on the application domain). Being part of the infrastructure also ensures that the services will be developed correctly by companies in the security business; thus platforms become richer, more secure, more reliable, and more trustworthy with the addition of the PKI. 2. Support Legacy and Heritage Infrastructure To maintain current business practices while evolving to improved business models, buyers need to support some existing applications and infrastructure, upgrade some existing applications, and integrate new applications. To meet these requirements, the PKI architecture should be architected to support important legacy and heritage technology; thus providing an evolution to new technology. 3. Interoperability (Standard protocols) Multi-platform environments are built to support evolving business practices and to take advantage of new technologies that better support those practices. A standard infrastructure supporting standard protocols provides the interoperability required to construct and operate a multi-vendor network, and also provides vendor independence to the buyer. 4. Portability of Applications & Middleware (APIs/SPIs) Buyers purchase new platforms, systems and applications to reduce maintenance costs, to acquire new features, and to improve system performance. When new platforms are acquired, existing and new applications must be easily ported to the new platforms. A standard infrastructure providing standard APIs allows application developers to support multiple platforms, making the software available on the buyer s platforms of choice. The pervasive infrastructure effectively increases the size of the market for a given application, thus encouraging application development. The effect is to increase the number of applications available on a particular platform. 5. Vendor Independence for Service Providers May 6,

6 Defining an infrastructure that allows service vendors to compete on a level playing field not only increases competition, but also allows the customers to avoid being locked-in to a particular platform vendor. The net result is more choice and better service. 6. Portability of Service Providers (SPIs) As with portable applications, the portability of service providers broadens the market for the services and thus further encourages their development. It also makes the services ubiquitously available on many platforms. 7. Enable Technology Evolution As business practices evolve so must the systems that support those practices. Total replacement is typically not feasible, and the overnight switch from an old system to a new one is extremely risky for any business venture. An extensible infrastructure that provides programming models and frameworks independent of particular technology not only allows for the use of legacy technology, but also allows for that technology to evolve over time. 8. Functional Completeness (of APKI) Buyers who deploy applications require complete, consistent, full-featured systems that can support growing applications without the cost of frequent system replacement or upgrade. No general-purpose infrastructure can ever predict all the uses to which it will be put, and thus should not be limited to only those facilities, features, and options that have been specifically requested by customers. While system architecture should be customer-driven, the architects also have the responsibility to achieve completeness in order to maximize application and service-provider development. 2 Future Work 2.1 PKI Development The Open Group APKI defines a solid base for addressing specific business requirements related to security and security services. We are proposing to further the construction of the OpenGroup s Public Key Infrastructure (PKI) based on new and evolving business requirements. The Security Program Group is in the process of developing a document defining its proposed architecture for the PKI (the APKI document). This will also form the core for security in the IT DialTone Architecture Definition. CDSA provides the foundations for this APKI. In order to develop (or select) technologies to implement the PKI, it is necessary that this technology development proceed in conjunction with the architecture development, providing timely mutual feed-back. And it is also necessary that the APKI achieve a sufficient level of detail to provide criteria for judging the efficacy of the technology. In this synergistic process of technology and architecture development, business requirements are constantly under consideration. Several new PKI Services were proposed: 1. A User Authentication Service (UAS) 2. A Verification Service 3. A Local Audit Service The services in the PKI are layered. For example, Single Sign On (XSSO) needs user authentication to identify the user who is logging on. The Virtual SmartCard Service (aka PSM) needs user authentication to 2 May 6, 1998

7 implement identity-based access control. Many services, such as GSS-IDUP, require the integrity and authentication of data objects. Policy-based services such as Security Context Management require integrity and authentication of executable policy libraries. The following subsections present an overview of each proposed new service, and the additional business requirements addressed by that service User Authentication Services The User Authentication Service is an extension of the CSSM framework (using the Elective Module Manager (EMM) mechanism) to provide authenticated identification of Users. UAS builds on the CDSA and provides a common programming abstraction for User Authentication, independent of the technology or device used to authenticate. And, as an extension to CSSM, the programming model is also platform and vendor independent. This means buyers can select different biometric service providers from various vendors as the authentication mechanisms of choice for different platforms throughout their enterprise. The applications and higher-level security services using these devices call the same interface regardless of the device type or service provider. The UAS Service Providers may also use the integrity library of the CSSM framework to increase the integrity of the stack. UAS provides two plug-in Service Provider Interfaces (SPIs): Authentication Service Providers Policy Service Providers The ability to dynamically select a policy service provider makes it easy for applications and high-level security services to provide features that allow enterprise IT departments to specify and install their own policies. If dynamic policy selection were not possible in the authentication service it would be difficult for developers to provide this and pass the feature along to IT organizations. Empowered with policy definition capabilities, IT organizations can support the current and evolving business practices of their organizations. Methods that can be used to authenticate a user include: knowledge of a password possession of a SmartCard and its pass-phrase various physical attributes of the user (voice, facial image, fingerprints, etc). The UAS not only provides alternatives to passwords, but also provides the opportunity to authenticate the user based on multiple methods. Further, with the use of Policy Service Providers, it is also possible for administrators to control the strength of authentication based upon the value of the assets being protected; rather than leave it up to the user to create weak passwords which, in any case, are independent of asset value. Biometric authentication has the potential to be very useful for high-value authentication. Since it is based on the inherent physical attributes of a user, proof of identity cannot be easily lost, stolen, transferred or otherwise compromised. And this strength can be further enhanced if used in conjunction with conventional authentication mechanisms like SmartCards and Passwords. Whether Biometric technology is ready for Prime Time is moot; APIs are already in the process of development, and products are coming to market. The Open Group must consider the need to include Biometric Authentication in the APKI. We recommend that a general user authentication interface encompassing biometrics and other authentication data be proposed and considered for standardization Verification Services May 6,

8 The Verification Service Library (VSL) is an extension of the CSSM framework (using the Elective Module Manager (EMM) mechanism) to provide generalized verification services for all types of moveable application data objects. All security services must verify the integrity and authenticity of an object before using that object. Integrity and authentication is the minimum requirement to establish a trust relationship. It is critical that the verification service itself be correctly implemented, trustworthy, and not easily spoofed or circumvented. High-level security services and applications could not build upon a verification service that did not provide this degree of trust. Creating a single verification service does not necessarily achieve this goal, but it makes it more achievable by reducing the number of implementations and focusing security analysis on a highly critical component of the system. Buyers would have a difficult time trusting multiple implementations of verification services from many and varied vendors. A sound service supports all higher-level services. VSL builds on the CDSA and provides a common programming abstraction for checking the integrity and authenticity of moveable application-defined data and software objects. Application data objects are owned and managed by applications in the enterprise. If moving data from one storage media to another or from one system to another invalidates the integrity or authenticity of the data, then operating procedures must be changed to account for this problem, or integrity is lost and security is weakened. In the worst case, business practices must be modified to account for the changes in operating procedures. VSL attempts to mitigate this problem for all applications and higher-level security services. Enterprises regain traditional management control of their application data objects without compromising the level of security imposed on those data objects. The ability to securely move objects is critical to IT DialTone. We recommend that a verification services be proposed and considered for standardization Local Audit Services Distributed Audit Services (XDAS) defines an interface for combining audit logs generated by a set of distributed processes systems. This service solves a major security problem for IT organizations that manage many systems. Often, a unified audit log is required to detect attacks upon a distributed system at large. The audit logs being merged via the XDAS interface are generated by single-site and multi-site applications. Each log contributor creates local log entries and uses XDAS interfaces to form a secured and merged log. Currently, each contributor is responsible for securing it s own local log entries before using XDAS. Different operating systems on different platforms provide different native logging services. Typically these logging services do not provide any security over the log. Application developers have two choices: 1. modify their implementations to use different logging (possibly dispensing with security over the log) 2. implement their own local, secured logging mechanism The buyer suffers with either choice. If the local log is not secured, then the contents of a merged, secured log is suspect. This compromises security in the environment. If each vendor implements a local, secured logging mechanism the buyer must pay for redundant implementations on each platform, must trust that each of many implementations is correct, and must trust that the log will be interoperable with any XDAS data format requirements. LAS builds on the CDSA and provides a common programming abstraction for secured local logs. Service providers can be implemented to augment native local logging services with security features or can provide their own implementation. Clearly, multiple service providers are required but the number is small compared with the number of applications and high-level security services that must otherwise implement their own local logging service. 4 May 6, 1998

9 With a secured local audit service, enterprise managers can be assured that their audit logs are secured and meet their business requirements to provide audit trails for legal purposes. We recommend that a local audit services interface be proposed and considered for standardization. 2.2 Pervasive use of CDSA The pervasive use of a CDSA-compliant infrastructure, service providers, and applications results in: improved security through common implementations that have undergone extensive security analysis reduced costs for platform vendors who can deliver and maintain a common solution rather than widely-variant solutions across variations of their platform reduced cost for buyers as a direct result of increased competition, and reduced development and maintenance costs for sellers opportunities for new applications and new layered services CDSA Portability and Interoperability Testing Portability is an essential requirement for an infrastructure; both for the applications that use it, and the service providers that implement it. Intel s proposal consists in developing test suites for both the APIs and SPIs of infrastructure components (starting with CDSA). In addition to developing test suites, it is necessary to provide an environment in which application developers and service providers can get together to allow portability testing on a wide range of platforms and services. This plug fest will not only test the portability of the infrastructure, but may lead to improvements in the infrastructure to improve portability in future releases. 2.3 Increasing Access to CDSA-based Services Other Language Interfaces to CDSA The reference implementation for CDSA was developed in C, and the API is designed for C-based applications. As the world progresses to object development, C++, Java, and COM all become more important considerations to application developers. To address the security needs of applications developed in these languages, it becomes urgent to provide access to CDSA functionality expressed in these languages (particularly Java). CDSA (and the CSSM framework) provides value to three distinct constituencies: application developers service provider developers buyers and users. Additional language interfaces will preserve and enhance this set of values. Additional language interfaces: ensure a uniformly high quality of security is delivered to a wider range of applications by making the same services available through all languages attract new developers to the infrastructure, creating more useful layered products and services reduce the learning curve for development organizations that develop and support applications in multiple languages It is not just the particular language, but also its implementation in terms of the CSSM framework that is important. May 6,

10 Intel has developed some example applications in C++ using CDSA s C language interfaces. While not the best solution, it is currently a workable one. Java is being used by many to develop in-house and commercial Internet applications. COM is also a popular development vehicle. For these reasons, we recommend prioritizing the Java language and that a Java-CDSA interface be proposed and considered for standardization. 6 May 6, 1998