• No results found

Cryptographic Protocols

In document Mastering Web Services Security pdf (Page 86-88)

Most of the popular challenge-response authentication systems are implemented using

cryptographic protocols. These protocols build upon the cryptographic mechanisms that we have previously discussed, namely secret key and public key cryptography. The protocols define how clients and servers should exchange key information to establish a secure authenticated session. A client and server then use the established session to exchange data that is protected from disclosure and/or modification.

The most common cryptographic authentication protocols are SSL and Kerberos, which we discuss next.

SSL/TLS Protocol

In public key algorithms, the principal keeps his or her private key secret. For that rea- son, a principal’s signature on a message using the principal’s private key constitutes a proof of identity. When public key technology is used to authenticate the principal to a Web server, the principal sends the server its public key certificate after server authentication is complete and the session key has been established. The principal also sends its signature on a combination of server- and client-provided information. The server verifies the signature on the principal’s public key certificate and verifies the client’s signature on the combined data. If the signature is verified, the client is authen- ticated, and the encrypted session can begin using a shared secret session key.

The widest application of a public key authentication protocol scheme for Web access is the Secure Sockets Layer (SSL) protocol. SSL is now officially called Transport Layer Security (TLS) (IETF 1999). (In this book, we’ll continue to call the protocol SSL since this is the most commonly used name.) Several books are available that describe the details of SSL and TLS, for example (Rescorla 2000).

SSL is a transport security protocol positioned above TCP but below the application layer of a communication protocol stack. It was originally developed by Netscape to provide security for Web-based HTTP transactions. In addition to HTTP, SSL can also be used to provide secure transport for Telnet, FTP, and other application protocols. SSL is generally used to enforce confidentiality and integrity for end-user access to the Web, and should be based on 128-bit triple Data Encryption Standard (3DES) or RC4 session keys. For adequate protection, Web server public keys should be at least 1,024 bits.

The operation of SSL is normally transparent to the application that sits above it. However, once a user has been authenticated, the application can obtain information about the client’s certificate through application programming interfaces (APIs) pro- vided by the Web server. We will talk more about certificates in Chapter 4.

One thing of note about SSL is that the protocol supports mutual authentication. That is, SSL authenticates the server to the client and can also optionally authenticate the client to the server. While many authentication systems only authenticate the client to the server, with Web Services it is often more important to authenticate the server to the client. Users trying to connect to a Web server need to be confident that they are communicating with a trustworthy server before sending sensitive information such as credit card numbers.

Kerberos/DCE Protocol

In secret key algorithms, a principal’s identity is verified by testing whether the prin- cipal can correctly encrypt a message using a key that is shared only between the veri- fier and principal. Thus, the verifier must also possess the key in order to perform verification. Unlike public key protocols, secret key protocols can be difficult to scale to large applications because each principal must have a different secret key for every other principal it would ever want to authenticate.

To deal with the problem of pair-wise keys for all applications, practical versions of secret key authentication protocols have a trusted third party that maintains keys for a collection of principals. All principals in that collection have to trust only that third party to protect their secret keys.

The most popular representative of secret key authentication protocols is Kerberos (IETF 1993, Neuman 1994), which was developed at MIT. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to ensure data confidentiality and integrity.

Kerberos has been incorporated into Distributed Computing Environment(DCE) (Gittler 1995, OSF 1996) and adopted with extensions by Microsoft for Windows 2000 environments. You can find a good overview of Kerberos and its followers in (Oppliger 1996).

Kerberos is commonly used in the middle tier within corporate networks. Kerberos allows a principal to prove its identity to a server without sending authentication data (such as a password) that might allow an attacker to subsequently impersonate the principal. The client application provides a secret key that is derived from a password as the basis of authentication. The secret key may potentially be stored on a hardware token (DES card) for stronger authentication and may also be derived from a public key certificate.

To use a Kerberos security service, the client first sends the principal’s identity to the authentication server, which sends back a credential called a ticket-granting ticket (TGT). The TGT has been encrypted so that only the legitimate principal who pos- sesses the correct password is able to decrypt it and use it at a future time.

When the client wishes to access a server application using Kerberos, the client sends the TGT to the Key Distribution Center (KDC). The KDC returns a session ticket, which contains a secret session key and client identifier. The client uses the session ticket to establish a secure authenticated TCP/IP session with the server application. The session ticket is protected by encryption and is not exposed over the network.

Kerberos optionally provides encryption and integrity services for messages exchanged between clients and server applications. Kerberos uses DES for encryption and RSA MD4/MD5 for integrity. Kerberos is capable of supporting 128-bit keys, which is the current recommended key length for most applications.

DCE extends Kerberos functionality, and has been used extensively in corporate net- works in which its rich feature set and high-performance secret key authentication technology are critical requirements. DCE 1.1 security is a mature product that pro- vides powerful and flexible support for all aspects of security: login, authentication, message protection, authorization, delegation, audit, and key management. DCE begins with Kerberos V5, which provides basic secret key (DES) authentication and message protection. DCE then adds Registration Servers and Privilege Servers to pro- vide additional services.

Secret key authentication using Kerberos and DCE security are known and proven technologies with good performance in corporate networks. However, it is generally accepted that secret key distribution and management is not tractable for very large numbers of users. Even with the Kerberos-based design of Microsoft Passport, the pro- tocol still receives criticism for its inability to handle the scale and loosely federated nature of the Internet-based Web Services.

In document Mastering Web Services Security pdf (Page 86-88)