Authorization

Deciding what users are permitted to do or what resources they are allowed to use are important functions of secure systems. Generally, the decision to provide access to services or resources is made by considering user requirements, or what the potential impact on other users of the system and to the system itself might be. For example, protection is often extended to files so that one user cannot destroy or modify another user's data. In another case, a user might be limited in the amount of disk space or network bandwidth so he does not monopolize the resource.

Authorization can be based on identity or the use of keys. As mentioned earlier in the chapter, identity may consist of an entity, a role or context, or a combination of these things. Two common mechanisms are useful in determining how much access to provide to resources. Capability lists associate a user or key with a set of access rights. An access control list links resources to a set of authorized users. After a system has authenticated a user (or a key, for that matter), it uses one of these lists in combination with a security policy to decide what constraints exist for the user in relation to the service. Although these lists are typically stored on the system that hosts the resources, a client can manage its own capability list. In this case, a client obtains a token or certificate from a system that provides a service, which entitles the bearer to use the service. These tokens or certificates are called credentials.

Peer-to-peer systems have unique requirements for identifying and authorizing entities. Storing identities on a peer for every possible user is impractical. It can result in large lists and a significant amount of redundant information between peers. Key- or credential-based systems are more useful. Centralized schemes can also be used effectively.

The problems of authenticating and authorizing users are frequently addressed by systems that are specialized to the tasks. In the next few sections, we will look at several that can be useful for peer-to-peer systems.

Kerberos

Kerberos was initially developed at the Massachusetts Institute of Technology as a component of a larger initiative to help link computing resources and services while providing a consistent user experience across workstations. It has since become widely adopted as a network authentication protocol for client server applications, and it uses secret key cryptography. Although Kerberos was initially developed for use with Unix systems, it has been incorporated into Microsoft Windows as an optional authentication mechanism. Kerberos enables clients to authenticate themselves to services. To prevent any confusion between clients of the Kerberos authentication service and clients of other services, the former are called principals. A few more additional terms should be defined before beginning the explanation of how Kerberos works:

• Key Kerberos principals possess keys that are large numbers. For a user, the key is the result of applying a one-way function to her password.

• Ticket A ticket is a Kerberos credential that includes the name of a principal, the name of the server, the client's network address, a lifetime for the ticket, and a session key.

• Authenticator An authenticator is a credential that is used to make sure that the principal is who he claims to be. An authenticator is made up of the principal's name, his network address, and a timestamp.

Kerberos uses a trusted third party to authenticate clients. The Kerberos trusted third party knows the secret keys for all the principals that communicate with it. By default, it uses DES for any ciphering. Figure 10.1 illustrates the scenario used in the following example.

Figure 10.1. A simple Kerberos network topology.

Kerberos operations can be divided into three basic functions:

• Authenticating a principal (Authenticating Service Exchange)

• Obtaining a ticket to use a service (Ticket Granting Service Exchange)

• Applying to use the service (Client-Server Exchange)

Officially, these operations are the subprotocols whose names appear in parentheses here.

For example, suppose that Kyle, a principal who desires to use a service must first authenticate with the Key Distribution Center (KDC). Upon logging into his workstation, the Kerberos client takes the following steps:

1. It sends a message, which contains information about Kyle, including his username and the name of the service he wants to authenticate with to Kerberos. In this early stage, it is the Ticket Granting Service (TGS).

2. The TGS looks to see if Kyle is an authorized principal. Principals are added to the system by security administrators. If Kyle is an authorized principal, the Ticket Granting Service will return a session key encrypted with Kyle's secret key and a Ticket Granting Ticket (TGT) encrypted with the TGS' own secret key.

3. On receipt of this information, the Kerberos client will use the password Kyle provided at login to obtain the session key.

Now that Kyle has the necessary credentials to interact with Kerberos, he can authenticate himself to other services. Before contacting the services directly, however, he must obtain the credentials to interact with the service from the Ticket Granting Service. It's important to note that, from this point on, Kyle is usually unaware of the authentication going on he does not have to login each time he accesses a service.

Upon determining that Kyle must be authenticated for a service, the process continues as follows:

