Transitive Authentication

Authentication means presenting (to your computer system) the credentials that prove your identity, such as a password, a fingerprint, or a smart card. With the advent of PAM, SASL and GSSAPI, authentication has become somewhat more manageable on UNIX/Linux systems, but we still have a long way to go before we achieve the seamless integration desired by our users, to borrow a phrase from Microsoft Windows, where such integration has been a design goal from the beginning. However, we want to co-opt what Windows does well, and to not be infested by what Windows does badly. The paradigm that I want to discuss is where the user authenticates only once, and all the servers in the system believe in that one authentication. I call this transitive authentication, because trust in the identity crosses over from the initial authentication to subsequent service activities. Other authors refer to it as single sign-on.

I'm going to use the client-server metaphor: a server is designed to provide some service, a client wants the service, to which it is entitled, and an enemy also wants the service to happen but is not entitled to it.

Authorization is the process by which the server is made aware which clients it should provide the service to. This implies that the clients each need to have an identity, and the server needs an authorization list, or some substitute, of identities that it should (or should not) serve. The process by which the server's owner decides which clients to authorize is important but is (mostly) beyond the scope of this document: our interest begins at the point where the identity appears on the authorization list.

Authentication is the process by which the the client asserts an identity and convinces the server that it is the referent of this identity. Enemies will try to steal the identity, that is, to lie to the server that the enemy is the client which is the referent of the identity, whereupon the service will be provided to the enemy.

It is fairly common for one client to act as a proxy for another; for example the boss has his secretary read his e-mail, and so the mail server needs to know that the secretary is authorized to receive, as a proxy, the services which normally would be given only to the boss.

It is also fairly common for one user to have multiple roles with differing security and reporting requirements. For example it is not a big problem if an enemy gets to read a system administrator's routine mail about office parties and the like, but if the same administrator authorizes services and establishes identities, and if the enemy were to perform those activities by stealing the administrator's identity, the organization would be in big trouble.

Authentication is particularly a problem when the client and server are on different network connected computers. In this case there is also the issue of privacy: enemies can steal information off the network, and authentication data as well as payload data is vulnerable. However, privacy is not an authentication issue and will not be discussed here except insofar as authentication is an intrinsic part of establishing a secure connection.

The phrase transitive authentication means that the client authenticates once, and when he requests subsequent services the servers are aware of and believe in the prior authentication. Generally the initial authentication takes work; at the very least it requires typing a password, showing biometric data, or insertion of a possession key. Users greatly resist authentication if it's frequent, and several services don't work at all unless the user can authenticate to them transitively.

Multi-stage transitive authentication means that the client transitively authenticates to one service, which then obtains different services using the client's credentials. This behavior is an advantage when the service is complex and has multiple parts, but if the client does not trust the server very much, it may be prudent for him to sabotage multi-stage transitive authentication.

Strong authentication cannot be faked by an enemy unless he cheats, whereas weak authentication can be broken by an enemy using data that can be stolen in the normal course of business and using a reasonable amount of computer resources. For example the traditional UNIX hashed password was strong when UNIX was first created, but is weak today, because the password file has to be publicly readable, and it takes only 15 seconds for a modern processor to crack the low-quality passwords used by typical clueless users.

An example of cheating that happens all too frequently would be stealing a secret encryption key protected by UNIX file permissions, which requires a root exploit. I use phrases like the server knows for sure or authentication cannot be faked in the sense that it takes a root exploit to trick the server and fake the authentication. On several occasions important Linux servers have been the subject of root exploits, causing major upsets and remediation efforts by the global Linux community. Although a well-maintained Linux machine is a lot more secure than a laptop that is run out of the box (not under Linux) and never updated, the administrator of a site that has something to lose should take with a grain of salt the statements below that certain mechanisms are invulnerable, and should not take for granted the security of his operating system. There is also the possibility that an authorized administrator goes over to the dark side and voluntarily lets enemies onto his system.

In a number of services the activity consists of a sequence of transactions of the same general type; e.g. successive mail messages are retrieved, or various database queries are performed. Presently client software often uses a poor substitute for transitive authentication: the client does service-specific authentication once (e.g. gives an identity and a password), and the software saves the information and sends it on every transaction. The disadvantages here are, first, the service has to do the full work of authenticating the client every time, whereas true transitive authentication could take less work. But worse, the client user needs to authenticate separately to each service, every time he starts its client software. On Microsoft Windows, every such software has a feature to remember the client's identity and password as an easily stolen registry key, and the users think Windows is far superior to UNIX because of its convenience and seamless integration. True transitive authentication would consign such monstrosities to the garbage heap where they belong.

Each of the credential types has its own issues and problems.

Password

Traditionally passwords have been up to 8 bytes long. By today's standard 64 bits of entropy is about the minimum that can be considered marginally strong. This would be 11 truly random printable bytes including punctuation, or 22 bytes of running English text (at 3 bits per byte). 28 bytes is about the maximum that a skilled user can type reliably error free every time; this would be running text, and the limit for truly random bytes must be less. In the context of credit or debit cards, some banks can only handle four decimal digits in a password, 13 bits. Thus in general passwords as credentials are not all that strong even for a conscientious user, and can be very weak if the user or the authentication system cuts corners.

Another problem is that users generally worry that they will forget the password, or have poor memorization skills and know that they will not remember it when needed, and so they write it down in a way that is easy to steal (e.g. in their wallet) or trivial to steal (e.g. on a sticky note on the monitor border). This is a particular problem for passwords that are used rarely. If one good password is used every day and transitive authentication gets the client into the rarely used service, the result is more secure than a separate password stuck to the user's monitor. Backup copies of a special password should be in an encrypted file (encrypted with a password unlikely to be forgotten, i.e. the one used for transitive authentication), in a safe, or both.

