8.2 Microsoft .NET Passport

As part of its .NET initiative, Microsoft has introduced a set of XML-and SOAP-based Web services that collectively support what Microsoft has named a ˜ ˜ user -centric application model. ^[2] In this model, it is the user and not the hardware that needs to be authenticated and authorized to run the software, so user authentication and authorization become the core attributes.

As of this writing, Microsoft calls the services that implement the user-centric application model .NET My Services . ^[3] At the core of Microsoft .NET My Services is a user authentication service named Microsoft .NET Passport [11, 12]. The service was initially released in 1999 and is currently the most widely used service of its kind on the Internet and WWW. ^[4]

8.2.1 Overview

As mentioned in the introduction, Microsoft .NET Passport provides a password-based authentication service that makes use of a TTP. The TTP, in turn , is provided by Microsoft through its .NET Passport service, or via the servers that provide the service.

Microsoft uses the term single sign-in (SSI) to refer to the service that Microsoft .NET Passport provides. This is in contrast to the term single sign-on (SSO) that is otherwise used in the literature. It is not clear to what extent SSI differs from SSO in the terminology of Microsoft. ^[5] In this book, we use the terms SSI and SSO synonymously and interchangeably.

To make use of Microsoft .NET Passport and its service (i.e., the SSI service), a user must create a .NET Passport account to store his or her credentials. The credentials, in turn, must include his or her e-mail address (or phone number) and password. A corresponding .NET Passport registration screen is illustrated in Figure 8.1. Note that it is possible and very likely that the GUI will have changed when this book hits the shelves of the bookstores. So this figure, and some of the following figures, only serve illustrative purposes.

Figure 8.1: The .NET Passport registration screen. ( 2002 Microsoft Corporation.)

Each user may store additional, optional user profile information, such as demographic or preference data (for example, gender, occupation , and ZIP code) or their first and last name in his or her .NET Passport account. The screen that is used to request this additional information is illustrated in Figure 8.2. In addition, through .NET Passport express purchase service (as discussed below), the user can store credit-card information and addresses in his or her .NET Passport wallet and use this information to purchase products and services on-line. The corresponding screen to enter the user s payment information is illustrated in Figure 8.3. In summary, the .NET Passport user account can be used to store any information that is needed and must eventually be provided at multiple sites.

Figure 8.2: The .NET Passport screen to edit a user profile. ( 2002 Microsoft Corporation.)

Figure 8.3: The .NET Passport screen to enter the user s payment information. ( 2002 Microsoft Corporation.)

In essence, Microsoft .NET Passport provides a SSI service by hosting a central database that contains users accounts, as well as the registration and sign-in/sign-out pages, that participating .NET Passport sites can cobrand. Using this service, a user can easily move between participating sites and services without the need to remember a specific set of credentials for each of them (this is basically the idea of an SSI or SSO service). Furthermore, there are several security levels that Microsoft .NET Passport may provide (i.e., standard sign-in, secure channel sign-in, and strong credential sign-in). These security levels are described below.

Sites become participating .NET Passport sites by implementing the .NET Passport SSI service. Participating .NET Passport sites rely on .NET Passport to authenticate users rather than hosting and maintaining their own authentication schemes. However, .NET Passport does not authorize or deny a specific user s access to individual participating sites. Web sites that implement .NET Passport maintain control over permissions. As such, .NET Passport provides an authentication system or infrastructure and does not provide a complete and comprehensive AAI. This is similar to the Kerberos system. Also similar to the Kerberos system, Microsoft .NET Passport can easily be extended to provide an AAI.

8.2.2 .NET Passport user accounts

Each .NET Passport user account may include the following components :

The .NET Passport Unique Identifier (PUID) that is a 64-bit numeric value assigned by the .NET Passport service during the creation of the account. For obvious reasons, this component is required for every .NET Passport user account.
The .NET Passport user profile that may contain the following components:
- The user s e-mail address or phone number;
- The user s first and last name;
- The user s demographic information such as postal code, country, and state or region.
The user s e-mail address or phone number is the only required profile information.
The .NET Passport credentials that contain the following components:
- The standard .NET Passport credentials consist of the user s e-mail address or phone number stored in the .NET Passport user profile and a password (or PIN) of at least six characters . An optional secret question and answer may be used to reset the password. The standard credentials are the minimum amount of information required for a user to have a .NET Passport account and to use the .NET Passport authentication service (i.e., for standard sign-in and secure channel sign-in).
- An additional four-digit security key that is used when the user accesses sites requiring strong credential sign-in. When created, the security key requires three associated secret questions and answers to reset it. The security key is created the first time the user accesses a site requiring strong credential sign-in.
The optional .NET Passport wallet , used by the .NET Passport express purchase service. Each wallet may contain the following pieces of information:
The user s credit-card numbers and the associated expiration dates, billing address, and friendly names .
The user s shipping addresses and associated friendly names.

