Computer Security in the Real World

Butler W. Lampson Microsoft

Abstract

lion or two machines, and newspapers print extravagant

After thirty years of work on computer security, why

estimates of the damage it does, but these are minor an-

are almost all the systems in service today extremely vul-

noyances. There is no accurate data about the cost of fail-

nerable to attack? The main reason is that security is ex-

ures in computer security. On the one hand, most of them

pensive to set up and a nuisance to run, so people judge

are never made public for fear of embarrassment. On the

from experience how little of it they can get away with.

other, when a public incident does occur, the security ex-

Since there’s been little damage, people decide that they

perts and vendors of antivirus software that talk to the

don’t need much security. In addition, setting it up is so

media have every incentive to greatly exaggerate its costs.

complicated that it’s hardly ever done right. While we

But money talks. Many vendors of security have learned

await a catastrophe, simpler setup is the most important

to their regret that although people complain about inade-

step toward better security.

quate security, they won’t spend much money, sacrifice

In a distributed system with no central management

many features, or put up with much inconvenience in or-

like the Internet, security requires a clear story about who

der to improve it. This strongly suggests that bad security

is trusted for each step in establishing it, and why. The

is not really costing them much.

basic tool for telling this story is the “speaks for” relation

Of course, computer security is not just about com-

between principals that describes how authority is dele-

puter systems. Like any security, it is only as strong as its

gated, that is, who trusts whom. The idea is simple, and it

weakest link, and the links include the people and the

explains what’s going on in any system I know. The many

physical security of the system. Very often the easiest

different ways of encoding this relation often make it hard

way to break into a system is to bribe an insider. This

to see the underlying order.

short paper, however, is limited to computer systems.

What do we want from secure computer systems? Here is a reasonable goal: Computers are as secure as real world systems, and

1 Introduction

people believe it. Most real world systems are not very secure by the ab-

People have been working on computer system secu-

solute standard suggested above. It’s easy to break into

rity for at least 30 years. During this time there have been

someone’s house. In fact, in many places people don’t

many intellectual successes. Notable among them are the

even bother to lock their houses, although in Manhattan

subject/object access matrix model [11], access control

they may use two or three locks on the front door. It’s

lists [17], multilevel security using information flow [6,

fairly easy to steal something from a store. You need very

13] and the star-property [3], public key cryptography

little technology to forge a credit card, and it’s quite safe

[14], and cryptographic protocols [1]. In spite of these

to use a forged card at least a few times.

successes, it seems fair to say that in an absolute sense,

Why do people live with such poor security in real

the security of the hundreds of millions of deployed com-

world systems? The reason is that security is not about

puter systems is terrible: a determined and competent

perfect defenses against determined attackers. Instead, it’s

attacker could destroy most of the information on almost

about

any of these systems, or steal it from any system that is

value,

connected to a network. Even worse, the attacker could do

locks, and

this to millions of systems at once.

punishment.

On the other hand, not much harm is actually being

The bad guy balances the value of what he gains against

done by attacks on these insecure systems. Once or twice

the risk of punishment, which is the cost of punishment

a year an email virus such as “I love you” infects a mil-

times the probability of getting punished. The main thing times the probability of getting punished. The main thing

Security gets in the way of other things you want. For

bad guys who do break in are caught and punished often

software developers, security interferes with features and

enough to make a life of crime unattractive. The purpose

with time to market. This leads to such things as a widely

of locks is not to provide absolute security, but to prevent

used protocol for secure TCP/IP connections that use the

casual intrusion by raising the threshold for a break-in.

same key for every session as long as the user’s password

Well, what’s wrong with perfect defenses? The answer

stays the same [20], or an endless stream of buffer-

is simple: they cost too much. There is a good way to pro-

overrun errors in privileged programs, each one making it

tect personal belongings against determined attackers: put

possible for an attacker to take control of the system.

them in a safe deposit box. After 100 years of experience,

For users and administrators, security interferes with

banks have learned how to use steel and concrete, time