4. The Kerberos client sends a message to the Ticket Granting Service containing the name of the service that Kyle wants to access, the Ticket Granting Ticket received earlier, and an authenticator, which is encrypted with the session key, also received earlier. As mentioned previously, the authenticator is a credential used to validate a ticket the client is presenting. It does this by decrypting the authenticator with the session key stored in the ticket. Successfully decrypting the authenticator means that the client who claims to own the ticket has the session key, and should be the rightful owner of the ticket.

5. If the ticket is good, the TGS issues a session key for use between Kyle's Kerberos client and the service he is trying to access. It also builds a ticket for the service (encrypted using the secret key of the target service), and returns both. The reply is encrypted using the session key from the TGT.

6. Kyle is now ready to redeem the ticket to the service. The Kerberos client constructs an authenticator for the ticket and dispatches the authenticator and ticket to the service, which validates the ticket, thereby receiving assurance that Kyle is who he claims to be.

Although the protocol may seem complex, it really distills to this: Kyle and the service both know and trust the Kerberos Ticket Granting Service, but do not have a permanent relationship between themselves. Kerberos makes it possible to introduce Kyle to the service ad hoc, and assure both Kyle and the service that they are genuine when they meet.

Kerberos does not intrinsically provide authorization. The Kerboros Ticket Granting Service does not make decisions about whether one principal is permitted to approach another. That decision is left to the principals who, with the information obtained from a ticket, can use local policy to decide.

Kerberos can partition authentication information into domains called realms, making it possible to scale-up, while ensuring manageability and permitting additional degrees of security. Principals can authenticate across realms if they are set up appropriately.

A complete specification for the operation of Kerberos version 5 can be found in RFC 1510, available from the Internet Engineering Task Force's Web site at http://www.ietf.org/rfc/rfc1510.txt?number=1510.

PKI

Earlier in the chapter, you learned about digital certificates. Throughout the rest of the chapter you will see that digital certificates and public key cryptography are incredibly useful so useful that it would make sense that some trusted system for creating and revoking certificates, and for storing, finding and distributing them would be implemented. Being trusted entities, and because of the value of certificates, we expect that those systems will be very secure. The Public Key Infrastructure (PKI) is all this and much more. The most common PKI is based on the ITU's X.509 Public Key Infrastructure (PKIX) Standard. The components of the standard, as they apply to the Internet, have been documented in IETF RFCs. The list of RFCs appears in Table 10.2.

Table 10.2. Internet RFCs for X.509

RFC	Subject
RFC 2459	Profiles of X.509 v3 Public Key Certificates and X.509 v2 Certificate Revocation Lists (CRLs)
RFC 2510	PKIX Certificate Management Protocols
RFC 2559	Operational protocols
RFC 2585	Operational protocols
RFC 2560	Operational protocols
RFC 2527	Certificate Policy and Certification Practices Framework
DRAFTS ONLY	Time-stamping and data-certification services

These documents provide clear guidelines and standards for the instruments of PKI so that digital certificates and their keys are managed efficiently and securely, while remaining useful to their clients. Although we can't discuss the complete PKIX standard in a single chapter, we will take a moment to focus on certificates again.

As you'll recall from earlier in the chapter, a certificate authority binds a subject name to a public key and other attributes. It does this by signing the document with its private key after verifying that the object or person is what or who it claims to be, and making sure that it has possession of the private key linked to the public key in the certificate.

Note

http://www.pkiforum.com/resources/verisigncerts.html contains many interesting articles and alerts that pertain to stolen or forged certificates.

In addition to publishing digital certificates, certificate authorities also publish Certificate Revocation Lists (CRLs). A CRL has several of the same elements used in a certificate: a version number, a signature algorithm identifier, the issuing certificate authority (CA) name, extensions, and a signature. In addition, it contains the date the list was issued and the date of the next anticipated update. Finally, it contains a set of serial numbers and revocation dates for invalidated certificates. Clients who receive a digital certificate are required to check with a CA to determine if the certificate appears on a CRL. Software that is certificate-aware often does this without notifying the user. To assist in efficiently locating CRLs, X.509v3 certificates have an extension, called the issuing distribution point, that identifies the location of one or more CRLs that might apply to the certificate.