To operate the .NET Passport service, .NET Passport also stores some operational data about the user account. This includes the version number, whether the account contains a .NET Passport wallet, and so on.

Users create their account the first time they register for a .NET Passport. There are several ways to register. The most direct way is to register at the home page of .NET Passport ^[6] or by using the Microsoft Windows XP Registration Wizard. Also, a user may register by opening a Hotmail ^[7] account (i.e., Hotmail accounts are automatically registered as Passports) or he or she may register at a participating site. Participating sites automatically redirect users to a cobranded, centrally hosted .NET Passport registration page. In either case, the amount of information the user is asked for when registering for a Passport depends on the site where the user registers. For example, users directly registering at the .NET Passport home page are asked only for the minimum information needed to create a Passport (i.e., an e-mail address and a password). If a participating site asks for additional, non-Passport information during registration, an arrow icon indicates the information that will be stored in the user s .NET Passport account. Information typed in fields not followed by this icon is not stored in the user s .NET Passport account (i.e., it is stored at the participating site only).

During Passport creation, users can choose what type of information they want to share with participating sites during sign-in (i.e., e-mail address, first and last names, all other .NET Passport user profile information). The site users register from can store all the information the site requested during Passport creation. Other participating .NET Passport sites, however, receive only the information the user has decided to share with participating .NET Passport sites. For example, users can decide not to share their e-mail address and their user profile information. In this case, when the user is authenticated, the participating Web sites receive only the user PUID. Furthermore, .NET Passport wallet information is shared only when users use the .NET Passport express purchase service.

We overview and briefly discuss the .NET Passport SSI and some complementary services, such as the .NET Passport Express Purchase and Kids .NET Passport services, next .

8.2.3 .NET Passport SSI service

The SSI service is the core service that .NET Passport provides. The service is implemented by a protocol and the protocol s message flows are illustrated in Figure 8.4. When a registered .NET Passport user clicks the standard sign-in link on a participating .NET Passport site, an initial HTTP request message is sent to this site (i.e., message 1). The participating site, in turn, sends back an HTTP redirect message for the cobranded .NET Passport sign-in page ^[8] located at the .NET Passport server (i.e., messages 2 and 3). From the user s point of view, the HTTP redirect for authentication is transparent. ^[9] A unique site ID is used to identify the participating site requesting the authentication. Furthermore, a return URL ( generally the same URL as the one the user originally requested) is added to the .NET Passport URL in query string parameters.

Figure 8.4: The .NET Passport Protocol s message flows.

Before displaying the appropriate .NET Passport sign-in page, .NET Passport checks the site ID and return URL. If they do not match an entry in the list of participating .NET Passport sites, the authentication is rejected (this ensures that only participating .NET Passport sites can request .NET Passport user authentication). The .NET Passport server then displays a page with a secure form that prompts the user to enter his or her .NET Passport credentials (i.e., his or her e-mail address and password). Again, this page might be cobranded by the participating site. In either case, the password is not displayed in the clear. When the user clicks the .NET Passport sign-in link, the credentials are transmitted to the .NET Passport server using the HTTP POST method on top of SSL (i.e., HTTPS). Consequently, the transmission of the user s credentials are strongly encrypted and protected against eavesdropping.

If the user s credentials match an entry in the .NET Passport database, he or she is authenticated. The PUID is extracted from the database along with the .NET Passport user profile information that he or she has agreed to share with participating sites at sign-in. The .NET Passport server then uses this information to create the following three cookies:

The ticket cookie that includes the PUID and a time stamp;
The profile cookie that includes the user profile information;
The visited sites cookie that includes a list of the sites the user has signed in to.

Cookies are encrypted using 3DES and a site encryption key that is shared between the .NET Passport server and the participating site (the key is identified through the site ID and must be distributed out-of- band ). Using the site encryption key, the .NET Passport server encrypts the ticket and profile cookies, adds them as query string parameters to the return URL provided in the authentication request, and presents this URL to the user s browser so that it gets redirected to the participating site (i.e., messages 4 and 5).

