Process Application Layer Security

Any vendor’s software is susceptible to harboring security vulnerabilities. Security can be seen as an arms race, with the bad guys exploiting vulnerabilities and the good guys patching them. Every day, Web sites that track security vulnerabilities, such as CERT, are reporting new vulnerability discoveries in operating systems, application software, server software, and even in security software or devices. Last year, CERT advertised an average of over six vulnerabilities a day. Figure 1.3 shows the increase in reported incidents over the years.

Patches are implemented for these known bugs, but new vulnerability discoveries continue. Sometimes patches fix one bug, only to introduce another. Even open source software that has been widely used for ten years is not immune to harboring serious vulnerabilities. In June 2000, CERT reported that MIT Kerberos had multiple buffer overflow vulnerabilities that could be used to gain root access, and in Feb of 2002, widespread vulnerabilities were announced in the fundamental ASN. 1 encoding schema common to all SNMP agents, allowing the compromise of nearly all infrastructure devices across the Internet.

Many sites do not keep up when it comes to applying patches and so leave their systems with known vulnerabilities. It is important to keep all of your software up to date. Many of the most damaging attacks have occurred in end-user software such as electronic mail clients. Attacks can be directed at any software and can seriously affect your network.

The default configuration of hosts makes them easy to get up and running, but many default services are unnecessary. These unnecessary services increase the vulnerabilities of the system. On each host, all unnecessary services should be shut down. Misconfigured hosts also increase the risk of an unauthorized access. AU default passwords and community names must be changed.

NOTE

The SANS (System Administration, Networking, and Security) Institute in conjunction with the National Infrastructure Protection Center (NIPC) has created a list of the top 20 Internet security threats as determined by a group of security experts. The list is maintained at www.sans.org/top20.htm. This guide is an excellent list of the most urgent and critical vulnerabilities to repair on your systems. Two of the problems listed earlier—unnecessary default services and default passwords—are on this list.

This effort was started because experience has shown that a small number of vulnerabilities are used repeatedly to gain unauthorized access to many systems.

SANS has also published a list of the most common mistakes made by end users, executives, and information technology personnel. It is available at www.sans.org/mistakes.htm.

The increased complexity of systems, the shortage of well-trained administrators, and a lack of resources all contribute to reducing the security of hosts and applications.We cannot depend on hosts to protect themselves from all threats.A useful approach is to use automated scanning devices, such as Cisco Secure Scanner (formerly NetSonar) to help identify the vulnerabilities from a network perspective, and work with the information owner to apply the necessary remediation.
Au is not lost, however. Application layer security can provide end-to-end security from an application running on one host through the network to the application on another host. It does not care about the underlying transport mechanism. Complete coverage of security requirements, integrity, confidentiality and non-repudiation, can be provided at this layer. Applications have a fine granularity of control over the nature and content of the transactions. However, application layer security is not a general solution, because each application and client must be adapted to provide the security services. Several examples of application security extensions are described next.

PGP

Phil Zimmerman created Pretty Good Privacy (PGP) in 1991. It is widely used by individuals worldwide for privacy and the digital signing of e-mail messages. PGP provides end-to-end security from the sender to the receiver. It can also be used to encrypt files. PGP has traditionally used RSA public key cryptography to exchange keys, and IDEA to encrypt messages.

PGP uses a Web of trust or network trust model, where any users can vouch for the identity of other users. Getting the public keys of the intended person can be difficult to achieve in a secure manner.You can get a person’s public key directly from that person, and then communicate the hash of the key in an out-of- band pathway. Keys are stored in files called key rings. Some Internet servers, in fact, have public key rings. They do not authenticate the keys—merely store them. You should not trust keys that have an unknown heritage.

S-HTTP

S-HTTP is not widely used, but it was designed to provide security for Web- based applications. Secure HTTP is a secure message-oriented communications protocol, and can transmit individual messages securely. It provides transaction confidentiality, authentication, and message integrity, and extends HTTP to include tags for encrypted and secure transactions. S-HTTP is implemented in some commercial Web servers and most browsers. As an S-HTTP server, it negotiates with the client for the type of encryption that will be used, several types of which exist.