getting work done conveniently, or in some cases at all.

locks, alarms, and multiple keys to make these boxes

This is more important, since there are lot more users than

quite secure. But they are both expensive and inconven-

developers. Security setup also takes time, and it contrib-

ient. As a result, people use them only for things that are

utes nothing to useful output. Furthermore, if the setup is

seldom needed and either expensive or hard to replace.

too permissive no one will notice unless there’s an audit

Practical security balances the cost of protection and

or an attack. This leads to such things as users whose

the risk of loss, which is the cost of recovering from a loss

password is their first name, or a large company in which

times its probability. Usually the probability is fairly

more than half of the installed database servers have a

small (because the risk of punishment is high enough),

blank administrator password [9], or public access to da-

and therefore the risk of loss is also small. When the risk

tabases of credit card numbers [22, 23], or e-mail clients

is less than the cost of recovering, it’s better to accept it as

that run attachments containing arbitrary code with the

a cost of doing business (or a cost of daily living) than to

user’s privileges [4].

pay for better security. People and credit card companies

Furthermore, the Internet has made computer security

make these decisions every day.

much more difficult than it used to be. In the good old

With computers, on the other hand, security is only a

days, a computer system had a few dozen users at most,

matter of software, which is cheap to manufacture, never

all members of the same organization. It ran programs

wears out, and can’t be attacked with drills or explosives.

written in-house or by a few vendors. Information was

This makes it easy to drift into thinking that computer

moved from one computer to another by carrying tapes or

security can be perfect, or nearly so. The fact that work on

disks.

computer security has been dominated by the needs of

Today half a billion people all over the world are on

national security has made this problem worse. In this

the Internet, including you. This poses a big new set of

context the stakes are much higher and there are no police

problems.

or courts available to punish attackers, so it’s more impor-

• Attack from anywhere: Any one on the Internet can

tant not to make mistakes. Furthermore, computer secu-

take a poke at your system.

rity has been regarded as an offshoot of communication

• Sharing with anyone: On the other hand, you may

security, which is based on cryptography. Since cryptog-

want to communicate or share information with any

raphy can be nearly perfect, it’s natural to think that com-

other Internet user.

puter security can be as well.

• Automated infection: Your system, if compromised,

What’s wrong with this reasoning? It ignores two criti-

can spread the harm to many others in a few seconds.

cal facts:

• Hostile code: Code from many different sources runs

• Secure systems are complicated, hence imperfect.

on your system, usually without your knowledge if it

• Security gets in the way of other things you want.

comes from a Web page. The code might be hostile,

Software is complicated, and it’s essentially impossi-

but you can’t just isolate it, because you want it to

ble to make it perfect. Even worse, security has to be set

work for you.

up by establishing user accounts and passwords, access

• Hostile environment: A mobile device like a laptop

control lists on resources, and trust relationships between

may find itself in a hostile environment that attacks

organizations. In a world of legacy hardware and soft-

its physical security.

ware, networked computers, mobile code, and constantly

• Hostile hosts: If you own information (music or mov-

changing relationships between organizations, setup gets

ies, for example), it gets downloaded to your custom-

complicated. And it’s easy to think up scenarios in which

ers’ systems, which may be hostile and try to steal it.

you want precise control over who can do what. Features put in to address such scenarios make setup even more complicated.

1.1 Real security?

Specification:

What is it supposed to do?

Implementation: How does it do it?

The end result should not be surprising. We don’t have

Correctness:

Does it really work?

“real” security that guarantees to stop bad things from

In security they are called policy, mechanism, and as-

happening, and the main reason is that people don’t buy

surance, since it’s customary to give new names to famil-

it. They don’t buy it because the danger is small, and be-

iar concepts. Thus we have the correspondence:

cause security is a pain.

Specification Policy

• Since the danger is small, people prefer to buy fea-

Implementation Mechanism

tures. A secure system has fewer features because it

Correctness Assurance

has to be implemented correctly. This means that it

Assurance is especially important for security because

