National Academies Press: OpenBook

Who Goes There?: Authentication Through the Lens of Privacy (2003)

Chapter: 2 Authentication in the Abstract

« Previous: 1 Introduction and Overview
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 33
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 34
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 35
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 36
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 37
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 38
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 39
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 40
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 41
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 42
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 43
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 44
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 45
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 46
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 47
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 48
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 49
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 50
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 51
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 52
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 53
Suggested Citation:"2 Authentication in the Abstract." National Research Council. 2003. Who Goes There?: Authentication Through the Lens of Privacy. Washington, DC: The National Academies Press. doi: 10.17226/10656.
×
Page 54

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

2 Authentication in the Abstract Before examining specific authentication technologies and their im- plications for privacy, a discussion of the terms and concepts them- selves is in order. Colloquial uses of the term "authentication" are occasionally misleading; for example, authentication is neither authoriza- tion nor identification. While this report does not attempt a comprehen- sive examination of privacy in the context of an information-rich world, this chapter and the next provide a foundation for thinking about authen- tication and privacy and a context for the discussions of specific technolo- gies in later chapters. WHAT IS AUTHENTICATION AND WHY IS IT DONE? Authentication is the process of establishing confidence in the truth of some claim. While this report focuses primarily on authentication in the context of information and computing systems, authentication occurs outside this realm as well, as examples throughout the text illustrate. Box 2.1, for example, presents a brief discussion of authentication in the context of absentee voting. In the context of information security, the unqualified term "authentication" is often used as shorthand to mean "verification of a claimed identity," although for the purposes of this report, a slightly more nuanced meaning is assumed. (See Chapter 1 for Another CSTB committee is examining the broad topic of privacy in the information age; the status of this project is available online at <http://www.cstb.org/project_privacy/>. 33

34 WHO GOES THERE? definitions of these and related terms.) It is possible to authenticate both human users and entities that are not humans (for example, cellular tele- phone networks in the United States directly authenticate cell phone hand- sets rather than handset users2 ), and it is possible to authenticate claims that do not relate to users' personal names (for example, an individual may claim to be tall enough to enjoy a height-restricted ride at a county fair; this claim can be verified without knowing the individual's name). Authentication is not usually an end in itself. Information systems usually authenticate users in order to satisfy security or other require- ments.3 Most commonly, security systems authenticate users in order to authorize their requests to perform actions and in order to hold them accountable for the actions that they perform. (See Figure 2.1 for a flow chart describing how the policies of the system guide whether authentica- tion, authorization, and/or accountability are needed.) In some instances authentication is unrelated to security; identification and authentication are sometimes used to create or expand a relationship between parties. For example, cookies4 are sometimes used to identify 20ften, databases can be used to map from a handset identifier to the name of the indi- vidual or organization that pays the bill for the handset. sin some cases, one such requirement is to protect classes of people Usually children' from material deemed inappropriate. In 2002, CSTB released a report that looked at this problem: Youth, Pornography, and the Internet, Washington, D.C., National Academy Press, 2002. 4Cookies are mechanisms used by Web browsers and Web servers to track visits and/or provide continuity of experience.

AUTHENTICATION IN THE ABSTRACT Policy decisions are made about authorization and accountability. / | Policy requires accountability? \ No - \ /Policy requires authorization based on individual identity or identifying attribute? No 1 Policy requires authorization based on nonidentifying attribute? \ No T \ \ \Yes )~ 35 Identify and perform individual authentication. Retrieve any attributes necessary for authorization. Perform authorization. Keep a record of individual and action. · Identify and perform individual authentication. · Retrieve any attributes necessary for authorization. · Do not keep a record of individual and action. Do not identify. Perform attribute authentication. Do not keep a record of attribute and action. · Do not identify. Do not authenticate. Do not keep a record of any kind. FIGURE 2.1 Authentication, authorization, and accountability. The necessity of authenticating the presenter's identity is based on the needs and policies of the system being accessed. If only authorization is sought by the system, the identity of the presenter may not be relevant.

36 WHO GOES THERE? individuals and track their browsing and purchasing behaviors. Such moni- toring is undertaken to bolster personalization and marketing efforts. The rest of this chapter describes elements of authentication systems and protocols at a high level in order to provide a foundation from which to examine specific authentication technologies. A description of the par- ties traditionally involved in authentication appears below, followed by a more detailed discussion of authorization and accountability. Three Parties to Authentication Authentication systems typically involve parties who play three roles in the authentication process. A "presenter" presents credentials (an in- depth discussion of the nature of credentials in general is provided in Chapter 6) issued by a third-party "issuer" to a "verifier" who wishes to determine the veracity of those credentials. In some cases, one party may play two roles. For example, the verifier and issuer roles are often combined. The issuer usually5 uses a separate system to perform an initial au- thentication of prospective credential holders prior to issuing credentials, to ensure that they are issued only to legitimate parties. Consider the case of a department of motor vehicles (DMV), which issues an important credential, the driver's license.6 The DMV often relies on another creden- tial, such as a birth certificate or a passport, to identify applicants for licenses. This reliance comes with its own risks, in that birth certificates, for example, are not strongly linked to the individuals whom they iden- tify and are so diverse in their format that it is difficult for DMV employ- ees to authenticate them. (The security and integrity problems associated with documents such as birth certificates are discussed in Chapter 6.) When analyzing different authentication systems, it is important to look at how a system implements all three roles. One needs to look at the security and privacy issues and the risks for each role and the processes that the system performs and consider who has a vested interest in the success (or failure!) of the authentication event. 5Not all credentials require presenting supplementary forms of identification prior to issuance. For example, one may acquire a free e-mail account from one of several services, which then acts as a legitimate e-mail address, anonymously. 6The original motivation for drivers licenses was to document authority to operate a motor vehicle. However, today they are used more often as a primary identity credential in many unrelated transactions, such as boarding an airliner or cashing a check. tThis is an example of the secondary use of a credential overwhelming the primary use; see Chapter 4 for more discussion of secondary uses.'

