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.
pdf version
Authentication
is not Authorization?! And what is a "digital signature" anyway?
Prepared
by R. David Vernon
Revised
12/01
REV 1A
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.
Authentication
and authorization are each critical in its own light and
are unique parts of the larger access-management 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.
The role or status of the individual within the organization will
drive which services, application features, and information the person
is authorized to access.
-
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 PRIVACYare 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
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 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
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
The broad
challenge of forging these services should not be underestimated; however,
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 synergies for Kerberos and PKI. These synergies include
creating a common directory structure and coordinating encryption key
exchange services to enhance privacy tools.
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.
Focus
Points
Enhancing
services at Cornell will require developing new tools and rethinking
old perspectives. The challenges being addressed include