CRLs help maintain the currency of certificates. In combination with certificates and the rest of the public key infrastructure, they make a great addition to the set of tools we have to create secure applications.

SAML

A promising standard is emerging in the form of the Security Assertion Markup Language (SAML). SAML is being developed by representatives of more than 20 companies with the input of users, under the auspice of the Organization for the Advancement of Structured Information Standards (OASIS). SAML is an XML-based framework for exchanging security information in an interoperable way. SAML does not currently define the underlying mechanisms used to obtain information instead it focuses on the protocols and vocabulary that clients and SAML authorities use to communicate with each other. SAML is independent of the underlying transport and other communication layers. Currently, a SOAP binding is defined so that SAML messages can be delivered using SOAP. In this case, SAML messages are mapped into the SOAP message body. Upcoming plans provide for a binding to raw HTTP.

SAML policies define the rules required to use SAML, with other frameworks or protocols to add or supplement security. Version 1.0 defines the WebBrowser Single Sign On (SSO) profile, in that an authenticated user within a particular domain can become authenticated in another domain without user interaction.

SAML clients and authorities communicate using a request-response protocol. However, SAML does not enforce client-server architecture. Authorities or "clients" can communicate with each other. Figure 10.2 illustrates a typical interaction.

Figure 10.2. Communication between a SAML requestor and authority.

Messages have several common elements: They contain information about the source of the message, the subject, and specific conditions that apply to the included assertions.

SAML authorities make three kinds of assertion statements about a subject. As defined in the specification, they are as follows:

• Authentication The specified subject was authenticated by a particular means at a particular time.

• Authorization Decision A request to allow the specified subject to access the specified resource has been granted or denied.

• Attribute The specified subject is associated with the supplied attributes.

Let's look at a request and a corresponding response. For this example, we will assume that Kalyn is attempting to log on to her workstation, and that a SAML-aware client is requesting authentication against the specified attributes. The following message illustrates the SAML request:

 <samlp:Request MajorVersion="1" MinorVersion="0" Request >    <samlp:AuthenticationQuery>     <saml:Subject>       <saml:NameIdentifier SecurityDomain="zzyxx.com" Name="kalyn"/>     </saml:Subject>     <saml:Atttribute AttributeName="userid" AttributeNameSpace= http://www.zzyxx.com>       <saml:AttributeValue>         cinderella       </saml:AttributeValue>     <saml:Atttribute AttributeName="password" AttributeNameSpace= http://www.zzyxx.com>       <saml:AttributeValue>         0qRRa400-loOA       </saml:AttributeValue>      </saml:Atttribute>   </samlp:AuthenticationQuery> </samlp:Request> 

If the authority successfully authenticates Kalyn, given her user ID and password, it might return a response to a SAML client that looks like this:

 <saml:Assertion MajorVersion="1" MinorVersion="0" Assertion  Issuer="zzyxx.com" IssueInstant="2002-05-06T17:12:01Z">   <saml:Conditions NotBefore="2002-05-06T17:12:00Z"         NotAfter="2002-05-07T00:00:00Z"/>   <saml:AuthenticationStatement AuthenticationMethod="password"         AuthenticationInstant="2002-05-06T17:12:00Z">     <saml:Subject>       <saml:NameIdentifier SecurityDomain="zzyxx.com" Name="kalyn"/>     </saml:Subject>   </saml:AuthenticationStatement> </saml:Assertion> 

This response indicates that Kalyn has been successfully authenticated, with the condition that the authentication will expire at midnight.

This scenario can be expanded to demonstrate the additional power of SAML. Now imagine that Kalyn wants to purchase an extra pair of glass slippers from an online merchant. Navigating to that site with her Web browser, she is authenticated there also. Finding the slippers she wants, she places an order that indicates that she would like to pay using a direct withdrawal from her bank, which has arranged for a temporary loan to cover the cost of her pumpkin carriage, gown, and accessories. In the course of the order, Kalyn's bank is contacted by her own client (using SAML, of course) to obtain authorization to spend up to a predetermined amount that is included in the order forwarded to the online merchant. The merchant sends the slippers, and everyone lives happily ever after.

There are several efforts that are closely related to the development of SAML, including the work of the Liberty Alliance, which is working to promote an open interoperable standard for network identity. For pointers to useful information about SAML or work related to it, see the "Additional Resources" section of this chapter.

