Chapter 8: Authentication and Authorization Infrastructures

In this chapter, we address the notion of an authentication and authorization infrastructure (AAI) and discuss some technologies to build and operate an AAI. More specifically , we introduce the topic in Section 8.1, addresses Microsoft .NET Passport in Section 8.2, and elaborate on Kerberos- and PKI-based AAIs in Sections 8.3 and 8.4. Finally, we conclude with some final remarks in Section 8.5.

8.1    Introduction

In a 1993 edition of The New Yorker , Peter Steiner published a cartoon ^[1] that showed a dog explaining to another dog the major advantage of the Internet, namely that ˜ ˜on the Internet, nobody knows you re a dog. In subsequent years , the cartoon was used by many security companies as an argument that e-commerce requires a PKI to be successful in the first place. The statement was made that an Internet merchant must know the identity of his or her customers, and that the merchant would face a problem if he or she did not know that the, customers were dogs.

One may argue whether this statement actually hits the point. Would an Internet merchant really face a problem if he or she did not know that the customers were dogs? To answer this question, it is helpful to have a look at the real world and to ask whether a real merchant would face the same problem. In the real world we would probably say yes. More interestingly, however, we would say yes, not because the merchant dislikes dogs, but because the probability that the merchant would get money out of a dog is negligible. Consequently, as a result of risk analysis considerations, the merchant would typically refuse to serve a dog, out of fear of loosing money. There are (at least) two conclusions to draw:

1. Everything we do is subject to risk analysis.

2. The merchant may not care about the identity (or breed) of his or her customers if the risk of not getting paid is negligible.

This line of argumentation leads to the insight that e-commerce requires authenticity only in the foreground, and that authorization is much more important from a commercial point of view. More specifically, a merchant is typically more interested in the authorization of his or her customers than in their authenticity. This point was first made by Joan Feigenbaum in an invited talk she gave at the 1998 USENIX Workshop on Electronic Commerce [1]. It has led to many research and development activities that are collectively referred to as trust management (e.g., [2 “8]).

Trust management is a rather artificial term , and its use is greatly overblown in the PKI industry. Following the line of argumentation introduced in [9] and further explored in Chapter 15 of this book, one may argue that trust management is not particularly important and that all that matters is risk management:

Trust management is surely exciting, but like most exciting ideas it is unimportant. What is important is risk management, the sister, the dual of trust management. And because risk management makes money, it drives the security world from here on out. [9]

To clarify the point, we consider the situation in which a customer wants to order some goods from an on-line merchant. In this situation, there are two possible questions a customer may ask:

1. Does he or she trust the merchant (to handle the order properly)?

2. Does he or she carry the risk of having the merchant not properly handle the order?

Obviously, the first question is related to trust management, whereas the second one is related to risk management. In many situations, it is much simpler and more efficient to elaborate on risks than to discuss trust. In fact, trust is difficult to address and even more difficult to quantify. In either case, however, it is important to note that trust and risks are not independent, and that the two things basically try to measure the same (or at least closely related ) things. For example, if we trust something we usually mean that the risks involved using it are small or negligible. Similarly, if we assume high risks we usually do not trust something or somebody.

If we agree that for all practical purposes authorization is more (or at least equally) important than authentication, we may want to extend the scope of a security infrastructure (e.g., a PKI) to address both authentication and authorization. This is where AAIs come into play. Similar to a PKI, an AAI may employ public key cryptography and public key certificates. Contrary to a PKI, however, an AAI need not necessarily be based on public key certificates. In fact, there is an increasingly large body of research and development that elaborates on other or complementary technologies to provide authentication and authorization services to communicating peers. This body of research and development is overviewed and briefly discussed in this chapter.

The simplest AAI one may think of is a password-based authentication system that is provided by a trusted third party (TTP), and that leaves authorization and access control decisions to participating server systems. This is basically the service that Microsoft .NET Passport provides. One may argue about the trustworthiness of Microsoft and the security properties of Microsoft .NET Passport, but for participants who only require a low level of security Microsoft .NET Passport provides a fairly simple and straightforward approach and solution for their AAI requirements.

The rest of this chapter starts with a thorough overview and discussion of Microsoft .NET Passport in Section 8.2. This discussion also takes into account that Microsoft is promoting .NET Passport very aggressively as a key technology for its user -centric application model and .NET initiative.

The design and development of authentication and key distribution systems has a long history in network security [10], and many more or less sophisticated authentication and key distribution systems are available in theory and practice (some of them have expired and are no longer supported by their original developers or vendors ). One system that is particularly widely deployed on the Internet is the Kerberos authentication system (as briefly mentioned in Chapter 5). Kerberos may serve as a starting point to design and develop an AAI. In fact, there are several Kerberos-based AAIs that are overviewed and discussed in Section 8.3. Note that Microsoft .NET Passport and Kerberos are not mutually exclusive, and that Microsoft has already announced that future releases of .NET Passport will also make use of and support Kerberos.

Microsoft .NET Passport and Kerberos-based AAIs depend on passwords that are selected by users. This basically means that the overall security of the resulting system is bounded by the security of passwords. Unfortunately, all statistical investigations reveal the fact that passwords selected by users have bad security properties (meaning, for example, that they can be guessed easily). Consequently, from a security point of view it is interesting to look into technologies that don t depend on users to select ˜ ˜good secrets (for any meaningful definition of ˜ ˜good ) and use computer-generated secrets instead. One such technology is public key cryptography and public key certificates. As mentioned in the previous chapter, public key certificates and PKIs can be used to provide authentication infrastructures. Combined with some complementary technologies, they can also serve as a starting-point to additionally provide an authorization infrastructure and to come up with a comprehensive AAI accordingly . Such technologies are addressed in Section 8.4. Finally, the various technologies that can be used to build and operate an AAI are put into perspective in Section 8.5.

^[1] The cartoon was published on page 61 of the July 5, 1993, issue of The New Yorker (Vol. 69, No. 20). It is reproduced, for example, at http://www.unc.edu/courses/jomc050/idog.html for academic discussion, evaluation, and research.