The major advantage of a password is that it costs nothing to create it (you get what you pay for) and nothing beyond machine time to collect and verify it. Also users are familiar with passwords and it's easy to educate them about passwords. Getting them to do what you tell them is another story. Generally it's easier to get your users to create, memorize and type in one good password once a day, then four or ten of them (needing to give the correct one several times an hour), which they will cut corners on, e.g. appending a different letter to each one, or just using a single (poor) password and not telling you; you wouldn't know because of salted hashes.

Biometric Data

Biometrics is seen as a panacea for authentication problems, but of course it isn't. Commonly attempted biometric data includes fingerprints, retina scans, voice recognition, and face recognition. Fingerprints are the most common, having relatively inexpensive readers (US$50 to $200) that provide reasonably informative data. Hard data is not available on how often fingerprints are similar, but it is generally believed that false matches are rare. Retina scans are probably equally reliable, but again, hard data is not widely available. Voice and face recognition are difficult to get right.

Biometric credentials of all kinds have a number of problems:

• The reader software always matches the incoming image against a set of standard images, one per known user. We would prefer if it would put out a normalized datum that is supposed to be same every time the same user is seen, as a password would be, because some authentication schemes require such a datum to use as an encryption key.

• The user's body is not static. For example, a cut finger may invalidate a fingerprint and a stuffed-up nose would invalidate a voiceprint. The authentication system must be able, without losing security, to replace the user's standard image on short notice without access to the old authentication token, and for some uses, e.g. medical, it is particularly important to provide service reliably to an injured or sick user.

• The standard image has to be persistent on the authentication server. Many setups place the authentication server in the actual reader or on the computer it's attached to -- when a match is seen, a secondary authentication token (a password) is released for network authentication. This means that both the standard image and the secondary token are very exposed to theft, and the client's image can potentially be replaced by the enemy's image. If the images are encrypted with the secret key of something, such as the administrator account, theft and fraudulent replacement are harder, but you risk locking yourself out of your machine, requiring an authorized root exploit to break in, just as the enemy would do.

• Everywhere you go, you leave fingerprints, voices, and facial images. Only retina images are not publicly available. The enemy can then construct, for example, an artificial finger, and trials of this technique show that it can be accepted by reader software. Revoking a compromised finger is hard: you can't cut it off and grow a new one, as insects and salamanders can.

Biometric credentials have their place, for example when a machine wakes from software suspend and you want unobtrusive assurance that the owner and not a casual thief is waking it up, but you cannot make them a non-bypassable element of authentication, nor rely on them for high security.

Smart Cards

The smart card is used for customer authentication in every cell phone (the SIM), is making inroads in the credit card industry, and is used by some companies for authenticating users on their computers. It acts as a key agent, holding a secret key, generally a RSA key. When a server doing authentication sends a message, client software passes it to the smart card, which encrypts or decrypts it. Smart cards have a number of security issues:

• Smart cards are connected to the client computer by physical contact in a USB or hardwired reader (ISO 7810) or by radio (RFID, ISO 14443); IRDA (tight beam infrared) is possible but I have not heard of it being used. With physical contact the owner knows which host the card is inserted in, but RFID can act at a distance and card skimming, as a thief might do, has been demonstrated.
• A small subset of the cards include a keypad so the user can enter a password every time the card is to be used. This hardware is expensive and easily damaged, and is rarely used. The password may be prudent on a credit card but prevents its use for transitive authentication that happens frequently, such as file access or message retrieval.
• Some cards want to see a password (PIN, four to six digits) from the user before they will communicate, sent over the standard interface. Again, this precludes using the smart card for generic transitive authentication. But worse, in the credit card setting the PIN would have to be provided to the merchant's equipment and to the thieves infesting his system.
• The rest of the cards are always active, so if an enemy physically steals the card or communicates with it surreptitiously (RFID only) then he can impersonate the owner. Much better would be if the card would require the partner to authenticate, e.g. with a X.509 certificate that it has been programmed to trust.

The conclusion about primary authentication mechanisms is that none of them matches the strength achievable in inter-computer communication, and all have known weaknesses and exploits against them. For the highest security, two or three factor authentication is used: a credential from more than one of these categories.

A seriously security-conscious client will put as many obstructions as possible in the way of an enemy trying to steal his identity. In particular, he will avoid transitive authentication, so if the enemy steals one identity it gives access to only one service but the others remain under the client's control. This means memorizing many passwords, using a different finger in each fingerprint reader, or carrying around a big stack of smart cards. Few users are this conscientious, nor are the services as valuable as one thinks, so the choice of convenience over security may be justified.

The original model of UNIX systems was that certain clients (human users) have accounts on a specific host, and upon logging in, that is, upon authenticating, the client may receive all the services of which that one host is capable. Thus, most daemons (individual service provider programs) need not consider authentication and authorization at all: requests can only come from within the host, and therefore can only come from authenticated users. Only the login service needs to handle authentication and authorization, which are commingled: if your authentication data (encrypted password) is in the password file, you are authorized to be on the host.

Soon administrators needed to discriminate among users: should students be allowed to print on the professors' printer? Should any user be able to read someone else's mail? Various ad-hoc schemes were developed so services could be authorized for only subsets of the users.

As tasks became more complex we had the spectacle of daemons requesting services from other daemons: for example, the cron daemon nightly runs a job that uses the database daemon to provide whatever data, and then uses the print daemon to produce hardcopy, all without human intervention.