Microsoft .NET Passport

.NET Passport is Microsoft's authentication and authorization scheme for Web-based services. More than 200 million consumers rely on it to provide access to a number of services, including Hotmail, Microsoft Money and other Microsoft products, eBay, McAfee, Monster.com, Buy.com, Computer Discount Warehouse, and Starbucks. Although .NET Passport is proprietary, freely available SDKs are available for Microsoft Windows and the Solaris and Linux operating systems.

In designing the system, engineers at Microsoft decided that .NET Passport should be compatible with technologies that currently exist in Web browsers and servers. As a result, it uses HTTP redirects, cookies, JavaScript, and SSL.

.NET Passport users are required to sign up to use it. They provide personal information to Microsoft when they do so. The information stored by .NET Passport is listed in Table 10.3.

Table 10.3. Core Attributes for .NET Passport

Attribute Name	Description
Accessibility	Determines if accessibility features should be enabled
Bday Precision	Defines the precision of the Birthdate attribute (required)
Birthdate	The member's birth date
City	A GeoID that maps to the member's city
Country	An ISO 3166 country code for the member's country or region
FirstName	The member's first name
Flags	Various flags for indicating such things as whether the member's email address has been verified (required)
Gender	The member's gender
Lang Preference	The member's preferred language, as a LocaleID(LCID)
LastName	The member's last name
MemberIDHigh	The upper 32 bits of the Passport Unique ID (PUID) that is assigned when the member initially signs up for the service (required)
MemberIDLow	The lower 32 bits of the PUID (required)
MemberName	A complete sign-in name, including a domain. This attribute has been deprecated.
Nickname	The member's preferred name
Occupation	The occupation of the member
Preferred email	The member's email address
PostalCode	The member's postal code
ProfileVersion	The version of the core profile in use
Region	A GeoID that maps to the member's region within a county
TimeZone	The time zone that the member lives in
Wallet	Determines whether the member has opted to establish a .NET Passport wallet (required)

As you can see, there is potentially quite a bit of information available to systems that authenticate using .NET Passport. Another goal of .NET Passport is to provide Single Sign-In (SSI) capabilities to users, enabling them to login to any .NET Passport-enabled Web site and have access to additional .NET Passport-enabled sites without logging in again. Also, because a significant amount of a user's personal information is contained in his .NET Passport profile, the user also does not have to provide it to each site it's available by default.

Now that you understand the scope of information that .NET Passport provides, we can examine how it works. Figure 10.3 illustrates the scenario for the following discussion.

Figure 10.3. The .NET Passport architecture.

Users approach Web pages or services by using the HTTP protocol, along with the address of the resource. For the sake of this example, we will assume that a user is attempting to access a Web page using a browser. If the site requires authentication by the .NET Passport service, it will redirect the browser to a domain authority, where the user is presented with a sign-in page that is delivered over a secure connection. The request contains a site identifier for the site the user was redirected from, the URL to return to upon successful authentication, and information about the version of .NET Passport and the key used to encrypt the information returned. The user then enters her username and password, which is verified by the login server. If the user provides the correct username and password, the login server retrieves the user's PUID and profile. This information is incorporated into HTTP cookies that are returned when the browser is once again redirected to the return URL. Table 10.4 lists these cookies and the information they contain.

Table 10.4. Contents of .NET Passport Cookies

Common Name	Label	Description and Contents
Ticket	MSPAuth	Contains the encrypted .NET Passport timestamps (last refresh and manual sign-in) and various flags
Profile	MSPProf	Contains the encrypted core profile attributes
Ticket Granting Cookie	MSPSec	Contains the PUID and password used for silent sign-in
Visited Sites Cookie	MSPVis	Contains a list of the .NET Passport sites visited, using their site ID
Domain Cookie	MSPDom	Stores the last domain authority used when signing in to .NET Passport

These cookies are unavailable to the client, as they are created in the .NET Passport.com domain. They are for use by .NET Passport.

However, .NET Passport does provide access to the information contained in two of the cookies by adding them as encrypted query string parameters to the return URL. MSPAuth and MSPProf, which contain information about a user, are decrypted by Web server extensions to reveal the user's core attributes to the client. The client can then authenticate the user and permit him to access the Web page.