takes more time to build, so naturally it lacks the lat-

the system must withstand malicious attacks, not just or-

est features.

dinary use. Deployed systems with many happy users

• Security is a pain because it stops you from doing

often have thousands of bugs. This happens because the

things, and you have to do work to authenticate your-

system enters very few of its possible states during ordi-

self and to set it up.

nary use. Attackers, of course, try to drive the system into

A secondary reason we don’t have “real” security is

states that they can exploit, and since there are so many

that systems are complicated, and therefore both the code

bugs, this is usually quite easy.

and the setup have bugs that an attacker can exploit. This

This section briefly describes the standard ways of

is the reason that gets all the attention, but it is not the

thinking about policy and mechanism. It then discusses

heart of the problem.

assurance in more detail, since this is where security fail-

Will things get better? Certainly if there are some ma-

ures occur.

jor security catastrophes, buyers will change their priori- ties and systems will become more secure. Short of that,

2.1 Policy: Specifying security

the best we can do is to drastically simplify the parts of systems that have to do with security:

Organizations and people that use computers can de-

• Users need to have at most three categories for

scribe their needs for information security under four ma-

authorization: me, my group or company, and the

jor headings [15]:

world.

• Secrecy: controlling who gets to read information.

• Administrators need to write policies that control

• Integrity: controlling how information changes or

security settings in a uniform way, since they can’t

resources are used.

deal effectively with lots of individual cases.

• Availability: providing prompt access to information

• Everyone needs a uniform way to do end-to-end au-

and resources.

thentication and authorization across the entire Inter-

• Accountability: knowing who has had access to in-

net.

formation or resources.

Since people would rather have features than security,

They are usually trying to protect some resource

most of these things are unlikely to happen.

against danger from an attacker. The resource is usually

On the other hand, don’t forget that in the real world

either information or money. The most important dangers

security depends more on police than on locks, so detect-

are:

ing attacks, recovering from them, and punishing the bad

Vandalism or sabotage that

guys are more important than prevention.

—damages information

integrity

Section 2.3 discusses these points in more detail. For a

—disrupts service

availability

fuller account, see Bruce Schneier’s recent book [19].

Theft —of money

integrity

1.2 Outline

—of information

secrecy

Loss of privacy

secrecy

The next section gives an overview of computer secu-

Each user of computers must decide what security means

rity, highlighting matters that are important in practice.

to them. A description of the user’s needs for security is

Section 3 explains how to do Internet-wide end-to-end

called a security policy.

authentication and authorization.

Most policies include elements from all four categories, but the emphasis varies widely. Policies for computer

2 Overview of computer security

systems are usually derived from policies for security of systems that don’t involve computers. The military is

Like any computer system, a secure system can be

most concerned with secrecy, ordinary businesses with

studied under three headings: studied under three headings:

2) Bad (careless or hostile) agents, either programs or

availability. Obviously integrity is also important for na-

people, giving bad instructions to good but gullible

tional security: an intruder should not be able to change

programs.

the sailing orders for a carrier, and certainly not to cause

3) Bad agents tapping or spoofing communications.

the firing of a missile or the arming of a nuclear weapon.

Case (2) can be cascaded through several levels of gulli-

And secrecy is important in commercial applications:

ble agents. Clearly agents that might get instructions from

financial and personnel information must not be disclosed

bad agents must be prudent, or even paranoid, rather than

to outsiders. Nonetheless, the difference in emphasis re-

gullible.

mains [5].

Broadly speaking, there are four defensive strategies:

A security policy has both a positive and negative as-

1) Keep everybody out. This is complete isolation. It

pect. It might say, “Company confidential information

provides the best security, but it keeps you from us-

should be accessible only to properly authorized employ-

ing information or services from others, and from

ees”. This means two things: properly authorized employ-

providing them to others. This is impractical for all

ees should have access to the information, and other peo-

but a few applications.

ple should not have access. When people talk about secu-

2) Keep the bad guys out. It’s all right for programs