AUTHENTICATION IN THE ABSTRACT 37 Authorization can be attained by ascertaining attributes of the user, the system, or external conditions. However, ensuring accountability often requires that a particular individual be linked to a transaction.7 Authenticating to Authorize Authorization is the process of ensuring that the rules governing who may do what to which resources are obeyed. Authorization works by asking an appropriate authority (referred to herein as a "policy decision point") for an authorization decision every time an individuals submits a request to the system to access resources. If the policy decision point decides to grant the request, the individual is allowed to access the re- source; if the policy decision point decides to deny the request, the indi- vidual is not allowed access. The International Organization for Standardization (ISO) Standard 10181-3 defines a standard model and standard terminology for authori- zation in an information technology and communications context.9 In the ISO model, authorization decisions are based on authorization policy, resource attributes (such as sensitivity of the data), context attributes (such as time of day), request attributes, and subject attributes. Subject at- tributes might include the requester's name and privilege attributes, such as job role, group memberships, or security clearance. In order to make a determination, the policy decision point needs to know something about the subject it is dealing with. Since subjects might try to impersonate one another, the verifier will want to make sure that the subject attributes that it uses to make its decision have been authenti- cated. Policy decision points do not necessarily need to know anything about a subject's name or any other particular claimed identity in order to authenticate the attributes that are relevant to the policies they enforce. Two examples from Disney World illustrate this point: Anonymous accountability mechanisms exist. Consider, for example, a cash security deposit for using a set of billiard balls. If the user steals or damages the balls, he or she forfeits the deposit Which is then used to finance the purchase of a new sety. The user who returns the balls in good condition gets the deposit back. The user is held financially accountable for loss or damage to property The billiard balls' with no record of identity being required. of course, this is anonymous only to the extent that anyone participating in or witnessing the transaction may know the user s identity. 8 In this case, the individual is the initiator of an operation that involves an authorization decision. The individual is the entity whose privileges are examined to determine if he or she should be allowed to complete the requested operation. 9This definition is adopted because it is the international standard for terminology in this area.

38 WHO GOES THERE? · Disney World restricts access to some rides on the basis of physical height of the rider. The policy that enforces this restriction authenticates the rider's height (an attribute) by requiring riders to walk past a sign that has a picture of a hand positioned at the required height. If the rider's head is higher than the hand, the rider's height is authenticated, and the rider is allowed onto the ride. This system does not identify individual riders at all, but it still enforces the desired policy. It authenticates the relevant attribute (in this case, height greater than the required minimum value) of each rider. It does not collect extraneous information about the individual. · Disney World also uses a system that is designed to prevent a single-entry pass from being used by multiple users. Disney World issues each passholder a card at the time the pass is purchased. The name of the passholder is not recorded on the card, and, in fact, the card can be trans- ferred freely from user to user until the first time it is used. At the time of first use, information about the passholder's finger geometry (not related to the passholder's fingerprint) is linked to the card. Any time after the first use of the pass, the person presenting the pass must authenticate ownership of the pass using a finger geometry verification check (by holding his or her hand up to a measuring device). If the check fails, the person presenting the pass is denied access to the park. Finger geometry is not distinctive enough to identify the passholder uniquely; therefore, verifying finger geometry does not provide sufficient certainty for accountability (see below). However, finger geometry varies sufficiently from person to person so that a randomly selected individual who is not the passholder is not likely to match the finger geometry linked to the card. Therefore, this system works well enough to prevent multiple users from using the same pass in most cases an acceptable level of risk, given what the system is protecting. This system uses a loose form of biometric authentication to protect against fraud (here defined as multiple users) without collecting information that identifies the legiti- mate owner of the pass. (See Chapter 5 for further details on various biometrics technologies.) Authenticating to Hold Accountable Accountability is the ability to associate a consequence with a past action of an individual. To hold individuals accountable it must be pos- sible retrospectively to tie them to the actions or events for which ac- countability is desired, or to be able independently to detect and respond to inappropriate behavior. Especially for purposes of after-the-fact ac- countability, information from the authentication event must unambigu- ously identify one and only one individual, who will be held responsible

AUTHENTICATION IN THE ABSTRACT 39 for the event.l° An authentication event that identifies a group of people but not a single individual within the group cannot easily support indi- vidual accountability.ll Accountability usually eventually requires personal identification of individuals (unlike authorization, which can often be done without iden- tifying individuals). Accountability processes are used to generate the evidence needed to punish the guilty when something is done in viola- tion of policy or law. Even so, the identifiers used need not always be in the form of the name of the individual or even something that can be used to find the individual of interest; they only need to be able to confirm that a suspect is the individual actually responsible. What is needed for this purpose is something that can be linked to the individual with some level of assurance. A fingerprint or DNA sample, for example, can be used to establish accountability. Neither of these two types of evidence names the individual nor does either provide a mechanism for finding him or her but both provide means to verify (after the individual is located through other means) that the suspect probably is or is not the account- able individual. Accountability in information systems usually works by allowing a process for observing and recording users' actions in a log. The log can later be searched (as part of an investigation into wrongdoing, for example).l2 While authentication (whether of an individual's name or of an at- tribute) is often necessary for accountability, authentication by itself is not always sufficient to support accountability. Authentication is a key to attributing actions and allocating punishments to the correct individuals. Din some cases, it may be possible to impose a certain kind of "accountability" without requiring the authentication of an identity. For example, some technologies are designed to prevent unauthorized duplication of digital media (such as CDs). In instances in which this technology works, there is no accountability that requires identity authentication; instead the CD (or the machine) might just stop functioning. 1lIt is important to note that accountability is not the only mechanism for righting wrongs. Legal and other systems sometimes address wrongs without directly holding accountable the individual responsible for the wrong for example, by providing for redress. Accountability and redress are separate concepts. One can have redress for a harm without holding the perpetrator of the harm accountable. For example, in disputes involving alleged violations of copyright, the Digital Millennium Copyright Act of 1998 provides for redress by providing copyright holders with a method of having material removed from Web sites. This form of redress prevents future harm but does not punish previous bad acts. 12Note that this is conceptually distinct from the notion of auditing for the purposes of system maintenance and/or troubleshooting. Auditing may or may not require recording individualized user activity. While the mechanisms can be similar, the purposes of these two kinds of log-based monitoring are distinct.