Note

Microsoft uses Triple-DES to perform encryption. As part of setting up a Web site that uses .NET Passport, the site administrators, and .NET Passport operators must decide on a password that is a shared secret. It is this password that is used to encrypt the cookies and query string parameters.

If the user has been authenticated once by .NET Passport, visits to other .NET Passport-enabled sites result in authentication that the user is unaware of. Upon accessing a second .NET Passport-enabled site, the client again redirects the browser to a domain authority. However, in this case, .NET Passport obtains the cookies it set previously, ultimately causing it to produce a redirection back to the referring site without requiring the user to log in again. The login server updates its own cookies and provides information about the user to the client again. Sites can force users to reauthenticate. Users log out of the system when their browser session is closed or when they explicitly command a logout. In the latter case, .NET Passport causes scripts to run at each .NET Passport site that has been visited, so that the site-specific cookies are deleted also.

In September 2001, Microsoft announced that .NET Passport would soon be able to interoperate with Kerberos v.5, thereby making .NET Passport less centralized. However, to realize the full benefit of a federated sign-in, users must authenticate through .NET Passport. Also, Microsoft does not appear to have loosened its grip on the .NET Passport service itself only Microsoft can operate one, and partners must pay to access the service at runtime. Additional information about .NET Passport is available at http://www.passport.com.

Integrity

Even if you can validate the origin of something, you often cannot be sure that it has not been altered. Several cryptographic functions help detect changes.

Digital signatures and digests can detect changes as small as a single bit in megabytes of data. Common practice is to use a hash function such as MD5 to produce a fingerprint of the data. The fingerprint is signed using a private key to create a digital signature. The data and signature are then delivered to the recipient, who uses the sender's public key to produce the original digest. Finally, MD5 produces the current fingerprint of the data and compares both fingerprints. A match indicates that the data is intact.

A second means of demonstrating the integrity of information is through the use of a Message Authentication Code (MAC). MAC functions perform the same task as hashes, but require a key. Functions that produce a MAC using a cryptographic hash algorithm in combination with a key are known as keyed hash-based Message Authentication Code (HMAC) functions. Using one of these function types, the sender will compute the MAC and send it and the data to the receiver. Using the secret key, the receiver simply computes the MAC for the received data and compares it with the sent MAC. Matching MACs provide assurance that the data is intact.

NIST's standard for the MAC algorithm is the Data Authentication Algorithm, which uses DES at its core. NIST's keyed hash-based Message Authentication Code algorithm preference is named HMAC. Other useful algorithms for insuring data integrity are HMACMD5 and HMACSHA1, based on the MD5 and SHA1 message digests, respectively.

Confidentiality

When people think of cryptography, confidentiality and privacy are probably the two things they think of first. Secret and public key cryptosystems help to hide information from others, or restrict access to a well-defined audience. By this time, you have a good grasp of how this is done. All that remains is to cover a few more technologies.

To promote the use of the Internet in e-commerce transactions, Netscape Communications developed the Secure Sockets Layer (SSL) protocol. SSL is used to transparently secure a communications channel by providing for the encryption and decryption of messages at the endpoints. SSL uses a combination of secret and public key technologies. The following list illustrates how SSL works:

1. A client that wants to communicate securely with a server initiates a handshaking protocol designed to select the cryptosystem and to exchange keys and authenticate the server.

2. The server submits its certificate to the client.

3. In response, the client verifies that the certificate has been issued (and is not revoked) by one of the trusted Certificate Authorities from a list that it stores locally. The client then generates a pre-master key, encrypts it with the server's public key and sends it to the server.

4. The server generates a master key and encrypts it with the server's private key and sends it to the client.

5. The client receives the master key.

6. Both the client and server generate a session key, which is used to encrypt future messages between them and to verify the integrity of those messages.

7. The server and client then send messages to each other indicating that future messages will be encrypted by the session key.

The client can be optionally authenticated with the server. Most Web browsers indicate that a secure connection is in use when a small key or lock icon appears on the frame somewhere.

Note