rity, the emphasis is usually on the negative aspect: keep-

inside this defense to be gullible. Code signing and

ing out the bad guy. In practice, however, the positive

firewalls do this.

aspect gets more attention, since too little access keeps

3) Let the bad guys in, but keep them from doing dam-

people from getting their work done, which draws atten-

age. Sandboxing does this, whether the traditional

tion immediately, but too much access goes undetected

kind provided by an operating system process, or the

until there’s a security audit or an obvious attack, 2 which

modern kind in a Java virtual machine. Sandboxing

hardly ever happens. This distinction between talk and

typically involves access control on resources to de-

practice is pervasive in security.

fine the holes in the sandbox. Programs accessible

This paper deals mostly with integrity, treating secrecy

from the sandbox must be paranoid; it’s hard to get

as a dual problem. It has little to say about availability,

this right.

which is a matter of keeping systems from crashing and

4) Catch the bad guys and prosecute them. Auditing and

allocating resources both fairly and cheaply. Most attacks

police do this.

on availability work by overloading systems that do too

The well-known access control model provides the

much work in deciding whether to accept a request.

framework for these strategies. In this model, a guard 3

controls the access of requests for service to valued re-

2.2 Mechanism: Implementing security

sources, which are usually encapsulated in objects.

Of course, one man’s policy is another man’s mecha-

Principal Do operation

Reference

Object nism. The informal access policy in the previous para-

monitor

graph must be elaborated considerably before it can be

Source

Request

Guard Resource

enforced by a computer system. Both the set of confidential information and the set of properly authorized em-

Authentication

Authorization

ployees must be described precisely. We can view these descriptions as more detailed policy, or as implementation

The guard’s job is to decide whether the source of the

of the informal policy.

request, called a principal, is allowed to do the operation

In fact, the implementation of security has two parts:

on the object. To decide, it uses two kinds of information:

the code and the setup or configuration. The code is the

authentication information from the left, which identifies

programs in the trusted computing base. The setup is all

the principal who made the request, and authorization

the data that controls the operations of these programs:

information from the right, which says who is allowed to

access control lists, group memberships, user passwords

do what to the object. As we shall see in section 3, there

or encryption keys, etc.

are many ways to make this division.

The job of a security implementation is to defend

The reason for separating the guard from the object is

against vulnerabilities. These take three main forms:

to keep it simple. If security is mixed up with the rest of

1) Bad (buggy or hostile) programs.

the object’s implementation, it’s much harder to be confi- dent that it’s right. The price paid for this is that in gen-

eral the decisions must be made based only on the princi-

2 The modifier “obvious” is important; an undetected attack is much

more dangerous, since the attacker can repeat it. Even worse, the victims

pal, the method of the object, and perhaps the parameters.

won’t know that they should take steps to recover, such as changing compromised plans or calling the police.

3 a “reference monitor” in the jargon

For instance, if you want a file system to enforce quotas

then the TCB adds the browser code and setup that

only for novice users, there are only two ways to do it

disables Java and other software downloads. 5

within this model:

• If the security policy for a Unix system is that users

1) Have separate methods for writing with quotas and

can read system directories, and read and write their

without, and don’t authorize novice users to write

home directories, then the TCB is roughly the hard-

without quotas.

ware, the Unix kernel, and any program that can

2) Have a separate quota object that the file system calls

write a system directory (including any that runs as

on the user’s behalf.

superuser). This is quite a lot of software. It also in-

Of course security still depends on the object to im-

cludes /etc/passwd and the permissions on system

plement its methods correctly. For instance, if a file’s

and home directories.

read method changes its data, or the write method fails

The idea of a TCB is closely related to the end-to-end

to debit the quota, or either one touches data in other files,

principle [18]—just as reliability depends only on the

the system is insecure in spite of the guard.

ends, security depends only on the TCB. In both cases,

Another model is sometimes used when secrecy in the

performance and availability isn’t guaranteed.

face of bad programs is a primary concern: the informa-