40 WHO GOES THERE? If identities in the log are not well authenticated, a user who falls under suspicion of wrongdoing will dispute the validity of the log by claiming that the actions attributed to him or her were really performed by some- one else someone else who fooled the authentication system and imper- sonated the suspect.~3 Accountability is not always a requirement in information systems (or elsewhere), and even where it is, collecting and storing information about individuals is not always necessary for accountability. In order to establish accountability, systems often collect and store information about who did what, where, and how. For example, financial markets support payment mechanisms with and without accountability. In a cash-for- goods transaction, the buyer and seller often divulge no information to one another. In contrast, credit card transactions are information-rich: A record is created that captures both the identity of each party and the details of the transaction. Credit records support accountability by uniquely mapping to an individual (except perhaps in the case of family members who share a single account and thus share each other's accountability or in situations involving powers of attorney) or to an organization. The inability to reconstruct a transaction from records retrospectively (that is, one may not be able to identify the other party or to prove that the transaction occurred) is the norm in cash transactions. This is at least in part due to the fact that the exchange is complete when the parties sepa- rate (goods have been exchanged for cash), so there is little need to make provisions for future accountability for payment. In a credit transaction, by contrast, one party has goods, another has a promise of payment, and a third has a record of the transaction directing the purchaser to make payment. The incomplete nature of the transfer and the ability of a buyer or seller to deny or fabricate an exchange have resulted in the creation of identity-based audit logs that support accountability. These are needed in order to complete the payment and therefore the transaction as a whole. These examples illustrate that anonymous, instantaneous liability- transfer mechanisms (such as cash) can reduce or even eliminate the need for accountability in some transaction-based systems. An example of an anonymous liability-transfer mechanism that is not instantaneous is a security deposit. A security deposit is an up-front payment equal to or exceeding the value of an item that is rented or borrowed (for example, a Nowhere authentication of individual identities is required, the individual identities in the log will not necessarily be easily accessible to just anyone who looks into the log. It is possible to design an audit system that puts a nonidentifying unique identifier "essentially a pseudonym, sometimes called an audit ID) into the log and allows specially authorized users to link these audit IDs to personal identities only after due-process rules have been observed.

AUTHENTICATION IN THE ABSTRACT 41 cash deposit that is made for the billiard balls used at a bar or for checking in at a hotel without a credit card). Cash is an extremely efficient mode of commerce in part because it does not require us to know or seek to know anything about the party on the other side of the transaction.l4 Other forms of payment are less effi- cient, because creditworthiness, identity, or other attributes of one or more parties to the transaction need to be established before the transaction is completed, records of the transaction need to be kept, and settlement procedures need to be executed. This suggests that where accountability (and therefore authentication) can be dispensed with, transactions can be made simultaneously more efficient and more protective of privacy.l5 WHAT DO WE AUTHENTICATE? Earlier, authentication was defined as the process of establishing con- fidence in the truth of some claim, often a claimed identity. The next obvious question is, What kinds of claims are verified? Individuals might make a variety of claims that would help to support the goals of authori- zation and accountability. When the goal that motivates authentication is to hold an individual accountable, it is useful to verify some piece of information that is strongly linked to or that uniquely identifies the individual for example, an iden- tifier (such as a personal name) or a very distinctive attribute (such as a DNA profile). It may also be useful in these cases to verify some piece of information that will help contact or locate the individual for example, a residence address or e-mail address. When the goal that motivates authentication is to authorize individu- als' actions, it is useful to verify some piece of information that will be useful to the policy decision point in making its authorization decision. This information may be a property of the individual (such as the fact that an individual has paid for entrance to an event), or it may be a statement about the individual by some authoritative party (such as when a credit transaction is authorized by the issuing bank). 14If the cash itself is authentic, then we trust in the issuing government to make good the promise of payment, perhaps in precious metal, and we trust that there will always be an exchange market for precious metal. Most currencies now skip the precious-metal connec- tion; governments back the currency instead with the direct promise of market stability. 150f course, providing records of transactions can be important for reasons other than accountability. For example, information systems often maintain transaction logs for the purpose of diagnosing and correcting system failures. In addition, the "anonymity" of cash creates challenges for law enforcement.