The participating site extracts the encrypted ticket and profile cookies from the query string parameters and sends them to the .NET Passport Manager object running locally. The .NET Passport Manager object, in turn, decrypts the information and receives the PUID, the time stamp, and the user s profile information accordingly . The time stamp can be used to decide whether the user must reauthenticate. If the site s time window has expired , it displays the cobranded .NET Passport sign-in page with the user s e-mail address and the prompt to enter the user s password before proceeding. If everything is fine, the user is authenticated and the participating site displays the requested page (i.e., message 6). To personalize the user s experience in some way, the site might populate the page using information it has already gathered from the user or extracted from the profile cookie. The site can also use information from the profile cookie to create or upgrade its own database entry for that particular user. In either case, the requested page includes a sign-out link.

Note that there is no direct server-to-server communication of users authentication and profile information between the .NET Passport server and the participating site. The information exchange always occurs through the client s browser using HTTP redirects and cookies. However, the Passport Manager on the participating site does periodically download a centrally hosted configuration file. This is an XML document that contains current URLs for the .NET Passport servers and the current .NET Passport profile configuration (or profile schema).

After signing in at one .NET Passport participating site, a user can sign in to any other participating site simply by clicking the corresponding .NET Passport sign-in link on that particular site. Again, the browser is silently redirected to the .NET Passport server and the site ID and return URL are sent for authentication. The .NET Passport server checks the validity of the site ID and the ticket cookie (i.e., PUID and time stamp) and silently returns encrypted ticket and profile cookies to the site to authenticate the user. Again, these cookies are encrypted using a key that is shared between the .NET Passport server and the participating site. In this way, after the first sign-in to any participating site has occurred, the user can be authenticated by any other participating site with just one click. If, however, a participating site wants to ensure a recent authentication for added security, it can ask the .NET Passport server to force a new authentication. Obviously, this requires the user to reenter his or her password regardless of the user s authentication state. Last but not least, users can also choose to be signed in automatically by saving their .NET Passport sign-in name and password on a given computer (i.e., the ˜ ˜sign-me in automatically option). This option keeps a consumer signed in to .NET Passport at all times on that computer, even if the consumer disconnects from the Internet, closes the browser, or turns off the computer. From a security point of view, this option should be considered with care and is certainly not preferred.

Even though a user can use his or her .NET Passport account at multiple sites, the password is stored only in the .NET Passport database and is shared only with the .NET Passport servers that need it for authentication. If a legitimate user (or someone else) makes several incorrect attempts during sign-in, .NET Passport automatically blocks access to this users s account for a couple of minutes. This makes it significantly more difficult to launch a password cracker (i.e., a password-cracking program) to gain illegitimate access to a user s .NET Passport account.

When a user signs out by clicking the sign-out link on any participating site, the .NET Passport server checks the visited site s cookie to learn all the sites the user has signed in to during the session. For each of these sites, the .NET Passport redirects the browser to the site ^[10] and has the site locally execute a script. The script, in turn, is to delete all cookies that have been created at sign-in. Consequently, only the site that has created a cookie can also delete it.

Furthermore, unless users choose the option to automatically sign in to .NET Passport, all .NET Passport cookies are temporary cookies that are deleted when the browser session is closed. Even if a user does not sign out of .NET Passport or close his or her browser, .NET Passport cookies are time sensitive, meaning that they expire after a time period specified by .NET Passport or the participating site. This ensures that .NET Passport- related information is never stored in the user s computer system for an infinite amount of time.

.NET Passport includes three security levels that Microsoft intends to complement in future releases to support additional credential types (e.g., Kerberos tickets, public key certificates, and so on). Participating sites can request the level of secure authentication they require based on the sensitivity of the content or services they provide. In either case, the user s .NET Passport password is not sent to a participating site, and authentication and profile information is always sent encrypted using a key specific to the site.

8.2.3.1 Standard sign-in

Using .NET Passport standard sign-in, SSL is used only to secure the transmission of user credentials between the browser and the .NET Passport service (i.e., SSL is not used between the browser and the participating site). This is the security level described above. It is intended to be used by participating sites that don t require a high level of security. For example, Microsoft s Hotmail service employs .NET Passport standard sign-in.

8.2.3.2 Secure channel sign-in

.NET Passport standard sign-in is vulnerable to replay attacks because a participating site receives the encrypted ticket and profile cookies over an HTTP connection. The participating site then writes the cookies to the user s browser over the same connection. Consequently, an attacker listening to network traffic (between the browser and the participating site) could capture the encrypted tickets. The user s credentials are not at risk because the cookies are encrypted with a key that is known only to the .NET Passport server or the participating site, respectively. However, the attacker could replay the tickets against the participating site. He or she would then appear to be the user for the lifetime of the tickets.

In general, there are at least three possibilities to address and counter this vulnerability:

Limit the lifetime of a ticket;
Provide a possibility for an owner of a ticket to prove his or her legitimate ownership;
Send and receive tickets only over secured channels.