Then network computing reared its fanged head: the network is the computer was a marketing slogan of Sun Microsystems. One or a few particular hosts could provide certain services, to which any host on the local net could get access; for example, a single machine might have a lineprinter that was shared by the whole department, or a user's home directory might reside on one host and be accessed across the net from any other host. A large can of worms was then opened:

• Identities and authorization information must be coordinated among all hosts on the local net. This is generally handled by replacing the per-host password file and related files by a distributed database such as Sun's NIS, or LDAP.

• If the enemy gained root access to a host, e.g. by hacking, or by connecting his own host to the net, he could authenticate on it as any user he pleased. The other hosts should no longer just believe when the client's host's operating system alleges that the request comes from a particular identity. In addition, there is now a concept of authenticating hosts: these belong to our group, and all others are enemies, or at least, guests with their personal rogue laptops are entitled to lesser services than our own people.

• Requests from legitimate users could arrive over the Internet from anywhere in the world, including hosts infested with viruses and keystroke loggers, mixed in with the evil sendings of millions of enemy zombie bots. Some organizations need to provide a certain degree of service even in the face of such dangers.

Since that time the Internet has exploded, and services have appeared that were undreamed of at the Beginning of Time (1970-01-01 00:00:00 +0000), and many of them have serious authentication issues which need to be discussed.

So here's a list of services, far from complete. I have not distinguished between secure and unencrypted versions of the same service, or multiple variants that provide the same general service, or remote versus local execution.

Shell Prompt

This is the ancient way of using the computer, giving commands and receiving responses over a serial channel.

Many companies rent computing services to tenants who access them over the net, never being physically present with the hardware. Services include execution, file storage, and Internet connectivity to third party customers.

Only authorized users are allowed in. At the start of the session the user must authenticate. It is common for the user to log in to a home host and then to use (or want to use) transitive authentication to get into others -- particularly hosts in a foreign realm. In the extreme case of bulk computing services all interactions go over the global internet and originate on the client's own host, on which the server cannot enforce security policies.

Graphical Desktop

A variety of programs interact with the user via a Graphical User Interface (GUI).

Authentication issues are identical to the shell prompt case, but numerous programs will originate connections to the graphics server, and enemies are not welcome because they display annoying advertising, or worse, they can get a copy of every keystroke entered including secret information.

Account Administration

Within limits imposed by the site, the user can change his own password and various other account information such as his full name, shell, and GUI type.

In traditional UNIX there is no transitive authentication usable for password changing, and so the old password must be given.

File Storage

The user's personal files reside on the file server. There are also shared files, particularly software shared (readonly) by all the users.

Filesystem access absolutely requires transitive authentication: imagine having to type a password every time a file is opened. Here's an overview of transitive authentication in traditional UNIX:

• Each file has one owner (a client user) and one group (a set of such users); when created, or later, it is configured to be readable, writable or executable by the general public, by group members, or by its owner, in any combination. Modern systems have POSIX ACLs which allow multiple users or groups to be given permission.
• UNIX systems run simultaneously multiple processes each of which is owned by one client user.
• File operations are performed by processes, and the process owner's identity governs whether the proposed operation is allowed.
• When a client logs in (authenticates) his process group leader is re-owned to his identity, which is inherited by the spawned processes that actually do the work. This is how the original authentication is propagated transitively for filesystem access.
• Many services receive their requests over UNIX domain sockets which are a variety of file. The service can then be restricted to one user or a set of them by UNIX file permissions -- provided the client and server are on the same host. UNIX domain sockets do not work across the net; network sockets have no access control by file permissions.
• There is quite a variety of network filesystems, with varying quality of transitive authentication. Sun's NFS version 2 relies on the client host's operating system to honestly report the client's identity, and relies on hostbased authentication to restrict service to hosts within the organization (or rogues which have stolen an authorized IP address). AFS uses Kerberos v4 tickets for transitive authentication, which is much more effective (though obsolete). NFS version 4 can also be configured to recognize or require Kerberos v5 tickets.

Database

There is a specialized daemon that can store and retrieve structured information, which in the interesting case is shared by a whole department or company. Generally it is important to keep this information away from unauthorized eyeballs. Modern database engines have an elaborate system of identities and authorizations which is not necessarily coordinated with the host operating system.

The database is the most underused of services, and in my opinion a major reason is the difficulty of authentication. With each database query it's necessary to include an identity and a password, and any automated script needs to have this information hardcoded or hidden in a separate file and exposed to theft. Further, maintaining database authorizations is a nightmare for the organization and mistakes lead to embarrassing information leakage. The database cries out for identities coordinated with the host system and for transitive authentication of those clients.

Printing and Media

In addition to shared printers, a site may have shared facilities for creating (burning) discs. Fax transmission is often implemented as a variant of printing.

In all of these services expensive media is consumed, and organizations with privacy or secrecy concerns know that the printed (etc.) information can easily escape from their control. Therefore they generally want to restrict and account for printing. Nonetheless, typical UNIX systems use the honor system for print requests: the standard print software fills in the client's identity with the request, and clients generally refrain from using hacked software that puts in some false identity. On the other hand, Microsoft Windows has (optionally) true transitive or password authentication for printers, and there is a Kerberos hack for CUPS on UNIX which is said to interoperate with Windows, though it is not mainstream.

E-Mail (Reading)

The system holds mail and delivers it to the user for reading.

In traditional UNIX the mail is stored in and read out of a file protected by UNIX file permissions. The problem is locking the file, so mail delivery and deletion of old messages do not happen at the same time, trashing the mailbox. Because of locking issues as well as less-than-optimal authentication, it is not practical for mail readers to modify this file across the net, and so several networked mail servers have been developed; there is also web mail, in which the organization's web server acts as a proxy, formatting the mail as a web page and sending it out to the client's web browser. For all of these services it is bad form if the client has to enter a password for each message. In the normal case mail is served to only one client, the identity to which the mail was sent.