In general, it’s not easy to figure out what is in the

tion flow control model [6, 13]. This is roughly a dual of

TCB for a given security policy. Even writing the specs

the access control model, in which the guard decides

for the components is hard, as the examples may suggest.

whether information can flow to a principal.

For security to work perfectly, the specs for all the TCB components must be strong enough to enforce the

Information

Reference

monitor

Principal

policy, and each component has to satisfy its spec. This

level of assurance has seldom been attempted. Essentially always, people settle for something much weaker and

Source

Guard Sink

accept that both the specs and the implementation will be

In either model, there are three basic mechanisms for

flawed. Either way, it should be clear that a smaller TCB

implementing security. Together, they form the gold stan-

is better.

dard for security: • Authenticating principals, answering the question A good way to make defects in the TCB less harmful

is to use defense in depth, redundant mechanisms for se-

“Who said that?” or “Who is getting that informa-

curity. For example, a system might include:

tion?”. Usually principals are people, but they may also be groups, machines, or programs.

• Network level security, using a firewall.

• Authorizing access, answering the question “Who

• Operating system security, using sandboxing to iso-

late programs. This can be done by a base OS like

can do which operations on this object?”. • Auditing the decisions of the guard, so that later it’s Windows 2000 or Unix, or by a higher-level OS like

a Java VM.

possible to figure out what happened and why.

• Application level security that checks authorization

2.3 Assurance: Making security work

directly. The idea is that it will be hard for an attacker to simulta-

The unavoidable price of reliability is simplicity.

neously exploit flaws in all the levels. Defense in depth

(Hoare)

offers no guarantees, but it does seem to help in practice.

Most discussions of assurance focus on the software

What does it mean to make security work? The answer

(and occasionally the hardware), as I have done so far.

is based on the idea of a trusted computing base (TCB),

But the other important component of the TCB is all the

the collection of hardware, software, and setup informa-

setup or configuration information, the knobs and

tion on which the security of a system depends. Some

switches that tell the software what to do. In most systems

examples may help to clarify this idea. • If the security policy for the machines on a LAN is deployed today there is a lot of this information, as any-

one who has run one will know. It includes:

just that they can access the Web but no other Inter-

1) What software is installed with system privileges,

net services, and no inward access is allowed, then

and perhaps what software is installed that will run

the TCB is just the firewall (hardware, software, and

with the user’s privileges. “Software” includes not

setup) that allows outgoing port 80 TCP connections,

but no other traffic. 4 If the policy also says that no

software downloaded from the Internet should run,

This assumes that the LAN machines don’t have any other software

This assumes that there are no connections to the Internet except

that might do downloads from the Internet. Enforcing this would greatly

through the firewall.

expand the TCB in any standard operating system known to me.

just binaries, but anything executable, such as shell

them explicitly. Untrusted programs can be rejected or

scripts or macros.

sandboxed; if they are sandboxed, they need to run in a

2) The database of users, passwords (or other authenti-

completely separate world, with separate global state such

cation data), privileges, and group memberships. Of-

as user and temporary folders, history, web caches, etc.

ten services like SQL servers have their own user

There should be no communication with the trusted world

database.

except when the user explicitly copies something by hand.

3) Network information such as lists of trusted ma-

This is a bit inconvenient, but anything else is bound to be

chines.

unsafe.

4) The access controls on all the system resources: files,

Administrators still need a fairly simple story, but

services (especially those that respond to requests

they need even more the ability to handle many users and

from the network), devices, etc.

systems in a uniform way, since they can’t deal effec-

5) Doubtless many other things that I haven’t thought

tively with lots of individual cases. The way to do this is

of.

to let them define so-called security policies 7 , rules for

Although setup is much simpler than code, it is still

security settings that are applied automatically to groups

complicated, it is usually done by less skilled people, and

of machines. These should say things like:

while code is written once, setup is different for every

• Each user has read/write access to their home folder

installation. So we should expect that it’s usually wrong,

on a server, and no one else has this access.