S-HTTP does not require clients to have public key certificates because it can use symmetric keys to provide private transactions. The symmetric keys would be provided in advance using out of band communication.
Secure Sockets Layer and Transport Layer Security Secure Sockets Layer (SSL) was designed by Netscape and is widely used on the Internet for Web transactions such as sending credit card data. It can be utilized for other protocols as well, such as Telnet, FTP, LDAP, IMAP, and SMTP, but these are not commonly used. Transport Layer Security (TLS), on the other hand, is an open, IETF-proposed standard based on SSL 3.0. RFCs 2246, 2712, 2817, and 2818 define TLS. The name is misleading, since TLS happens well above the transport layer. The two protocols are not interoperable, but TLS has the capability to drop down into SSL 3.0 mode for backwards compatibility, and both can provide security for a single TCP session.

SSL and TLS provide a connection between a client and a server, over which any amount of data can be sent securely. Server and browser generally must be SSL- or TLS-enabled to facilitate secure Web connections, while applications generally must be SSL- or TLS-enabled to allow their use of the secure connec— tion. However, a recent trend is to use dedicated SSL accelerators as VPN terminators, passing the content on to an end server; the Cisco Content Services Switch Secure Content Accelerator 1100 is an example of this technique.

For the browser and server to communicate securely, each needs to have the shared session key. SSL/TLS use public key encryption to exchange session keys during communication initialization. When a browser is installed on a workstation, it generates a unique private/public key pair.

The Secure Shell Protocol

The Secure Shell protocol (SSH) is specified in a set of Internet draft documents. SSH provides secure remote login and other secure network services over an insecure network. It’s being promoted free as a means for reducing cleartext passwords on networks. One excellent Windows client is PuTTY, available at ww.chiark.greenend.org.uk/sgtatham/putty. The lOS on a modern Cisco router supports SSH, but only SSH version 1. SSH version 2 is completely rewritten to use different security protocols and has added public key cryptography. Both versions provide confidentiality of passwords and other commands during sessions.
The SSH protocol provides channels for establishing secure, interactive shell sessions and tunneling other TCP applications. There are three major components to SSH:

• Transport layer protocol Provides authentication, confidentiality, and integrity for the server. It can also compress the data stream. The SSH transport runs on top ofTCP. The transport protocol negotiates the key exchange method, public key, symmetric encryption, authentication, and hash algorithms.
  
• User authentication protocol Authenticates the user-level client to the server and runs on top of the SSH transport layer. It assumes that the transport layer provides integrity and confidentiality. The method of authentication is negotiated between the server and the client.
  
• Connection protocol Multiplexes an encrypted tunnel into several channels. It is run on top of SSH transport and authentication protocols. The two ends negotiate the channel, window size, and type of data. The connection protocol can tunnel Xli or any arbitrary TCP port traffic.

Figure 1.4 shows how various security controls can interact with network traffic, and shows several of the areas where controls can be placed—from directly encrypting signals as they are applied to the Network Access Layer (link encryption) all the way up to encrypting the contents of a mail message (PGP):

Figure 1 .4 The Layers of Security Controls

Authentication

Authentication can be used as a security control at any layer in the protocol stack, but is typically deployed at the application process layer. (Often, the application Network Access Layer process layer then makes changes to controls at the internetworking layer, establishing sessions or opening ACLs to permit traffic.)

Authentication can be provided locally on each device on your network, but using an authentication server offers improved scalability, flexibility, and control. Firewalls, routers, and remote access servers enforce network access security. Configuring these devices to use one, centralized database of accounts is easier on the administrator and the users who may access the network through multiple pathways.

A Cisco Network Access Server (NAS), firewall, or router acts as the client and requests authentication from an authentication server. The access server or router will prompt the user for a username and password, and then verifies the password with the authentication server. TACACS+, RADIUS, and Kerberos are widely used authentication servers supported by Cisco. TACACS+ and RADIUS can also provide services for authorization, and accounting.

Terminal Access Controller Access System Plus

Terminal Access Controller Access System Plus (TACACS+) is an enhanced version ofTACACS developed by Cisco. The enhancements include the separation of authentication, authorization, and accounting into three distinct functions. These services can be used independently or together. For example, Kerberos could be used for authentication, and TACACS+ used for authorization and accounting. Some of the characteristics ofTACACS+ are:

• While older versions ofTACACS and RADIUS use UDP for transport, TACACS+ uses TCP (port 49) for reliable and acknowledged transport.
• TACACS+ can encrypt the entire payload of the packet, so it protects the password, username, and other information sent between the Cisco access client and the server.The encryption can be turned off for troubleshooting. Communication from the workstation to the Cisco client providing access services is not encrypted.
• TACACS+ supports multiple protocols such as IP, AppleTalk Remote Access (ARA), Novell, Asynchronous Services Interface (NASI), X.25 PAD connection, and NetBIOS.
• You can use TACACS+ to provide greater control over router management in either nonprivileged or privileged mode, because you can authenticate individual users or groups rather than a shared password. Router commands can be specified explicitly on the TACACS+ server to allow specific commands.