The first approach is simple and straightforward. Each participating site of .NET Passport can make use of this possibility by selecting sufficiently short lifetimes for the tickets it issues. Obviously, the disadvantage is that users are frequently requested to reenter their credentials, ensuring that they are valid .NET Passport users. The second approach is not supported by .NET Passport. It was chosen , for example, by the developers of the Kerberos authentication system. In fact, Kerberos uses the notion of an authenticator to prove legitimate ownership of a ticket (this mechanism is explained in the next section). Finally, the third approach is supported by .NET Passport secure channel sign-in. In this mode, all communication takes place over secured channels (i.e., SSL or HTTPS channels) and are cryptographically protected accordingly. With .NET Passport secure channel sign-in, an attacker listening to the network traffic won t be able to get the tickets because the entire traffic is encrypted with a session key that is held only by the legitimate participants . From the user s point of view, the secure channel sign-in interface is the same as the standard sign-in interface except that the .NET Passport sign-in page is displayed using SSL.

8.2.3.3 Strong credential sign-in

As mentioned above, if a legitimate user makes several incorrect attempts during sign-in, .NET Passport automatically blocks access to that users s account for a couple of minutes ( mainly to make it more difficult to launch password-cracking programs). In spite of this countermeasure, a determined and long-term brute-force attack is still possible and represents a potential risk. There are at least two approaches to addressing this problem:

Make the passwords stronger;
Block the account after a given number of unsuccessful attempts to sign-in.

Both approaches have drawbacks. Making passwords stronger adversely affects the usability of the .NET Passport service because of stringent password requirements, such as a minimal length, password expiration, and the requirement to use mixed-case, numeric, and symbol characters as part of the passwords. Similarly, blocking an account could easily be exploited in a denial-of-service attack.

Against this background, the designers of .NET Passport have chosen to use a two-stage sign-in process for protecting participating sites with more stringent security requirements. The first stage is identical to the secure channel sign-in process described above. The second stage, however, involves a second sign-in page that requires the user to enter a four-digit security key, or PIN. This page is displayed only through an SSL connection and incorporates a persistent failed-attempts counter for each user. The counter is reset upon each successful sign-in. In the event that five consecutive failed attempts are made, the user s security key is disabled. The user is still able to use the normal .NET Passport sign-in (i.e., standard sign-in or secure channel sign-in), but he or she has to go through a process to reset the security key. Since the security key is locked after five failed attempts to sign in and then must be reset to restore access, it is not vulnerable to an automated dictionary attack and therefore constitutes a strong credential. Consequently, the resulting authentication scheme is named . NET Passport strong credential sign-in.

.NET Passport strong credential sign-in is currently the highest level of security participating sites can request and will be used by sites for which preventing malicious access to a user s account is more important than ease of use.

8.2.4 Complementary services

There are two complementary services that can be provided in addition to the basic .NET Passport SSI service: the .NET Passport Express Purchase service and the Kids .NET Passport service. The two complementary services are briefly overviewed next.

8.2.4.1 .NET Passport express purchase service

Using the .NET Passport Express Purchase service and the optional .NET Passport wallet, a user can make use of his or her credit cards to purchase products or services online. In fact, .NET Passport Express Purchase uses the same redirection mechanism as described above. To post data, .NET Passport Express Purchase uses labels that comply with the electronic commerce modeling language (ECML). ^[11] When users click the .NET Passport Express Purchase link or button on a participating site s check-out page, they are redirected to their .NET Passport wallet page by means of a secure SSL connection. The site ID and return URL, supplied to .NET Passport by the participating site during registration for the .NET Passport Express Purchase service, are passed to the .NET Passport Wallet server as query string parameters during the redirection. Both the site ID and the return URL are checked by the .NET Passport Wallet server to identify the site and verify that it is a valid .NET Passport site (if the site is not valid, the request is rejected). If authenticated, users can select the credit card, billing address, and shipping address they want to use for the purchase. ^[12] By clicking the Continue button on the .NET Passport wallet page, they send their selected information to the participating site. This information is returned to the calling site only over an SSL connection. Note that .NET Passport does not receive or track the purchase price or product information when processing .NET Passport Express Purchase transactions. Also, the .NET Passport Express Purchase service is not itself a credit card or debit card service. Participating sites are still required to process the transaction directly or through a third-party service.

8.2.4.2 Kids .NET passport service

In the United States the Children s Online Privacy Protection Act (COPPA) went into effect on April 21, 2000. COPPA requires that operators of online services or Web sites obtain parental consent prior to the collection, use, disclosure, or display of personal information from children.

