Authentication is not Authorization?! And what is a "digital signature" anyway? Prepared by R. David Vernon Revised 12/01 Introduction REV 1A As part of the IT Architecture Initiative, the Office of Information Technologies (OIT) is producing a series of papers outlining directions in information technology architecture. In the spirit of RFCs, the papers are written to help understand and to open dialogue about information technology trends at Cornell, with the ultimate goal of improving the use and interoperability of information technology services throughout Cornell. Synopsis This paper briefly outlines issues Cornell faces to ensure a trusted exchange of information across the Cornell data network and the Internet at large. It includes Definitions of authentication and authorization Review authentication and authorization from a historic Cornell context General authentication and authorization architectures and technologies Practical implications Action items Closing thoughts What Is "Network" Authentication and Authorization? At Cornell and throughout the world, information is exchanged and access to computers is enabled by the Internet. Moreover, the access to resources via the Internet is sometimes only intended for specific network entities. The requirement to authorize access between authenticated entities drives the need for a network "access-management" architecture at Cornell. 1
Authentication and authorization are each critical in its own light and are unique parts of the larger accessmanagement architecture. Authentication is the process of ensuring knowledge of who or what (in other words, what person or what computer) is accessing "your" resource, your information, or both. Authentication is also the process of ensuring "irrefutable knowledge" of whose service you are accessing. Authorization is the process used to determine what services can be accessed by an irrefutable known (in other words, authenticated) network user or computer. Thus, authentication enables users and computers on the Internet to know with whom they are communicating. Authorization determines the allocation of services to an authenticated user. Reviewing Authentication and Authorization from a Historic Cornell Context New access-management-service requirements at Cornell warrant review. Traditionally, authentication services helped a computer identify a person attempting to gain access, or to "log on." Now, however, new authentication needs have evolved that go beyond the traditional scope of Cornell's authentication system. These new requirements include Digital signatures: As the name implies, this process marks an electronic document to signify its association with the author. Think broadly of the terms "document" and "author." An author could be a human or a machine, and a document could be anything from an e-mail message to radio telescope telemetry. Identity Management: As more people use greater numbers of network-attached devices to support a growing number of services, forging the "best" architecture to manage these network Principals is a critical and complex challenge. Trust: Trust dictates the value of a digital signature. Trusting the validation process is key to any new authentication service. Although Cornell constituents might trust Cornell s authentication service, extending this trust outside of Cornell is a challenge. Privacy: This is not directly related to authentication, but with authentication technology, encrypted information can be sent efficiently across the Internet. An authentication system that allows digital signatures can also be the core service that exchanges encrypted information, thus ensuring the privacy of the communication. These new service needs, DIGITAL SIGNATURES, IDENTITY MANAGEMENT, TRUST, and PRIVACY are the driving force behind Cornell's retooling of its traditional access-management-service suite. General Authentication and Authorization Architectures and Technologies To provide context for new authentication and authorization challenges, here is a brief review of current and potential authentication services. Current Cornell deployed Kerberos authentication service Future Public Key Infrastructure (PKI) services 2
KERBEROS: The foundation for a Cornell wide authentication system was implemented in the early 1990s. The initial intent was to create a single sign-on process for a mix of central administrative hosts. This authentication system was based on Kerberos. Although new service needs are now apparent, Kerberos at Cornell remains the default authentication and sometime authorization service. A detailed history and current CIT plans for service enhancements are available in CIT's Authentication at Cornell Past, Present, and Future. 1 Kerberos acts as a "key distribution center" (KDC) to provide network Principals (users and computers) encryption "keys" to exchange through packages known as session tickets. KDC allocated tickets and the means in which they are interpreted allow Principals to authenticate confidently and securely with whom they are exchanging information. So what does this mean in layman's terms? Simply put, Kerberos economically facilitates secure (encrypted) logons to campus computers. Conceptually it accomplishes this as follows: Think of a Kerberos service as a universally trusted friend in the Cornell network family. First, users and computers register themselves with the trusted friend. In other words, there is a manual process of showing the trusted friend you are who you say you are. After this initial process, users then identify themselves to the trusted friend with a username and password agreed upon during the registration process. Logically this process works well to gain knowledge about who is communicating with the friend, but the goal is to extend this information to other network services. To accomplish this the friend provides encrypted identification codes that users can exchange as a proxy for their identification. In turn, when these proxies are presented to network services (or other users), the process that reads these identification codes ensures the code was given out only by the trusted friend, and, in turn, the identity of the requesting user. Although the technical nuances of how this information is exchanged between client and server is beyond the scope of this paper, the important concept is users and computers on a network "trust" the Kerberos service as a secure and robust means of authentication. For more detailed information about how Kerberos works, see web.mit.edu/kerberos/www/. PKI AND DIGITAL SIGNATURES: Theoretically, if all network users at Cornell were authenticated through Kerberos, a high degree of confidence that all user interactions could be attributed to known entities would exist. To some degree, this strong trust of Kerberos authentication at Cornell has become a proxy for the "signature" of the requesting user. But using Kerberos at Cornell, however ubiquitous, will not satisfy the need to know about users beyond our Kerberos realm. Moreover, Kerberos does not readily attach a digital signature to a document. To provide authentication through "digital signatures" across the Internet, support is growing for an authentication service known as Public Key Infrastructure (PKI). Like Kerberos, PKI uses a trusted service to get irrefutable knowledge about a network user. But unlike Kerberos, PKI uses the open and operationally efficient exchange of a "public" key. In a PKI authentication system, a user registers with a PKI service, often referred to as a certificate authority (CA). This registration process is required to associate the user with a pair of encryption keys that encrypt and decrypt information. One unique key is private; one unique key is public. The private key is kept secret by the registered user, but the public key is shared with the world. In turn, the Certificate Authority is trusted to associate the public key with a known Principal. This pair of "asymmetric" keys can then be used by the public to associate a digitally signed document with a user known to a trusted CA. PKI registered users digitally sign a document by using their PKI private key to encrypt a small mathematic summary of the document. This encrypted summary is sent along with the document. The public then takes the document and uses the PKI public key posted by the CA to decrypt the summary. At 1 http://www.cit.cornell.edu/oit/arch-init/authenticationdirections.pdf 3
this point, communicating Principals mathematically summarize the document. If the two summaries are the same, Principals know who sent the document (authenticated) the document was not changed after it was sent In addition to PKI's ability to authenticate the author of a document, PKI can also facilitate encrypting and transferring large amounts of data. To do this, clients use PKI encryption to encrypt a new non PKI key that was used to efficiently encrypt a "large" document. A different encryption process is used because Public Key Encryption is mathematically intensive and therefore not considered suitable for encrypting more than a small amount of data. In this scenario, the public would use the intended recipient's public key to encrypt the new key used earlier to encrypt a "large" document. The new key-encrypted document and the PKI encrypted new key would be sent to the intended recipient. Only the destination user's PKI private key can decrypt the key used to encrypt the document, so the transfer is considered secure. For more information about using PKI systems to deliver "symmetric" keys, see additional information about protocols such as Secure Socket Layer (SSL) 2. This process alone does not authenticate the author of the document to do this, the author would also need to sign the document digitally. CHALLENGES FOR PKI IMPLEMENTATION AT CORNELL: Although PKI offers clear benefits, its use at Cornell brings challenges. Two key challenges are trust key management As with Kerberos, the value of PKI is subordinate to the trust users have for the certificate authority. If the CA is not trustworthy, the digital signatures are worthless. In context, PKI Certificate authorities generally distribute information about registered users using a structured form known as an X.509 certificate how would Cornell verify the integrity of X.509 certificates delivered by a peer Ivy school? How would a peer Ivy verify Cornell's? Even with the simplified key management enabled by PKI schemes, 3 the best way to extend trust across the CA's realms is not universally agreed upon by industry experts. Fortunately an interim solution will afford Cornell and similar organizations with an institutionally trusted CA service today. This Certificate Authority service will come from an external and independent agency, from which there are several to choose. 4 These for-fee independent corporations offer user-authentication classes based on the institution s ability to verify the requesting user s identity. Even if Cornell elects to outsource its PKI services, this does not eliminate Cornell s responsibility to understand and manage the operational ramifications of PKI key pairs being doled out for Cornell business and research communications. Many digitally signed and encrypted documents will be associated with an individual, and with the campus at large, how Cornell goes about revoking keys and ensuring institutional access to private PKI keys will be critical. Practical Implications A growing consensus prevails that for Cornell to have a viable and flexible authentication architecture, it must incorporate both private (Kerberos) and Public Key (PKI) strategies. But these services should not be developed blindly of each other Cornell must examine common implementation requirements and service 2 home.netscape.com/eng/ssl3/draft302.txt 3 Management of PKI keys: the "public" key is much simpler to manage than the "private" encryption keys used by systems such as Kerberos. 4 Cornell has a limited contract with VeriSign to provide CA services. 4
synergies for Kerberos and PKI. These synergies include creating a common directory structure and coordinating encryption key exchange services to enhance privacy tools. But given the limitations of current Cornell authentication and authorization perspectives and the need for an expanded suite of authentication services, PKI may well work. Although the components of Kerberos at Cornell could offer digital signature services and general privacy tools, the intention is to maintain Kerberos as a client / server authentication service. Simply stated, the new needs of broader digital signatures and extended privacy are better addressed with PKI resources, because these tools are easier to manage and have a large national backing. One challenge at Cornell is the tendency to associate an authenticated user with a default suite of service access. In addition, Cornell has a tendency to associate authorized Network IDs as a "right" to consume Cornell resources. Current events have proven the problematic nature of this thinking. If network IDs can be assigned only to official members of Cornell, and anyone with a network ID can get access to EZ- Remote, how does Cornell give Network IDs required for access to library printers to people who are not members of Cornell? The problem is clear and the required rethink is simple; authentication and authorization must be separated. Although a Kerberos ticket can be a prerequisite to authorizing the use of Cornell service, a ticket does not and should never imply default authorization to a service. Authorization to a service as rich and unique as creative minds at Cornell may create must be delegated to the owners of services and never be assumed as part of the authentication process. Yet just because authorization is not authentication does not mean the authentication system has no value to an authorization process. As authentication securely exchanges knowledge of a user s identity, it can also send along a bit of demographic information. For example, this user is a Cornell student, staff member, guest, and so forth. If demographic data is exchanged, service providers can easily offer and authorize "group" services to users with a common attribute. Architecturally, these attributes can be collected by the Kerberos server from a trusted campus directory service, such as the pending Cornell Lightweight Directory Access Protocol (LDAP) server or other viable directory resources. Of course, transmitting these attributes rests on forging a campus consensus of what classifies a student, staff member, or guest. Action Items Enhancing services at Cornell will require developing new tools and rethinking old perspectives. The challenges being addressed include Re-articulate the notion that authentication is not authorization. Develop university policy to address ownership and management of encryption keys. Explore developing and managing a Cornell operated certificate authority or a campuswide contract with a private corporation for large-scale Cornell CA services. Forge a suite of common attributes to associate with Cornell Principals, thus providing efficient authorization schemas for service providers. Design LDAP services that act as a common directory resource for PKI and Kerberos authentication systems. Educate users on the concepts of digital signatures and the use of PKI infrastructures to help transfer encrypted information. Explore Kerberos ticket exchanges as a way to deliver symmetric encryption keys for general data encryption services. 5
Extend authorization services to new classes of network devices that will require authentication for access (for example, network switches and wireless hubs). Watch national trends and work with peer institution projects to ensure Cornell's participation in developing PKI interrealm-trust strategies. Closing Thoughts Advanced authorization services are not a future need there is a University need today for extended digital signature services and trust relationships with peer institutions certificate authorities. Multiple national initiatives and evolving state and federal laws on privacy rights, such as HIPAA 5, require the secure exchange of information. Now advanced authentication and privacy services are a baseline for Internet information exchange. In addition, new demands on authentication services at Cornell will force a broader review of Cornell's traditional perspective on the scope of an "authentication service." New client demands driven by authentication paradigms such as authentication and authorization to access campus network services or to associate resource consumption for billing purposes will place unprecedented demands on the authentication infrastructure. These facts, combined with the growing University dependency on Internet based delivery of services and communication, will all but force Cornell to invest rapidly in the retooling and education needed to ensure extended authorization capabilities. Today this may be best enabled with a flexible access-management strategy leveraging past investments in Kerberos while adding integrated PKI services in cooperation with peer institutions to afford cost-effective authentication and encryption services across a wide area. Over time, this dual Kerberos and PKI strategy should be reviewed to see if the PKI / Kerberos systems should be replaced by a single PKI based authentication service. 5 www.hcfa.gov/hipaa/hipaahm.htm 6