and many studies confirm this expectation. The problem

• A user is normally a member of one workgroup,

is made worse by the fact that setup must be based on the

which has access to group home folders on all its

documentation for the software, which is usually volumi-

members’ machines and on the server.

nous, obscure, and incomplete at best. 6 See [2] for an eye-

• System folders must contain sets of files that form a

opening description of these effects in the context of fi-

vendor-approved release.

nancial cryptosystems, [16] for an account of them in the

• All executable programs must be signed by a trusted

military, and [19] for many other examples.

authority.

The only solution to this problem is to make security

These policies should usually be small variations on

setup much simpler, both for administrators and for users.

templates provided and tested by vendors, since it’s too

It’s not practical to do this by changing the base operating

hard for most administrators to invent them from scratch.

system, both because changes there are hard to carry out,

It should be easy to turn off backward compatibility with

and because some customers will insist on the fine-

old applications and network nodes, since administrators

grained control it provides. Instead, take advantage of this

can’t deal with the security issues it causes.

fine-grained control by using it as a “machine language”.

Some customers will insist on special cases. This

Define a simple model for security with a small number

means that useful exception reporting is essential. It

of settings, and then compile these into the innumerable

should be easy to report all the variations from standard

knobs and switches of the base system.

practice in a system, especially variations in the software

What form should this model take?

on a machine, and all changes from a previous set of ex-

Users need a very simple story, with about three levels

ceptions. The reports should be concise, since long ones

of security: me, my group or company, and the world,

are sure to be ignored.

with progressively less authority. Browsers classify the

To make the policies manageable, administrators need

network in this way today. The corresponding private,

to define groups of users (sometimes called “roles”) and

shared, and public data should be in three parts of the file

of resources, and then state the policies concisely in terms

system: my documents, shared documents, and public

of these groups. Ideally, groups of resources follow the

documents. This combines the security of data with where

file system structure, but there need to be other ways to

it is stored, just as the physical world does with its public

define them to take account of the baroque conventions in

bulletin boards, private houses, locked file cabinets, and

existing networks, OS’s and applications.

safe deposit boxes. It’s familiar, there’s less to set up, and

The implementation of policies is usually by compiling

it’s obvious what the security of each item is.

them into existing security settings. This means that exist-

Everything else should be handled by security policies

ing resource managers don’t have to change, and it also

that vendors or administrators provide. In particular, poli-

allows for both powerful high-level policies and efficient

cies should classify all programs as trusted or untrusted based on how they are signed, unless the user overrides

This is a lower-level example of a security specification, one that a

Of course code is also based on documentation for the programming

machine can understand, by contrast with the informal, high-level exam-

language and libraries invoked, but this is usually much better done.

ples that we saw earlier.

enforcement, just as compilers allow both powerful pro-

• Each resource object has an ACL that is a list of SIDs

gramming languages and efficient execution.

along with the access each one is permitted. When a

Developers need a type-safe language like Java; this

process calls a method of the object, a guard (usually

will eliminate a lot of bugs. Unfortunately, most of the

the OS kernel) checks that one of the SIDs in the

bugs that hurt security are in system software that talks to

process’ identity is on the ACL with the right access

the network, and it will be a while before system code is

permission. An object can read its caller’s identity

written that way.

and do its own access checking if it wants to.

They also need a development process that takes secu-

Operating systems like Unix and Windows 2000 do

rity seriously, valuing designs that make assurance easier,

security this way; they either rely on physical security or

getting them reviewed by security professionals, and re-

luck to secure the channel to the user, or use an encrypted

fusing to ship code with serious security flaws.

channel protocol like PPTP. The databases for both authentication (user names, passwords, SIDs, and groups)

3 End-to-end access control

and authorization (ACLs) are strictly local.

You might think that security on the web is more

Any problem in computer science can be solved with

global or distributed, but in fact web servers work the

another level of indirection.

(Wheeler)

same way. They usually use SSL to secure the user chan-

Secure distributed systems need a way to handle au-