Against this background, the designers of .NET Passport have provided a complementary service that makes the consent process easy for parents by providing one location for them to give consent for all participating Kids .NET Passport sites. The service has been named Kids .NET Passport. ^[13]

More specifically , .NET Passport users can register children under the age of 13 for special Kids .NET Passports that let parents and guardians control what information their children can share with participating Kids .NET Passport sites, and what those sites can do with that information. As with a standard .NET Passport account, a Kids .NET Passport account can store personal information (e.g., name, date of birth, e-mail address) that can be shared with participating sites. When a child with a Kids .NET Passport signs in at a particular site, .NET Passport checks the birth-date field in the profile. If the child is younger than 13, .NET Passport checks the account to determine whether the parent or guardian has granted consent for that site, and at what level (i.e., deny, limited, or full). The consent levels are summarized in Table 8.1. If the child s profile indicates that consent at one of the three levels has been granted for that site, the child is allowed to proceed. If, however, consent has not been granted, .NET Passport displays a notification message that the child must request consent from a parent or guardian before processing.

Table 8.1: Consent Levels Used by the Kids .NET Passport Service
Deny	The site is not authorized to collect personal information from a child
Limited	The site is authorized to collect, store, and use personal information from a child, but it is not authorized to disclose it to a third party (unless it is necessary to operate the site)
Full	The site is authorized to collect, store, and use personal information from a child, and to disclose it to third parties

The Kids .NET Passport service works fine in theory. In practice, however, it is very unlikely that a child will use its Kids .NET Passport instead of simply requesting a normal .NET Passport. History has shown that kids turn out to be very innovative and ingenious when it comes to circumventing parental obstacles.

8.2.5 Security analysis

A short time after Microsoft launched the first version of its .NET Passport service in 1999, David P. Kormann and Aviel D. Rubin published ^[14] a paper entitled ˜ ˜Risks of the Passport Single Sign-on Protocol [13]. In this paper, the AT&T researchers identified several risks and feasible attacks, and revealed a flaw in the interaction of Passport and Netscape Navigator that leaves a user logged in while informing him or her that he or she successfully logged out. Most of the identified risks and feasible attacks are related to key management. For example, most users don t care about server-side authenticity and don t properly verify server certificates. Consequently, various types of man-in-the-middle attacks are feasible . The same is true for DNS spoofing. Furthermore, .NET Passport is designed to have each participating site use one single key to generate cookies. This could be generalized to have each participating site use client-specific keys. The advantage of this would be that cookies are bound to clients and cannot be used universally . Most importantly, .NET Passport is a centralized system that has a single point of failure (i.e., the central database is an attractive target, since its knowledge allows an attacker to spoof any user that has an account in the system).

In their security analysis, Kormann and Rubin also argued that .NET Passport is a ticketing system that lacks a basic component of many such systems (e.g., Kerberos), namely, authenticators, to prove the legitimate ownership of tickets. Instead of authenticators, .NET Passport employs SSL connections to securely transfer tickets. It is too early to tell whether there are any risks and feasible attacks that will result from this alternative technology.

As mentioned previously, .NET Passport is one of the simplest authentication service one can think of that is based on user-selected passwords. In the following section, we elaborate on alternative and more sophisticated designs that are based on one of the oldest authentication systems still in use today (i.e., Kerberos).

^[2] This is in contrast to a machine-centric application model in which software is licensed to run on a specific hardware device.

^[3] The services have formerly been code-named HailStorm.

^[4] As of July 2001, Microsoft claimed to have more than 165 million accounts. One reason for the large number is that all Hotmail accounts were converted to the .NET Passport system. Furthermore, it is not possible to delete an account once it is created (at least it is not obvious how one can delete it).

^[5] Note, for example, that the term SSO is used in the documentation that describes Microsoft s Kerberos implementation in Windows 2000 and XP.

^[6] http://www.passport.com

^[7] http://www.hotmail.com

^[8] The current version of .NET Passport also allows participating sites, using JavaScript, to display the .NET Passport sign-in module (called inline sign-in) within their own pages.

^[9] This transparency means that the user does not have to type in a new URL. The browser is automatically redirected to the authentication server.

^[10] The URL for the script is provided by the site during the registration process.

^[11] Further information about the ECML can be found at http://www.ecml.org.

^[12] When a user chooses a stored credit card in a .NET Passport wallet, the complete credit card number is never displayed on the screen. The .NET Passport wallet pages display only the first six digits of the credit card number to help the user identify it, while preventing others from seeing the card s entire number.

^[13] http://kids.passport.com

^[14] The paper was first published on the Web and was later published in [13].