42 WHO GOES THERE? Presentation of a passport to an immigration agent authenticates the passport holder for the purpose of authorizing entry into a country. The individual presents the passport, which claims his or her name and coun- try of residence. The immigration agent verifies the claim by examining the picture in the passport to verify that the individual is the legitimate holder of the passport and possibly by doing some kind of authenticity check on the passport document itself. In summary, authentication is the process of verifying a claim. A claim asserts that an individual has some attribute. An attribute may be an identifier, a property, or a statement about the individual by a third party. Below is a discussion of these various kinds of attributes. Identifiers Recall from Chapter 1 that an identifier points to an individual. An identifier could be a name, a serial number, or some other pointer to the entity being identified. An identifier can be strong in the sense that it allows unique mapping to a specific individual in a population, or it can be weak, in that it could be correctly applied to more than one individual in a population. Whether an identifier is strong or weak will depend upon the size of the population and the distinctiveness of the identifying attribute. However, multiple weak identifiers can, when combined, uniquely identify a specific individual and therefore serve as the func- tional equivalent of a single strong (unique) identifier. Multiple weak identifiers may lead to unique identification. Some identifiers, such as pseudonyms, require a list of correspondences between pseudonyms and individuals (often called a look-up table) for unique mapping back to an individual, thus allowing only the holder of the list to identify the action with the individual. Some identifiers, such as common names, allow any observer to map an action back to an individual (though not always with 100 percent confidence). Authorization, in contrast, may require no iden- tifier at all. Systems that use multiple weak identifiers can be made just as secure for the verifier as systems that use, for example, personal names, but the former may have the privacy advantage of not as easily identify- )6Interestingly, while the use of multiple weak identifiers may enable a certain level of security through authentication, these identifiers can also be used to create unforeseen linkages and therefore pose a risk to privacy (even while, individually, very weak identifi- ers might pose a minimal risk to privacy). Work done by Latanya Sweeney suggests that very little information is needed to uniquely identify a particular individual in even an ostensibly anonymized database, suggesting that creating linkages between databases- even without biometric data tying individuals to their data may not be difficult (see <http: / / lab.privacy. cs. cmu.edu /people /sweeney/ confidentiality.html>~.

AUTHENTICATION IN THE ABSTRACT 43 ing individuals to third parties who do not have access to the information that links the weak identifiers. A unique identifier refers unambiguously to one and only one indi- vidual in the population. Legal personal names are commonly used iden- tifiers for human individuals, despite the fact that they are not usually unique except in very small populations. In this case, additional identify- ing information, perhaps limiting the population, is often implicitly re- quired for identification (e.g.,"Bob Smith of Centerville"~. However, indi- viduals can be identified by things other than names. Many corporate systems, for example, use employee ID numbers rather than personal names as identifiers. In large organizations, this is commonly done be- cause ID numbers (unlike personal names) are unique. Names that are not personal names (such as pseudonyms and e-mail addresses) can also be used as identifiers. An entity issuing or relying on such an identifier may wish to correlate it to a unique individual; indi- viduals using these identifiers may wish to prevent such correlation. Iden- tifiers that are not personal names can be designed to protect individuals' privacy by limiting or preventing correlation of the identifier to a specific individual by limiting access to the look-up table (in a way that personal names cannot). In general, the strength of the identification system is related to how distinctive the combined identifiers are across the population in question. "Bob Smith" might be a strong identifier in Centerville, but quite weak across the population of the entire country. Identifying a person uniquely across the entire population of the United States might require a name and considerable additional data, such as a phone or Social Security number. Attributes Authorization policies are often based on attributes that do not inher- ently identify an individual. An attribute can be inherent (height, for example) or assigned (vice president, for example); it can be permanent or dynamic. As an example, access to confidential company information in a corporate intranet may be granted to any employee of the corporation. The relevant attribute would be status as an employee. Some attributes can be granted to individuals with virtually no claim on the part of the individual being authorized. The most common use of this type of attribute is in granting guest access to a system. Since by definition anyone can be a guest, it is unnecessary to authenticate an individual's identity in order to determine that he or she is entitled to the guest attribute. Obviously, this attribute is not very discriminating, so one might ask why it is used at all. The answer is that authorization systems are normally set up to authorize every access to every resource-

44 WHO GOES THERE? so even publicly available resources need to be governed by a policy that says, "grant access to the public," where the public is defined as anyone who has the guest attribute. Some attributes can be observed directly by the information system. For example, an individual's location can be determined if the system can tell that the individual is using a terminal that is known to be on the business's premises. Gender and race are in many instances observable attributes. Authentication of such attributes does not require prior au- thentication of an identifier for the individual. It is sometimes possible to manifest attributes that ordinarily would not be directly observable. Bars do this when they stamp the hands of patrons who are older than the minimum legal drinking age; this allows people of legal age to enter and leave the bar without having to reauthenticate their age by showing ID cards each time they enter. Some attributes cannot be observed directly by information systems. For example, an individual's employer or department number cannot be determined by examining the individual or his or her surroundings. Sys- tems normally deal with such attributes by creating a process for register- ing individuals, assigning attributes to registered individuals, storing each individual's assigned properties, and retrieving an individual's attributes when needed for an authorization decision. In order to retrieve a specific individual's attributes from storage (or from a third party), the system must have an identifier for the individual, which it can use to refer to the individual whose attributes it wants to look up. Furthermore, this identifier must be authenticated, so that the system can have confidence that it is talking not to an impostor but in fact to the individual whose attributes it is going to look up. Systems usually require individuals to authenticate themselves (us- ing a unique identifier) and subsequently to be assigned other attributes that are then stored in an attribute database. Then, at some later time, the individual reauthenticates the same unique identifier to the system, and some observer function in the system uses the unique identifier to look up the assigned attributes in the database and to make an access decision. Statements A statement records a belief or claim about an individual by an iden- tifiable party.l7 Authorization decisions may in some cases be based on attestations or assertions of authorities. For example, a bank's decision to 17That is, it is possible to determine who the party is and hence whether the party is authoritative for the statement.

AUTHENTICATION IN THE ABSTRACT 45 extend credit to an individual may be based on a credit rating asserted by a credit agency. The individual's credit rating is an attribute that is as- signed by the credit agency to the individual. In this case, the party making the statement is an authority, and the party that uses the state- ment to make an authorization decision is a relying party. Third-party assertions generally provide attribute information that cannot be directly observed by the relying party. In the example above, an information system cannot observe an individual's credit rating it must instead query the credit agency to provide the rating. In order to retrieve accurately an individual's attributes from the authority, the rely- ing party must have an appropriate identifier for the individual, which it can correlate to the individual's identity and corresponding statements in its database. HOW DO WE AUTHENTICATE? John Locke, tinguished two identity: in his "Essay Concerning Human Understanding," dis- types of identity physical identity and psychological [T]he identity of the same man consists . . . in nothing but a participa- tion of the same continued life, by constantly fleeting particles of matter, in succession vitally united to the same organized body. Any substance vitally united to the present thinking being is a part of that very same self which now is; anything united to it by a conscious- ness of former actions, makes also a part of the same self, which is the same both then and now. Person, as I take it, is the name for this self. Wherever a man finds what he calls himself, there, I think, another may say is the same person. It is by the consciousness it has of its present thoughts and actions that it [i.e., a person] is self to itself now, and so will be the same self, as far as the same consciousness can extend to actions past or to come; and would be by distance of time, or change of substance, no more two persons, than a man be two men by wearing other clothes to-day than he did yesterday. Locke also identifies the association of a set of past actions with a present actor as being critical to the notion of personal identity, and he associates identity with law and accountability: [A]s to this point of being the same self, it matters not whether this present self be made up of the same or other substances I being as Upjohn Locke. An Essay on Human Understanding, Part II, Chapter 27. 1690. Available online at <http://www.ilt.columbia.edu/publications/ locke_understanding.html>.

46 WHO GOES THERE? much concerned, and as justly accountable for any action that was done a thousand years since, appropriated to me now by this self-conscious- ness, as I am for what I did the last moment. In this personal identity is founded all the right and justice of reward and punishment. The distinction between physical and psychological identity is critical to the understanding of authentication systems, because authentication systems use features of both types of identity, and they differ in their properties and application depending on which type of identity they au- thenticate. Password- and key-based authentication systems, for example, can be used to make individuals express intent (because such systems authenticate psychological identity), but they are prone to the theft of authentication secrets. Some biometrics, on the other hand, can be used to identify individuals without those individuals' active participation and awareness, so care needs to be taken when using biometrics in authentica- tion systems designed to ensure accountability. Some authentication systems also authenticate claims not on the basis of physical or psychological identity but instead on the basis of the pos- session of an artifact. Thus Were are Free generic approaches to authentication. They are often described as "something you know," "something you have," and "something you are."l9 The properties of each approach are discussed below. Authentication systems often combine two or all three of these ap- proaches. This is what is done at a typical automated teller machine (ATM). Both "something you have" (the bankcard) and "something you know" the personal identification number or PIN are required to access account information or to make changes to the account. A combination of approaches (sometimes referred to as multifactor authentication) gener- ally provides more security than do single approaches alone, because the strengths of one approach can be used to compensate for the weaknesses of another. At the same time, depending on implementation and other systems choices, multifactor authentication may raise more privacy con- siderations than single-factor authentication. 19The National Institute of Standards and Technology articulated these principles as related to computer security in the 1970s (D.E. Raphael and J.R. Young, Automated Personal Identification, SRI International, 1974; National Bureau of Standards, Evaluation Techniques for Human Identification, FIPSPUB48, April 1977~.

AUTHENTICATION IN THE ABSTRACT 47 Authenticating Physical Identity Authentication systems based on physical characteristics (something you are) authenticate individuals by observing physical characteristics of the body of me individual; these systems are often called biometric au~en- tication systems. The physical characteristics used differ from system to system; some use fingerprints, others use the geometry of me human hand, others use me pattern of tissues in the iris of the eye, and so on. A person wishing to be authenticated by means of a biometric mecha- nism need not remember anything, nor does he or she need to remember to carry an object. Unlike passwords, properly chosen biometrics cannot be readily shared in normal use.20 Authenticating Psychological Identity Authentication systems based on covert knowledge (something you know) authenticate users by requiring the individual to recite a secret (sometimes personal information). These systems rely on what Locke would consider the identity of a "person" that is, they depend on the psychological continuity of a person's memory.21 The benefit of this 20While a number of effective techniques for attacking biometric systems have been pub- lished, the majority of users, who are neither malicious nor technologically sophisticated, will not use these techniques to circumvent protections against sharing for casual reasons- e.g., to share biometric identifiers with family members, colleagues, and so on (T. Matsumoto, H. Matsumoto, K. Yamada, and S. Hoshino, "Impact of Artificial Gummy Fingers on Fingerprint Systems," Proceedings of SPIE 4677 danuary 2002), available online at <http: / /research.nii.ac.jp /kaken-johogaku/reports /H13_overview /A04-00-l .pdf>; L. Thalheim, J. Krissler, and P. Ziegler, "Biometric Access Protection Devices and Their Pro- grams Put to the Test," C't Magazine 11 (May 21, 2002~:114, available online at <http:// www.heise.de/ct/english/02/11/114>; T. van der Putte and J. Kenning, "Biometrical Fin- gerprint Recognition: Don't Get Your Fingers Burned," Proceeding of the IFIP TC8/WG8.8 Fourth Working Conference on Smart Card Research and Advanced Applications, Kluwer Aca- demic Press, 2000, pp. 289-303, available online at <http://www.keuning.com/biometry/ Biometrical_Fingerprint_Recognition.pdf>; and D. Blackburn, M. Bone, P. Grother, and J. Phillips, Facial Recognition Vendor Test 2000: Evaluation Report, U.S. Department of De- fense, January 2001, available online at <www.frvt.org>~. 21Another way of thinking about identity continuity is to consider the case where two different names (or instances of the same name) correspond to the same principal (this is known in the distributed systems literature as an "indirect name" or "symbolic linked. The classic example comes from the registration of title to real estate. It is very common that someone who wishes to sell a house uses a name different from his or her name at the time the house was purchased: the person might have changed their name in marrying, or after a criminal conviction. A classic identity problem is knowing that the "Mrs. Janet Rogers" wishing to sell property at 1423 Constitution Avenue is the same person as the "Miss Janet Foster Smith" who purchased it 11 years ago.

48 WHO GOES THERE? approach is that it does not require a person to remember to carry a particular object and is in general one of the simplest forms of authentica- tion. However, what is known can be forgotten, shared, guessed, or just plain stolen by being overheard or from the noting of written reminders. There are at least two types of covert knowledge: synthetic secrets and private secrets. Synthetic secrets are items of information created specifically for the purpose of authentication; they typically have no relation to characteris- tics of the individual or to events in the (human) individual's life. Pass- words are a type of synthetic secret (when used properly) and the classic example of the "something you know" approach to authentication. The principal problem with using a synthetic secret for authentication is that because it is unrelated to the individual's life in any meaningful way, it is often difficult to remember. A joke in the security community illustrates the point: "There are two rules for choosing a good password: (1) pick something you can't remember and (2) don't write it down." This problem arises because synthetic secrets that are easy to remember are also usually easy for others to discover or guess.22 Private secrets are items of information that are so intimately associ- ated with an individual or with events in the (human) individual's life that no other person (or few others) would be expected to know about them. The use of private secrets for authentication causes several problems. People resist the use of private secrets for authentication on the grounds that they are private and should not have to be revealed to third parties (even to third parties who wish to authenticate us). Private secrets are rarely completely private.23 This leads to another problem: Any item of information that is used as a private secret to authenticate an individual will typically be shared with all the people and organizations that want to authenticate the individual (technical measures exist that could prevent sharing this, but they are not widely used). Each party who authenticates the individual therefore comes to know the information that is supposed to be a private secret, and thus the information becomes less private and less secret as time goes by. 22One approach that makes passwords more difficult to share or guess is to require people to memorize images instead of sequences of words, letters, numbers, and/or charac- ters. See "In a User-friendly World, One Picture's Worth 1,000 Passwords: Image-Driven Log-ons Are Easier to Use and More Secure, High-Tech Researchers Claim," by Michael J. Kennedy in the Los Angeles Times, June 4, 2002, for a description of this technology and some of the companies exploring its use. 23For example, a DMV and its clerks can find out driver's license numbers. An individual's mother knows her own maiden name, and so do other members of the family. Many people know or can find out Social Security numbers.

AUTHENTICATION IN THE ABSTRACT 49 Not only do these problems compromise the individual's privacy, but they also gradually destroy the usefulness of the information as an au- thenticator. When the information's value as an authenticator has been substantially degraded, another piece of (private) information will have to be chosen as a new basis for the private-secret authentication process. If this sequence of events is repeated enough times, many of the individual's private secrets will have been revealed to large numbers of other parties. The individual's privacy will have been put at considerable risk, as will the ability of other parties to authenticate the individual. Social Security numbers are an excellent case study in this phenomenon, as a recent incident involving the Princeton University admissions office illustrates. Both Princeton University and Yale University use Social Se- curity numbers as student identifiers. Yale's admissions office used the Social Security number as an authentication key to allow students to ac- cess the status of their applications for admission via a Web browser. A member of the Princeton University admissions office staff discovered this and apparently used Social Security numbers obtained from the records of applicants to Princeton in order to access the Yale admissions Web site and learn about Yale's admissions decisions.24 Authenticating Possession of an Artifact Another traditional approach to authentication is the possession of a unique object. A typical house key is an example of the "something you have" approach. (Box 2.2 describes authentication by means of a car key fob.) The object should be hard to duplicate, at least by simple observa- tion by a third party. In other words, it is possible to duplicate a house key, but merely observing a key being used does not allow the observer to duplicate the key. The object that is possessed may have a range of functionality. It may be as simple as a traditional house key, whose shape defines it. It may be a credit card with raised lettering and a magnetic stripe for storing infor- mation. It may also be a smart card, with an embedded processor that may be used to store information or to act as a cryptographic processor. These different types of objects have different levels of resistance to tampering and duplication. A house key is readily duplicated, if desired, by the person in possession of it. A credit card also may be duplicated, provided the person in possession of the card has the appropriate equip- ment. Smart cards, particularly those that perform cryptographic opera- 24See "Ivy Imbroglio: Princelon Says It Spied on Yale," Wall Street Journal, July 26, 2002, p. Bl.

50 WHO GOES THERE? lions, are in theory harder to duplicate, because they do not ever disclose during normal operation the secret information that would be required to duplicate them. The "something you have" approach has the advantage that the holder does not need to remember a password. The object that is used can be designed to be hard to copy, so it cannot be readily used by more than one person at a time, although it could be loaned (in which case the original person loses access to it while it is on loan). However, objects can easily be lost or stolen, and sometimes people are not in a position to carry an item when they want to use a system. IDENTIFICATION The processes of authentication and identification are related but dis- tinct. While the former may require the verifying party to authenticate an identifier that refers to the individual, the identification of an individual is distinct from the authentication of the individual's claimed identity. Some authentication technologies (particularly biometric technologies) are used in both processes. Identification associates an identifier with an indi- vidual without the requirement of a claim on the part of the subject. More specifically, identifying an individual refers to the process of examining and/or interrogating an individual (usually an individual who has been encountered before) with the objective of determining which

AUTHENTICATION IN THE ABSTRACT 51 identifier refers to that individual. In contrast, authenticating an identi- fier refers to the process of verifying the linkage between an identifier (usually claimed by the individual, but sometimes observed) and the individual. THE RELATIONSHIP BETWEEN AUTHENTICATION AND IDENTIFICATION Given that authentication and identification are distinct but related concepts, it is important to understand the interplay between them. While authentication for accountability almost always eventually requires iden- tifying an individual at some point (as discussed previously), authentica- tion for authorization does not always require this. In the first place, authorization does not always require authentication. When authoriza- tion does require authentication, as discussed previously, it does not always require individual authentication. Even when authorization requires individual authentication, it often does not require the authenti- cated identifier to be a personal name. The common use of credit cards is an example. The credit card number is the unique identifier. If the card has not been reported lost or stolen, it is assumed that the holder of the card is authorized to use it. For credit card purchases made by phone or over the Internet during which the physical holding of the card cannot be observed, a secondary piece of information from the card, such as an expiration date or additional code number, is requested.25 It is essential to develop authentication systems whose strength (and often therefore whose intrusiveness into privacy) is in line with the secu- rity needs of and threats to the resources being protected. In some cases it may be appropriate to require users to forgo some privacy when they are authenticated for purposes of accessing very sensitive or very valuable resources. Note that the information being protected may itself be pri- vacy-sensitive, and thus may merit strong authentication on that basis alone. Recommendation 2.1. The strength of the authentication sys- tem employed in any system should be commensurate with the value of the resources (information or material) being protected. Authorization systems usually do identify individuals' personal names, even when it is not necessary to do so to meet the required secu- 250f course, the second piece of information from the card is valid the first time it is ever used and becomes less valuable with each additional use.

52 WHO GOES THERE? rity goals. The main reason for this is convenience: Even for authoriza- tion policies that do not use them directly, personal names are familiar, sufficiently differentiable to discriminate among user populations of mod- est size, and convenient to use as a way to look up other individual attributes. They are therefore often used as the "label" on the "file folder" that contains the individual's other attributes. Of course, some authoriza- tion policies actually do require the use of personal names, and some authorization systems collect personal names up-front that is, preven- tively instead of waiting until it is clear that personal names are neces- sary before collecting them. Finding 2.1. Authorization does not always require individual authentication or identification, but most existing authoriza- tion systems perform one of these functions anyway. Similarly, a requirement for authentication does not always imply that accountability is needed, but many authentication systems gen- erate and store information as though it were. Recommendation 2.2. Systems that demand authentication for purposes other than accountability, and that do not themselves require accountability, should not collect accountability infor- mation. Recommendation 2.3. Individual authentication should not be performed if authorization based on nonidentifying attributes will suffice. Where appropriate, authorization technologies and systems that use only nonidentifying attributes should be used in lieu of individual authentication technologies. When indi- vidual authentication is required, the system should be subject to the guidelines in Recommendation 3.2 (see Chapter 3~. The CSTB report IDs- Not That Easy raised a number of questions that should be addressed before the implementation of any large-scale identity system. These same questions apply generally to authentication systems, given that authentication and identity are often closely con- nected. While smaller-scale authentication systems may imply decreased urgency (that is, a system to restrict access to a hotel swimming pool, in which the attribute necessary for authorization is "current hotel guest," may require less rigorous attention to these questions than a system that would track the enrollment status of all foreign students in the United States on the basis of their visas or other IDs), the principles outlined in IDs Not That Easy still hold, especially with regard to understanding the goals of the system and minimizing unnecessary data collection and re-

AUTHENTICATION IN THE ABSTRACT 53 tension. The questions are reprinted here from IDs Not That Easy26 for reference. · What is the purpose of the system? Possible purposes of an identity system include expediting and/or tracking travel; prospectively moni- toring individuals' activities in order to detect suspicious acts; retrospec- tively identifying perpetrators of crimes. · What is the scope of the population to whom an "ID" would be issued and, presumably, recorded in the system? How would the identities of these individuals be authenticated? · What is the scope of the data that would be gathered about individu- als participating in the system and correlated with their system identity? "Identification systems," despite the name, often do much more than just identify individuals; many identity systems use IDs as keys to a much larger collection of data. Are these data identity data only (and what is meant by identity data)? Or are other data collected, stored, and/or ana- lyzed as well? With what confidence would the accuracy and quality of this data be established and subsequently determined? · Who would be the userts) of the system (as opposed to those who would participate in the system by having an ID)? If the public sector or government will be the primary user, what parts of the government will be users, in what contexts, and with what constraints? In what settings in the public sphere would such a system be used? Would state and local governments have access to the system? Would the private sector be allowed to use the system? What entities in the private sector would be allowed to use the system? Who could contribute, view, and/or edit data in the system? · What types of use would be allowed? Who would be able to ask for an ID, and under what circumstances? Assuming that there are datasets associated with an individual's identity, what types of queries would be permitted (e.g., "Is this person allowed to travel?" "Does this person have a criminal record?". Beyond simple queries, would analysis and data mining of the information collected be permitted? If so, who would be allowed to do such analysis and for what purposes? · Would participation in and/or identification by the system be vol- untary or mandatory? In addition, would participants have to be aware of or consent to having their IDs checked (as opposed to, for example, being subjected to surreptitious facial recognition)? 26Computer Science and Telecommunications Board, National Research Council. IDs Not That Easy: Questions About Nationwide Identity Systems. Washington, D.C., National Academy Press, 2002, pp. 9-11.

~4 O GOES ~RE7 ~ What /~' sfr"cf"~ protect the system's 1ntegrhy as gem as the data subjects privacy and due process duty and Which structures deter- mine the 11~1Uty of We government and relying pardes for system misuse or Inure? We next chapter explores the history and meaning of privacy' con- duding ~1~ a recommendation for the development of au~ent~abon systems modeled on these ~esUons.

Next: 3 Privacy Challenges in Authentication Systems »
Who Goes There?: Authentication Through the Lens of Privacy Get This Book
×
 Who Goes There?: Authentication Through the Lens of Privacy
Buy Paperback | $48.00 Buy Ebook | $38.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Who Goes There?: Authentication Through the Lens of Privacy explores authentication technologies (passwords, PKI, biometrics, etc.) and their implications for the privacy of the individuals being authenticated. As authentication becomes ever more ubiquitous, understanding its interplay with privacy is vital. The report examines numerous concepts, including authentication, authorization, identification, privacy, and security. It provides a framework to guide thinking about these issues when deciding whether and how to use authentication in a particular context. The book explains how privacy is affected by system design decisions. It also describes government’s unique role in authentication and what this means for how government can use authentication with minimal invasions of privacy. In addition, Who Goes There? outlines usability and security considerations and provides a primer on privacy law and policy.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!