E-Mail (Sending)

The system accepts outgoing mail from the user. The software and authentication issues are different from the reading side.

A traditional UNIX mail transfer agent (MTA) was willing to forward mail for anyone to anywhere, but with the invention of spam (unsolicited commercial e-mail) mail transfer agents need to restrict service. A typical rule is that an authenticated organization member may send mail to anywhere, whereas non-authenticated clients (or authenticated outsiders) may send to organization members but may not relay spam through the MTA. This means that client software needs to be able to authenticate to the MTA, and this authentication needs to persist over multiple outgoing messages in the session.

E-Mail (Encryption)

E-mail was one of the first internet applications and in those days neither authentication nor privacy was either practical or valued. Today is different. E-mail is handled on networks and by intermediate servers on which content scanners (Carnivore) are known to be operating, and spam (unsolicited commercial e-mail) is normally sent with a forged sender address. Thus the sender and recipient would like to know authoritatively that only the intended recipient could read the mail and that the listed sender actually did send it. Some security-conscious organizations have a policy that all work-related mail leaving the company must be at least signed, and encrypted if the recipient can handle it.

Several mail client programs offer automated digital signatures and encryption on mail. The sender and recipient need to effectively authenticate to themselves to use the feature, and transitive authentication makes the user experience much more pleasant.

Personal Information Manager

The system presents personal information such as a contact list in a form that can usefully be coordinated with the mail system and other communications media. Calendar information is partly in this category and partly in the next.

For the most part it's enough to store personal information in a file protected by UNIX file permissions. The Horde is a web-based personal information manager, webmail server, etc. Its authentication issues are the same as for any other modifiable web pages, with the exception of the calendar component.

Calendar

While normal people treat their calendar of activities as personal information, in the corporate setting it is common for a person's calendar to be visible publicly and for other people to be able to make demands on the user's time through the calendar -- making a meeting.

Clearly the person making the meeting needs to be authoritatively authenticated to the system and must be authorized to make demands on his victim.

Chat and Friends

This means computer-aided realtime interactive communication. There are a wide variety of chat services, from purely textbased to fullbore video conferences. Of particular interest, voice chat (VOIP) can be bridged to the Public Switched Telephone Network (PSTN).

The original chat service is IRC (Internet Relay Chat). It has purely honor system authentication; it was developed in 1988 when authentication was barely relevant. Jabber/XMPP is much newer and has real authentication, which can be bridged to the host operating system or can be administered separately. VOIP services generally require authentication. When a PSTN (land phone) bridge is involved it's particularly important that the computer-side client be authenticated because an outgoing call is expensive, and an incoming call is intended for a specific person.

Web Service

Users can view a vast variety of information on the web, of varying degrees of authoritativeness. The content is not only text and images, but audio, video, and software. Most web content is for public consumption. But of interest here is content restricted to particular clients. And in most cases the restricted content can be modified by the authorized client. Examples include:

• A user's e-mail messages presented (and replied to and deleted) via a webmail proxy.
• A patient's medical records which the doctor consults and updates.
• An organization's private documents such as plans, or evidence to be presented at the proper time in a lawsuit.
• Bank and brokerage account information; the client can review recent transactions and then pay bills or buy and sell securities.

Of all services protected by authentication, customers' bank accounts (and other financial services such as eBay, and stock brokerages) are one of the two which are most productive for working criminals. Users generally choose weak passwords, and more advanced authentication such as biometric or smart cards is unheard of. Users frequently fall for the blandishment of their non-UNIX web browsers to remember their passwords. Better authentication for restricted web content would really help the clients -- and the servers, who legally may be left holding the bag.

Electronic Commerce

Some webservers can provide a service for which they expect to be paid, such as commercial software, music files, or physical goods to be delivered by other means.