Remote Dial-in User System

Remote Dial-in User System (RADIUS) is an open standard and available from many vendors. It was originally designed for ISPs to support dial-in clients, and provides the authorization and billing information for those needs. RADIUS can be a good choice in a heterogeneous network environment because of its widespread support, but some vendors have implemented proprietary attributes in RADIUS that hinder interoperability.

• RADIUS uses UDP, so it only offers best effort delivery at a lower overhead.
• For authentication, RADIUS encrypts only the password sent between the Cisco access client and RADIUS server. RADIUS does not provide encryption between the workstation and the Cisco access client.
• RADIUS does not support multiple protocols, and only works on IP networks.
• RADIUS does not provide the ability to control the commands that can be executed on a router: It provides authentication, but not authorization to Cisco devices.

Kerberos

Kerberos protocol can be used for network authentication and host authentication. It uses a trusted third-party approach, where users identify themselves to a central server, and the server then provides “tickets,” that the user can present to gain access to servers; the end server trusts that the Kerberos server is granting authority correctly.
A Kerberos realm includes all users, hosts and network services that are registered with a Kerberos server. Kerberos uses symmetric key cryptography and stores a shared key for each user and each network resource that is participating in its realm. Host-based applications must be “kerberized’ with modules adapted to use the Kerberos protocol. Kerberized versions of Telnet, ftp, mail, and several others exist, and APIs exist for updating code. Every user and network resource needs a Kerberos account. Kerberos stores all passwords encrypted with a single system key. If that system key is compromised, all passwords need to be recreated.

The process of authenticating using Kerberos involves three systems: a client, a network resource, and the Kerberos server. The Kerberos server is called the Key Distribution Center (KDC). The KDC has two functions: an Authentication (Service (AS) and a Ticket Granting Service (TGS).The basic process is a six-step sequence:

1. Alice to KDC Hi, I’m Alice. Could I have access to the AS?
2. AS to Alice Here is your “ticket-granting ticket.” If you aren’t Alice, it’s useless. If you are Alice, decrypt this, and come back with the answer.
3. Alice to TGS Okay, I figured out your secret. Give me a “servicegranting ticket” so I can talk to server Bob.
4. TGS to Alice You have it! It’s encrypted using the same mechanism as before, and then encrypted with Bob’s password. This ticket will be accepted by Bob for eight hours.
5. Client to Bob The KDC gave me this ticket, and it is encrypted using your password.Validate me.
6. Bob to Alice Hello,Alice! I’ve decrypted what you got from the KDC, I trust the KDC, and he trusts you, so your access is granted. It is worth noting that under Kerberos, passwords are never sent in the clear; there is a preshared secret between the client and the KDC, and the client uses that to unlock the “ticket-granting ticket.”This allows the client to request tickets that can be provided to individual servers to obtain that service.

As an example, let’s look at remote network access. The remote user establishes a PPP connection to the boundary device, and the device prompts the user for username and password. The device, acting as the client, requests a ticket— granting ticket from the Kerberos authentication server. If the user has an account, the authentication server generates a session key, and sends a ticket- granting ticket (TGT) to the client encrypted with the password stored on the AS for that account. The Cisco access server will attempt to decrypt the TGT with the password that the user entered. The TGT is a credential that specifies the user’s verified identity, the Kerberos server identity, and the expiration time of the ticket. By default, tickets expire after eight hours. The TGT is encrypted with a key known only to the ticket-granting server and the authentication server. The TGT is presented back to the TGS with a request for access to the Cisco access server. Now the roles reverse, and the Cisco access server becomes the server. The Cisco access server accepts the service ticket, decrypts it to verify it is valid, and provides service. If successful, the user is authenticated to the access server, and the user’s workstation becomes part of the protected network.

Note that at this point, the only authenticated “user” is the Cisco access server. Users, who want to access services that are part of the Kerberos realm on the network, must now re-authenticate against the Kerberos server and get authorization to access the services. The user first gets a ticket-granting ticket as previously described, which is used to request access to other services. The difference is that the client is now the user’s workstation.