Although the terms client and server are used in the example, SSL can be used for peer-to-peer. In this case, the server is a peer that performs the protocol functions of the server-side of the connection.

When SSL Version 3 (SSLv3) was submitted as a protocol for Internet Standardization, the initial work to produce an Internet standard resulted in an evolution of SSL called Transport Layer Security (TLS). The basic high-level operation remains the same.

Many of the toolkits that are used to secure peer-to-peer communication depend on SSL or TLS. For example, JXTA depends on TLS. Because most of the work occurs behind the scenes in these technologies, peer-to-peer applications do not have to worry about adding much to their code to provide secure communication.

Nonrepudiation

Nonrepudiation consists of the acts or state of a system that enable it to prove something to the extent that it cannot be refuted. In most cases, it means that the system is capable of rebutting an attempt to deny knowledge of an act. Nonrepudiation involves most of the cryptographic services discussed so far:

• Identification and Authentication Knowing who or what did something is an important nonrepudiation function for most systems. Minimally, names or identifiers must be persistent and unique. Having confidence that the user really is the person you think they are is important, also. Shared secret keys such as passwords enable the system to be confident that a client possesses a key. However, it cannot determine if the identity or key has been stolen. Certificates improve the situation by virtually eliminating the possibility that an identity is counterfeit, but still leave the possibility of a borrowed key. Increasing the quantity of knowledge or things that one or more users must provide makes the system even more robust. For example, a system can require a client to find somebody else willing to support the client's claim of identity and make both provide credentials. Other more advanced techniques make use of features of the identify itself. Biometric-based authentication uses physiological or behavioral characteristics. Currently, biometric authentication is performed using fingerprint, iris, facial, or speech recognition.

• Authorization By authorizing access to system resources, you fence them in. Fences can protect users from what is on the other side and vice versa. Passing through a gate in the fence, a user often registers an act or commitment. Passing around or over a fence usually indicates malicious intent. All these things are useful to systems that require nonrepudiation, particularly if you have to place something "at the scene of the crime."

• Integrity It's important to ensure that information cannot be tampered with undetected. Identities, passwords, certificates, and data should not be modifiable by unauthorized entities. If integrity is lost, it must be restored, thereby limiting the effect of the loss. Systems that do not have internal integrity often cannot make irrefutable claims on others.

One particular example illustrates how protocols can be designed to support nonrepudiation. Figure 10.4 illustrates the example.

Figure 10.4. An example of a nonrepudiating protocol using a third party.

Suppose Ryan and Kalyn need to exchange the latest Nintendo cheats, and they want to be certain that each receives the message. They also want to be assured that they are only communicating with each other. They ask a trusted friend, Kyle, to help them. The process is as follows:

1. Ryan begins by signing his message with Kalyn's public key. After adding a timestamp and a secret known only to Ryan and Kyle, he now signs the document with his own private key and sends it to Kyle.

2. Kyle decrypts the document with Ryan's public key and makes certain that the additional information provided is the secret they share.

3. Kyle adds a timestamp to the document (now stripped to the ciphertext intended for Kalyn), and encrypts it with his own private key. He sends the document to Kalyn.

4. When Kalyn receives the message, she uses Kyle's public key and her own private key to decrypt it.

5. After reading and memorizing it, she encrypts the message with her private key. She then adds a timestamp and the secret shared between her and Kyle and encrypts the document with Kyle's public key, returning it to Kyle when she is done.

6. Kyle decrypts the document with his private key, verifies the secret information, adds a timestamp, encrypts the document with his public key and sends it to Ryan.

7. Upon receipt, Ryan decrypts the document with Kyle and Kalyn's public keys and compares the document to the original. If they are the same, he can be certain that Kalyn received the document he sent.

With a large number of words, we have just rediscovered certified delivery by courier with return receipt for electronic documents.

In this example, the third party helps to ensure that the information is delivered only to the intended recipient because the sender and receiver are authenticated with the third party. In addition, the third party becomes also becomes a "witness" of the transactions to support nonrepudiation.

To support nonrepudiation, system and client events are written into a database of logs.

Nonrepudiation is a fairly advanced security concept that has not found its way into most of the relatively new peer-to-peer applications. However, as peer-to-peer makes its way into business usage, it will become an important service.