nel; this also authenticates the server’s DNS name, but

thentication and authorization uniformly throughout the

users hardly ever pay any attention. Authorization is

Internet. In this section we first explain how security is

primitive, since usually the only protected resources are

done locally today, and then describe the principles that

the entire service and the private data that it keeps for

underlie a uniform end-to-end scheme.

each user. Each server farm has a separate local user database.

3.1 Local access control

There is a slight extension of this strictly local scheme, in which each system belongs to a “domain” and the au-

Most existing systems do authentication and authoriza-

thentication database is stored centrally on a domain con-

tion locally. They have a local database for user authenti-

troller. The basic idea is very simple; the following de-

cation (usually by passwords) and group membership, and

scription omits many details about how the bits are routed

a local database of authorization information, usually in

and how the secure messages are formatted.

the form of an access control list (ACL) on each resource.

Each system in the domain has a secure channel to the

In these systems access control works like this:

controller, implemented by a shared key that encrypts

• It’s assumed that the channel on which the user

messages between the two; this key is set up when the

communicates with the system is secure, that is, only

system joins the domain. To log in a user the login sys-

the user and the system can send or receive messages

tem, instead of doing the work itself, does an RPC to the

on that channel.

controller, passing in the user’s password response. The

• The system has a local database of user names and

controller does exactly what the login system did by itself

passwords (or hashes of passwords). This also re-

in the earlier scheme, and returns the user’s identity. It

cords which users are members of which groups.

also returns a token that the login system can use later to

Usually it stores an internal security identifier (SID)

reauthenticate the user to the controller. SIDs are no

for each user and group as well.

longer local to the individual system but span the domain.

• The user authenticates the channel by sending a pass-

Kerberos, Windows NT, and Passport all work this

word response (some function of the password and a

way. In Kerberos the reauthentication token is confus-

challenge) to the system. This is called “logging in”.

ingly called a “ticket-granting ticket”.

After verifying the response from the local database,

To authenticate the user to another system in the do-

the system creates a process for the user, attaches it to

main, the login system can ask the controller to forward

the channel, and assigns the user and group SIDs to it

the authentication to the target system (or it can forward

as its identity. If this process creates others, they get

the password response, an old and deprecated method). In

the same SIDs, or perhaps a subset.

Kerberos the domain controller does this by sending a

• An executable file (program image) can also have an

message called a “ticket” to the target on the secure chan-

identity (called setuid in Unix). This means that if a nel between them. 8

process is started up running this program, it gets the

program’s identity as well as the caller’s, and it can

8 This means that the controller encrypts the ticket with the key that it

switch between the two identities. This switching is

shares with the target. It actually sends the ticket to the login system,

sometimes called “impersonation”.

which passes it on to the target, but the way the bits are transmitted doesn’t affect the security. The ticket also enables a secure channel

Authentication to another domain works the same way,

2a) Alice’s smart card uses her key K Alice to sign a certifi-

except that there is another level of indirection through

cate for the temporary key K temp owned by the login

the target domain’s controller. A shared key between the

system.

two domains secures this channel. The secure communi-

2b) Alice’s login system authenticates the SSL connec-

cation is thus login system to login controller to target

tion by using K temp to sign a response to a challenge

controller to target. A further extension organizes the do-

from the Microsoft server.

mains in a tree and uses this scheme repeatedly, once for

From this example we can see that many different

each domain on the path through the common ancestor.

kinds of information contribute to the access control deci-

Unless the domains trust each other completely, each

sion:

one should have its own space of SIDs and should only be

Authenticated session keys

trusted to assign its own SIDs to a user. Otherwise any

User passwords or public keys

domain can assign any SID to any user, so that the Micro-

Delegations from one system to another

soft subsidiary in Russia can authenticate someone as Bill

Group memberships

Gates. Unfortunately Windows 2000 inter-domain se-

ACL entries.

curity today omits this precaution. See section 3.5 for

We want to do a number of things with this information:

Computer Security in the Real World