This is the other authenticated service that is regularly tapped into by working criminals. To make a credit card purchase from a webserver the client (or enemy) needs only to provide the information from the card (account number, client's name, expiration date, and special security code) plus the billing address. If the enemy has physical possession of the card, e.g. if it was stolen, or if a copy was made while the card was in a physical merchant's possession, the billing address is easy to find, normally being the holder's residence address, which is public record. Authentication beyond the card information would greatly reduce crime.

Wireless Networks

Both wireless and wired networks can be set up so a client host needs to authenticate before it can send packets to useful destinations. The latest security protocol, WPA, is governed by IEEE 802.11i. Authentication on Ethernet and friends is governed by IEEE 802.1x, which 802.11i uses in one of its modes.

An organization requires wireless authentication for two reasons: so clients not part of the organization, or who have not paid, cannot use the service, and so enemies cannot connect to the network and steal traffic. On wireless nets, however, security (WEP) has turned out to be less effective than promised, and the management of pre-shared keys and/or WPA authentication credentials is more difficult than expected, particularly when the clients are ad-hoc, numerous and temporary, as at a public wireless hotspot, e.g. an airport. Therefore such wireless nets generally do not use authentication or other security on the air interface; rather, if they restrict access at all, their egress router is set to reject all packets except those from specific MAC addresses, and they have a web server that handles authentication or payment, and then adds the client's MAC address to the router's ACL. It's recommended that clients on any network see to their privacy themselves, assuming that enemies could subvert any of the numerous devices that handle the data packets on their way to and from the server.

Trust

Trust agents are a unique case in authentication. To purchase trust, the client authenticates to the trust agent, generally only once during its digital lifetime, specifying its own Distinguished Name and/or the hostname of its server, and its RSA public key. If satisfied, the trust agent then provides a computer-readable certificate, invariably a X.509 certificate, signed by the agent, which states that the principal (client) named therein has the right to use the included name. The client's transaction partners are then supposed to trust the agent and believe in this certificate, thereby trusting that a connection is coming from the partner named in the certificate and not from an enemy committing fraud. (The procedure for trusting the certificate is digital and is automated; see Prime Pairs below.) An organization can act as its own trust agent, and will trust itself, but outside servers and clients generally will not trust it and will reject certificates that it signs.

Generally the trust agent handles authentication by physical mail. The client sends in copies of various non-computerized documents such as a birth or citizenship certificate or a state charter for a corporation, plus DNS records if a host is being certified.

Hashed Password

This is the original UNIX method. The client types his identity followed by the corresponding plaintext password, either in response to prompts on a serial line, or in boxes on a GUI form. (If the client is authenticating to a networked server, the plaintext password can be stolen off the wire unless an encrypted connection is used.) The server does a one-way transformation or hash of the password, and if it matches the hashed password on file, the client gets on. The hash is used because the UNIX password file has to be publicly readable, but the fastest computers of the day could not break the hash function and recover the password. Today, however, a weak password (8 random lower case letters) can be cracked in 15 seconds and a dictionary word can be found instantly. Thus organizations are trying to move to improved authentication methods, by moving the hashes into a separate nonpublic file, by requiring stronger passwords, and by not using hashes at all.

Plaintext Password

Some services keep the client's password in a file or database without any hashing or encryption. This is not secure and is only tolerable when there is no major consequence if an enemy steals all the users' passwords. An important goal for an authentication method is to put as many barriers as possible in the way of a hacker who breaks into the server.

One-Time Password

In this family of authentication mechanisms the client has a collection of passwords each of which is used only once. Thus even if the enemy has a keystroke logger on the client user's host, or steals the password off the net (assuming no encryption), the stolen password does him no good since it cannot be re-used. One method involves printing out a sheet of passwords in a secure setting. In another, a small computer generates a deterministic sequence of pseudorandom numbers at a known frequency such as once every 30 seconds, and the authentication server is also able to compute this sequence as a function of time so as to decide if the password is valid.

Shared Key

This is a variant of the plaintext password technique, frequently used on wireless networks, in which all the clients share the same password. The shared key is used to encrypt the network traffic, and hence authentication and privacy are identical. However, traffic is not private from other clients holding the key. It is very simple to authorize a client: just tell him the shared key. One disadvantage is that you can only de-authorize a client (or enemy) by getting all the other clients to change their keys. A worse disadvantage is that the more people know the secret, the more likely that an enemy can steal it.

Other services such as IPSec (a VPN or Virtual Private Network for encrypting traffic to a server-gateway) can be configured with more elaborate and stronger shared keys that are unique for each client. Again, the key functions both for authentication and for privacy. However, it takes work to create the key and to transport it securely to the partner. Thus shared keys are rarely used any more with IPSec; RSA keys are used instead. Except, a server may post publicly a shared key that anyone can use to establish a tunnel; the session initiation protocol randomizes the session key so each datastream is private from the others.

Kerberos

This authentication service is mature and is well-liked by those who use it -- specifically Microsoft Windows. Basically the user's password (after hashing) becomes the key for authenticated and encrypted communication with the Authentication Service. Again, authentication and encryption are tied together: the client announces its identity; the Authentication Service looks up its saved copy of that identity's key; and it sends back an encrypted message which that client ought to be able to decrypt. The payload, a Kerberos Ticket Granting Ticket, allows the client to transitively authenticate to any Kerberos-capable service that talks to the same server. Kerberos has several other very desirable features:

• Kerberos encryption is strong. There are currently no known exploits against the AES (Rijndael) and 3DES crypto algorithms used, nor against the Kerberos version 5 protocol itself. Thus in the absence of cheating (stealing secret keys) authentication by Kerberos cannot be faked.
• Servers also have Kerberos identities; the server's key is stored in a file protected by UNIX file permissions. Assuming this key is not stolen, the client can know authoritatively that he has connected to the correct server and not an enemy one.
• The Kerberos ticket has a configurable lifetime, typically a few hours, and no active process is needed to invalidate the ticket afterward. The ticket stays in a file, which can be shredded and deleted before the expiration time. There are separate initial and renewable lifetimes: if the ticket is unused beyond its initial life it expires, but if it is being used actively the software can automatically renew it within a longer lifetime.
• The system has strong protection against replays in which an enemy steals data off the network and retransmits it to authenticate to the same server at a later time.
• There are three major Kerberos implementations: MIT's, Heimdal, and Microsoft's. For the most part they interoperate, but there is one very ugly fly in this ointment: password changing. This is not specified in the Kerberos protocol, and each implementation has its own extension.
• There is a PAM module to set up and dispose of a user's Kerberos credentials at login, which works.
• Cross-realm trust can be configured, but system administrators will generally do this only when the two realms are tightly integrated, e.g. departments of the same company. In its absence the client needs to use ad-hoc tools to obtain a credential at the remote realm and then make it available locally when transitive authentication is needed.
• Few servers natively accept Kerberos credentials for transitive authentication, though hacks and patches are available for some. This is the biggest disadvantage of Kerberos.

GSSAPI (Generic Security Services Application Program Interface) is a framework for secure authentication between the client and the server. While there are several mechanisms available for GSSAPI, the only one in common use is Kerberos. Thus GSSAPI is often used synonymously with Kerberos, although that usage is not correct.

Prime Pairs (RSA Public Key Infrastructure)

Rivest, Shamir and Adleman (RSA) developed an algorithm in which a pair of prime numbers, plus some other parameters, functions as a private (secret) key for encrypting or decrypting messages, and their product acts as a key for the inverse transformation. This product is posted publicly and is given to all relevant partners; thus it is called the public key. If an enemy factors the public key he can regenerate the secret key. The procedure to do this is well-known and simple, if you're willing to wait long enough, but the time or resources required are outrageous for commonly used key lengths. Thus RSA-PKI is strong when used for encryption and for authentication.

It is assumed that only the actual client has access to the secret key. If an enemy gets the key, the enemy can impersonate the client.

Only the client can encrypt with the secret key; hence if the server is given a message which it can decrypt with the public key, it knows authoritatively that the message came from the client and not some random enemy. Conversely, the server can encrypt a message with the public key and be certain that only the client will be able to decrypt it.

RSA keys are an integral part of X.509 certificates. The client first generates a secret key, and multiplies the factors producing the matching public key. He then appends to it his Distinguished Name: basically, his personal name or hostname, the name of his organization, and his locality. This information is packed up in a Certificate Signing Request and sent, with authentication documents, to the trust agent (Certificate Authority). The trust agent, if satisfied with the documentation and the fee, forges the certificate by appending its own Distinguished Name and key identifier, and then making a hash over everything, encrypting it with the trust agent's secret key, and appending that. Any server trusting that agent will have installed its root certificate (public key), and can decrypt the hash, and can compute for himself what the hash should have been: should be equal. This proves that the certificate was forged by the trust agent and not an enemy, and that it has not been fraudulently altered afterward.

For authentication, an RSA key is used like this: The client sends in a X.509 certificate. The server checks its signature, and thus trusts that the key goes with the Distinguished Name in the certificate. The server sends a string of random data. The client encrypts this string using its secret key, and sends it back. The server decrypts it with the public key in the certificate; should be what was sent over. Now the server knows authoritatively that the client named in the certificate is at the other end of the connection. The server can then provide the service, if the client is authorized. This procedure is used with SSL/TLS (Secure Socket Layer or Transport Layer Security) which is used by webservers and many other services.

An important variant is used by SSH (Secure Shell): there is no X.509 certificate, but the server already has a copy of the public key, matched up with the client's identity. (It's stored in the client's home directory. SSH allows several public keys, in case one user will act as a proxy for another.) The client announces its identity first plus a key identifier, and the server retrieves the public key. From there the procedure is the same.

In systems that use cryptographic keys for authentication, generally a user's secret key is encrypted with a password, or is otherwise protected. For transitive authentication to work, the key must be available throughout the session. There are several ways to satisfy this requirement:

• SSH and GPG include programs called a key agent. If the user sets it up, when the session begins the user provides his password to the agent and it decrypts and saves in memory the secret key. (Memory is protected by UNIX file permissions; only by a root exploit can an enemy steal the key out of memory.) It is aware when the session ends, whereupon it shreds the key and exits. It can also be configured to forget the key after a time limit, after which the user must give the password again. There is a UNIX domain socket opened by the agent, with UNIX file permissions limiting its use to the owner. Client software can pass messages to the agent (from servers wanting transitive authentication) and it will encrypt or decrypt them. In the absence of the agent the client software will ask for a password every time it is used, to separately decrypt and use the secret key.

  PAM includes a module which starts the SSH agent and uses the login password to decrypt the key, assuming that the same password is used to log in and to encrypt the key. PAM can be configured so this module does actual authentication of the user, that is, if the key can be decrypted then the user gets on, but if it can't then authentication fails and the session cannot begin. In this mode, every user must have a SSH key.

• Kerberos does not use a key agent, but it does save the Ticket Granting Ticket in a file protected by UNIX file permissions. Client software can use this ticket to transitively authenticate to servers.

• Smart cards act as key agents; in fact the best such cards can create a RSA secret key and never reveal it (unless the enemy physically disassembles and destroys the smart card). The card may or may not be programmed to require a password before it will encrypt or decrypt using the secret key.

Now let's again go over the list of services and see what needs to be done to make them work with transitive authentication.

Having reviewed how to do transitive authentication on numerous specific services, let's now review the various authentication mechanisms generically.

Plain or Basic Authentication

The original authentication method was a loginID and password (Plain or Basic authentication), and all services and client software that can do authentication can do this style. But this is what we're trying to get away from, so I won't discuss it further.

X.509 Certificates

To use X.509 certificates for transitive authentication, the operating system as part of the initial login process needs to start a key agent and load the client's secret key(s) into it. This agent can then encrypt and decrypt challenge strings to do the transitive authentication, as well as participate in setting up an encrypted channel, typically TLS.

The X.509 certificate is very attractive for authentication because:

• Because of the RSA encryption and signature features, enemies are not able to create a fake one or fraudulently alter one.
• It includes a cryptographic key so that privacy of the communication can be assured.
• It includes a protocol for revoking lost or stolen certificates.
• The certificate includes indicia that uniquely identify the client.
• Trust of the certificate can either be purchased from a commercial vendor or created by the server's organization.
• It is possible for arbitrarily many certificates to be created from a single secret key.
• The trust agent (public vendor or server administrator) never sees the client's secret key, only the public key.

On the other hand, X.509 certificates have these disadvantages:

• The secret key must be available when the service begins. That means that it is either unencrypted and protected only by UNIX file permissions, or is held by a key agent. Typically the web browser acts as a key agent, for web services only. I don't know of any actually existing key agent for other services.
• Client programs (web browsers) that use TLS include idiosyncratic means to get at the certificates which are not useful for transitive authentication.
• Few services are (currently) able to authenticate by X.509 certificates: at present only those in which TLS (encrypted network channel) is an integral part, such as web service (https). However, TLS-entangled services are a major fraction of the ones for which transitive authentication is wanted.
• X.509 certificates are arcane. However, there are excellent libraries available that can deal with them.
• Multi-stage transitivity is possible in theory but is not implemented generically in the libraries.
• X.509 certificates are valid for a long time (years). Not every client checks on the certificate revocation server as it should.

Secure Shell (SSH)

For the system administrator the main activity needing transitive authentication is remote shell execution. (You install files by executing a partner-server on the remote site; you perform software package updates by executing the updater on the remote site, etc. etc.) In addition, one of the standard operating modes of the IMAP mail delivery protocol is to remotely execute a partner-server on the mail storage host. For these services SSH is ideal. Here are some of its advantages:

• It can be configured to use RSA encryption to authenticate, in which case enemies cannot fake the credential.
• It can also be configured to use Kerberos to authenticate.
• The protocol intrinsically encrypts the session.
• Both the client user and the server host mutually authenticate, preventing sending sensitive information to an impostor.
• The protocol can transport insecure datastreams over the secure tunnel. This is particularly important and useful for a graphical desktop: on the remote site a GUI program connects to a proxy X-server, and the graphical information emerges on the local host as if the GUI program were local, while sensitive keystrokes take the inverse path.
• The tunnel feature can be used to get insecure protocols through NAT, difficult firewalls, etc. Depending on the security context this may be seen as an advantage or a disadvantage.
• It can be configured to do multi-stage transitive authentication, by connecting the key agent's socket through the secure tunnel. This feature can be turned on or off for each individual connection. The Kerberos credential can also be propagated to the remote host.
• Proxy clients can be authorized without hassle. This is the preferred way to authorize a system administrator to use the root account.
• Restricted execution is supported: a daemon user can use an unencrypted secret key to execute remotely and/or as a different user (e.g. root), but only to run a prespecified program, for example to dump filesystems or to synchronize authentication tables on a backup server.

But SSH is no panacea. Here are some of its limitations:

• For essentially all of the services for which transitive authentication is desired, except remote shell execution and IMAP, client software knows nothing of SSH, and wrapper scripts (that for example start a tunnel process and then start the client with parameters directing it to the forwarded port) are useful only rarely.
• In particular, SSH is irrelevant for web service, and there are no browser plugins that might make it relevant.
• For true transitive authentication the client's secret key must be loaded into the provided key agent.
• The SSH server is often configured so RSA authentication is optional, and in this mode it is subject to frequent and resource-intensive password-guessing attacks, which eventually will succeed if your users are clueless.

Kerberos (GSSAPI)

One of the major design goals of Kerberos is transitive authentication, and when client and server software do Kerberos at all, the user experience is excellent. Kerberos has these advantages:

• All the services that you want transitive authentication for have Kerberos-capable servers and clients. Not all software supports Kerberos, but there is at least one usable client and server combination.
• Considerable care has gone into avoiding attacks of various kinds, particularly replay attacks.
• Kerberos has a long history (since 1989) and is used by major organizations. Those who have deployed it, like it.
• The authentication database can be backed up and restored (though the transparency of this backup is poor on UNIX and worse on Windows). Hot failover works between authentication servers.
• Microsoft Windows (Active Directory) uses Kerberos for authentication. A Windows domain can interoperate with a non-Microsoft server (except a kludge is needed for password changing), and vice versa.
• The client's Kerberos credentials are cached in a plain file; a key agent is not needed.
• Credentials have a limited lifetime and after that become invalid with no additional action needed.
• Proxy clients can be authorized without hassle.

On the other hand, Kerberos has these disadvantages:

• Kerberos is arcane for the system administrator.
• There are no Kerberized clients and servers for e-commerce, wireless networks, or trust agents. However, the latter two are not really relevant for transitive authentication, and the issue with e-commerce is that the banks are not in the mood to make this work -- the clients and servers are there when the banks are ready.
• Kerberos does authentication. Privacy is a separate issue. Although Kerberos is supposed to resist attacks where authentication conversations are snatched off the wire, it's recommended to avoid testing how well this works, by encrypting the whole channel.
• In Kerberos the user's password, after hashing, is the symmetric key by which the authentication server sends the credential. After a root exploit this key can be stolen from the server. The enemy can alter his own Kerberos initialization program to use the stolen key to obtain a credential identifying the victim and enabling services to be stolen. But finding a string with the same hash, that can be typed into an unhacked login service to authenticate the enemy, takes outrageous work. If a RSA scheme were used, the authentication server's database would be worthless if stolen, containing only public keys that the enemy already knows.
• Kerberos needs an authentication token which is the same every time, like a password, that it can hash into a symmetric key. Authentication credentials that don't yield such a token, like biometric credentials, are useless with Kerberos.
• Quite a number of files containing sensitive data need to persist for a considerable time and are protected only by UNIX file permissions. These include:
  • The client's credential cache.
  • The server's symmetric key -- each server needs its own identity.
  • The stash file containing the key used to encrypt the authentication server's database.
  • The backup copy of the server's database, which is not encrypted unless the administrator writes his own script to encrypt it.
• Each request for service involves a three-way conversation between the client, the server, and the KDC (authentication server). To a certain extent the resulting ticket can be cached and sent again to the same server, leaving the KDC out of the conversation.
• Database replication is weak: an hourly cron job replicating the entire file. However, the MIT Kerberos client library, if using a slave server, will retry on the master if authentication fails, making quick incremental propagation not essential -- though still something to wish for. Heimdal has incremental propagation as an experimental feature. Jimc has implemented an incremental propagation scheme for MIT Kerberos, though it is not mainstream.

Kerberos is the key to practical transitive authentication. RSA keys have their place but will not help us with most of our authentication issues.

It is possible to do transitive authentication on a lot more services than we do now. Here are lists of improvements that we should make. The first set are actually doable.

• Finish creating the Kerberos infrastructure. This includes:

  • Every user (not just a few MCG people) must have a Kerberos identity.

  • Every host including workstations (not just mail storage sites) and every service on those hosts must have a Kerberos identity. The post_jump script should be able to create these identities when Linux is installed on a new machine.

  • We need a master site and a slave on PIC, and a slave server on each Math subnet, meaning one more slave. We need to move the existing Math servers to more suitable hosts. Recommended are Sunset, Tupelo, Walnut, Malibu and Laguna.

  • We should consider, and likely set up, cross-realm trust between Math and PIC.

  • Login scripts must ensure that the Kerberos credential is initialized on each user login and shredded on logout. [This is done; it works, skipping silently if the user has no Kerberos identity.]

  • For unobtrusive initial setup, we should install the PAM module that creates a Kerberos identity upon finding it missing, using the login password.

  • Microsoft Windows should be configured to use the Math and PIC Kerberos servers. The Windows infrastructure must be authorized to add principals needed by Windows, e.g. when a new host joins the domain a host principal must be created and its symmetric key must be written in the registry of the host. We would set up a special domain to test this initially.

  • Login scripts also need to start key agent(s) for SSH and GPG. [Done, works, skipped if the user doesn't have any keys of the respective types.]

• Install or configure more Kerberized servers and clients. These include:

  • Configure SSH to use the Kerberos credential to authenticate if it is available. [This is done, and works.]

  • Include pam_krb5 in the password changing PAM stack. [Done, works.]

  • Obtain and/or write a password changing bridge from Windows to MIT Kerberos. Samba may have the feature.

  • Configure all NFS clients to use version 4 including GSSAPI (Kerberos) transitive authentication, and configure servers to accept authentication if proffered, otherwise interpreting the user as <nobody>, for readonly access to public software. [This was working on Simba but got broken in the v10.2 upgrade; need to re-do.]

  • Install and configure the Kerberized IMAP daemon.

  • Make sure GSSAPI (Kerberos) is configured and working in all our Postfix outgoing mail servers. It is supposed to be built by default.

  • Locate a Kerberos authentication patch for Thunderbird on Linux, for IMAP authentication. Make sure Outlook Express and Thunderbird on Windows can and do offer Kerberos as an auth mechanism for IMAP. Similarly, make sure that outgoing SMTP can be authenticated by Kerberos.

  • Get the GSSAPI patch for the Jabber server to compile. Find a client that will do GSSAPI.

  • Install mod_auth_kerb on all Apache webservers. Install the negotiateauth plugin for Mozilla / Firefox. Make sure Microsoft Internet Explorer is configured for Integrated Windows Authentication as a pushed-out policy.

  • Configure all restricted web content to use Kerberos authentication.

  • We could install the Kerberos patch for CUPS, but this is probably not worth the effort.

• Additional support is needed for home users.

  • Our VPN server has pretty drastic firewall rules. These will need to be relaxed to allow Kerberos authentication from home.

  • On a standalone home Windows box, can it do primary authentication to the Mathnet or PIC domain, receiving our Kerberos credential in the normal way? What holes do we need to make in our firewall to make this happen? Are we then exposed to trans-net attacks? Will we demand that the home user use a VPN?

  • On a networked remote Windows box, e.g. for our prof when visiting at another institution, can he authenticate on both that place's net and at Mathnet at the same time? Will Windows present the right credential to the two nets?

  • Similar issues for a home Linux box; we need to provide a script to automate authenticating to Mathnet, and if the remote Linux box is part of its own Kerberos realm (lacking cross-realm trust), the script needs to not wipe out the credential from the machine's home net.

  • On what terms will we allow NFSv4 mounting through our firewall?

  • Find a Windows client for NFSv4. This is for both work and home.

  • All the patches and plugins we provide automatically at Mathnet need to be documented and made available for home users to download.

• These action items would be very helpful but as a practical matter we are not likely to actually accomplish them.

  • Modify OpenVPN to use generic GSSAPI for authentication. But there's then a chicken and egg issue: if we demand that the VPN be running before sending packets over the Kerberos auth port, the remote user will not have a Kerberos credential when the VPN starts up.

  • Make Kerberos authentication work through database middleware including from Windows clients.

  • Change the Kerberos protocol to use RSA keys. Change the Authentication Server to obtain the corresponding public keys from LDAP, i.e. junk the Kerberos database entirely.

  • Create GSSAPI and/or SASL mechanisms that use X.509 certificates for authentication.

  • Locate or create a universal key agent that can serve SSH, GPG, and OpenSSL software, either storing the secret key(s) itself or acting as middleware to a smart card. Keychain is a beginning in this direction but not exactly what I have in mind.

The present so-called authentication method for credit card sales, both on the web and in person, is completely inadequate and is regularly and rampantly subverted by thieves. A major part of the problem is that the client's complete credential is made public and can be replayed to buy things. Points where the credential escapes are:

• A client making an online purchase has a keystroke logger on his computer which reports all the credit card information to its owner.

• A client responds to a request by his bank's security department to confirm his credit card information. (Phishing.)

• Merchant personnel copy the credit card while it is not visible to the client. This is particularly a risk at restaurants.

• The datafeed from the merchant to the bank is compromised. This is called skimming. Promiscuous RFID smart cards have a related attack vector.

• An online merchant's website is hacked and the credit card information is stolen, sometimes over a considerable interval of time.

Let's go over various existing authentication mechanisms for credit cards: