Cryptography Operational Protocols and Algorithms

Leaving aside for a moment the issues of protocols and algorithms, the first choices to be made are the cryptographic strength of the system, embodied by choices of algorithm and key length, and some of the key-management questions. It is most important to choose truly random keys that are sufficiently long, keep those keys secret, and change keys "often enough." Again, this all supposes that you have selected a good cryptosystem; all the security of the system lies in the keys, and none in the algorithm itself.

We will consider key randomness and key secrecy shortly. For now, let us consider the selection of key length and the frequency of key updates.

Key Length

Given a reasonably strong algorithm, how well the data is protected depends largely on the length of the encryption key. Fundamentally, an encrypted message must remain secret for the useful life of the information. To a large extent, the value of the information in the encrypted message will govern the resources used to attack it. For example, an attacker would be foolish to spend $1 million to obtain information worth $1,000, but he might spend $1 million to obtain a secret worth $2 million. Here are some examples.

• Financial credentials must remain secret beyond their validity period.
• Contract bids must remain secret beyond the contract award.
• Editorial material must remain secret until published.
• Confidential personal information must remain secret beyond the lifetime of the individual.

Today, it is common to use 128-bit keys for symmetric algorithms, both for communications security and for the security of data to be protected for 20 years. The necessary key lengths for public-key algorithms vary considerably. The current recommendation for the RSA public-key algorithm, for example, is to use a minimum length of 1024 bits, with 2048 bits used for especially sensitive applications or longterm keys.

Key Updates

Cryptographic keys do not last forever; they need to be updated from time to time. The proper lifetime of a key is a function of the value of the items encrypted, the number of items encrypted, and the lifetime of the items encrypted. We have already discussed lifetime. If a key can be broken by a properly equipped adversary in 2 years, and the lifetime of information encrypted using the key is 6 months, then the key should be changed at least every 18 months so that an attack mounted on the first item encrypted will not succeed until after the last item encrypted loses its value.

The number of items encrypted is an issue for two reasons. First, if individual encrypted items have a market value, then the sum of the values of all encrypted items is the proper measure against which to balance the resources an attacker may bring to bear. Second, some cryptosystems can be attacked more easily when a large body of ciphertext is available. This effect is more difficult to quantify, but again, it is a good idea not to use a key for too long.

Another factor that leads to frequent key updates is paranoia. The longer a key has been in use, the greater the chance that someone has compromised the key storage system and obtained the key by subterfuge rather than by brute force attack.

It is important to note that changing a key does not increase the time that an attacker will need to find it using brute force or any other method of cryptographic attack. Changing keys does, however, limit the amount of information revealed if any particular key is found. For example, if the encryption keys are changed every month, then only one month's worth of information is disclosed if a key is discovered.

Internet Printing Protocol (IPP)

The Internet Printing Protocol (IPP) has gained high visibility as more computers become dependent on LAN as well as Internet resources. Although most network servers and clients can be configured to use the 1pr/lpd, Telnet, or DLC protocols, there are still many other protocols that can be used to send data to printers, such as SPX/IPX. The driving force of the Internet is making many vendors conscious of the need for more unified standards for basic functions, such as file and print sharing, and new protocols are being developed to meet those needs.

In 1996, several groups were developing a new standard. Novell and Xerox were working on a protocol that was titled Lightweight Document Printing Application (LDPA), IBM was developing the Hypertext Printing Protocol (HTPP), and Microsoft and HP were working on still another new protocol. Finally, a working group was formed under the auspices of the Internet Engineering Task Force (IETF) to work on a new standard. IPP uses the Hypertext Transfer Protocol (v. 1.1) as the underlying transport protocol.

The goals of the first) efforts of the project were to develop a protocol that defines the user end of the printing process and includes the following capabilities, as well as a few other features:

• Allow the user to discover the capabilities of a particular printer.
• Allow the user to submit jobs to the minter.
• Allow the user to get the status of the printer or a print job.
• Allow the user to cancel a print job.
• Define a set of directory attributes that make it easy to find a printer in a directory database.

All these are standard items incorporated into the first version of the standard (1.0).

Security and authentication mechanisms are also being created for IPP—just as for many other protocols that access the Internet.

The newest version of this protocol is 1.1. It is being developed by the RFC process, as well as the IEEE standards process. Following is a list of RFCs that have been written (as either a draft or an establishedstandard) for version 1.2 of IPP:

The work of the original IPP group so far was defined by several RFCs. Version 1.0 RFCs include thefollowing

• RFC 2565, "Internet Printing Protocol/1.0: Encoding and Transport"
• RFC 2566, "Internet Printing Protocol/1.0: Model and Semantics"
• RFC 2567, "Design Goals for an Internet Printing Protocol"
• RFC 2568, "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol"
• RFC 2569, "Mapping Between LPD and IPP Protocols"
• RFC 2639, "Internet Printing Protocol/1.0: Implementers Guide"

Version 1.1 of IPP is defined (at this time) by the following RFCs:

• RFC 2910, "IPP/1.1: Encoding and Transport"
• RFC 2911, "IPP/1.1: Model and Semantics"
• RFC 3196, "Internet Printing Protocol/1.1: Implementer's Guide"

Additional Internet Draft documents are still in the review stage and will add additional functionality to the protocol. For example, see also the following RFCs:

• RFC 3239, "IPP Requirements for Job, Printer, and Device Administrative Operations"
• RFC 3380, "IPP: Job and Printer Set Operations"
• RFC 3381, "IPP: Job Progress Attributes"
• RFC 3382, "IPP: The 'collection' Attribute Syntax"

Although standards bodies continue to refine and add new functionality to IPP, that has not stopped software vendors from using the protocol. If you want to keep abreast of newer developments in the IPP standards process, search for IPP at www rf c - editor . org, as well as the previously mentioned Web site of the IEEE working committee.

Printing Protocols and Printing Languages

A printer language is not the same as a printer protocol. For example, PostScript and PCL (Printer Control Language) are languages that describe how a document is to be rendered into the final printed product by the printer. When a printer is directly connected to a printer port on a computer, the printer language is important and is used by the software driver to format the information being sent to the printer.

A printer protocol, however, is used to send the formatted job, both data and instructions compiled using the printer language, to the print device. A few protocols will be detailed here that are more specific in their use and implementation; that is, they generally are used for communicating with a printer.

Several protocols are used for network printing. Some are proprietary protocols used by only one computer or network operating system (NOS). Others, such as 1pr/lpd—which was first developed for use on Unix systems—have been implemented in many environments. Data Link Control (DLC) is an IBM protocol that has been adapted for use on many printers although it is not used much today.

Also covered is the newest printing protocol: the Internet Printing Protocol (IPP), which was created by a working committee of the Internet Engineering Task Force (IETF). Development is underway for standards to further define this new protocol. You will find, however, that both Windows 2000/2003/XP and NetWare 6.x already support IPP. Novell even sells its iPrint as a separate product that can be used in a non-NetWare environment.

Using Ipr/lpd and the TCP Stream Protocols

TCP/IP was originally developed for the Unix operating system (OS), of which there are several flavors. Depending on the version of Unix (as well as Linux) running on a workstation or server, you will find that TCP/IP printing falls into one of two major types:

• BSD (Berkeley System Distribution) Spooling System
• SVR4 (System V, Release 4) Printing System

The BSD system uses the 1pr (line printer remote) program to send files to printers. The printers can be connected to a network, or to a computer. Whichever way, the 1pd (line printer daemon) receives these print requests and interacts with the Ipr to send the print job to the printer. The / et c/ p r int cap text file is used to set up characteristics for each printer. The SVR4 Unix system uses the 1p (line printer) program and the 1psched daemon (printer scheduler) to print files. Although the SVR4 system is considered more sophisticated because it has several utility commands for managing the system, the BSD system probably is easier to manage in a networked environment.

When using either of these methods, the actual print commands and data are sent to the printer in the payload section of a TCP/IP packet.

Although all Unix and Linux systems support TCP/IP printing, many support other protocols as well. For example, Red Hat Linux can also be configured to use SMB (Server Message Block) to connect to a Windows server (or a Unix/Linux computer configured to offer printing services using SMB).

The 1pr/lpd protocols work well, but are mostly used by older operating systems.

TCP/IP stream sockets the Unix provide yet another way to use TCP/IP to connect to a printer. Streams are a two-way communication TCP/IP session between the computer (or print server). When using TCP/IP streams, you need to specify a port (also known as a socket in Windows terminology). Thus the address of the networked printer, paired with a port number, provides a unique address so that the data exchange can be accomplished.

Data Link Control Protocol (DLC)

For all practical purposes, DLC is rarely found anymore within today's networks, although it might still be found on legacy systems. This IBM protocol was widely used during the early days of networked printing, as well as for other applications. However, more robust protocols, such as TCP/IP, have made this protocol a less desirable solution for network printing.

The DLC protocol was developed by IBM primarily for use in connecting to mainframe computers as part of its Systems Network Architecture (SNA) specifications. DLC can also be used to establish terminal sessions with AS/400 computers. In addition to the HP Jet Direct card, you will find that other vendors also make network cards for printers that can use DLC. For example, the Brother NC-600X and NC-2010h network cards both can be used for this purpose. However, you'll find that DLC no longer is present in Windows systems starting with Windows) XP.

Filtering on IP Addresses

To briefly review, the IP protocol is used by other higher-level protocols (such as TCP and UDP) to provide a connectionless best-effort data-delivery service. To do so, the IP datagram encapsulates the TCP or other protocol segment by adding source and destination addresses, port numbers, and other header information before sending the datagram farther down the protocol stack, where it is eventually transmitted on the wire bit-by-bit by the physical components of the network.

Routers can be configured easily to examine the contents of the IP header and drop packets that don't match a set of rules that the network or firewall administrator configures on the router. Perhaps the most obvious example is to filter out packets arriving from the Internet that have a source address that falls within the same network address range used on the internal network. Because such a packet, if it were indeed valid, would have to originate inside the network, it shouldn't be coming in from the outside! It is easy to forge IP packets so that the source address, as well as other header information, can be set to anything a hacker desires. A lot of programs are freely available on the Internet to do this.

When a packet with a source address is sent into your network, it's more likely that the destination server or workstation in your network will accept it as a valid packet, thinking it's coming from a user on the local network, and the packet will be processed as usual. Using this method, it's easy to get packets into your network and actually have them delivered, when they should not be.

This is only one example of a good reason to filter packets based on the IP addressing information in the packet header. Because addresses can be forged, and because it's not practical to list all the millions of addresses that are allocated to computers on the Internet and pick and choose, you need to be cautious when using this kind of specific filtering. For example, suppose your network becomes the subject of a denial-of-service attack. You can use a network analyzer to discover the source addresses of the packets, and quickly insert a rule in the router (or firewall product) database that drops all packets that come from the network from which those packets are coming.

Filtering Based on Protocols

In the IP packet, a field is used to indicate the type of protocol the packet is carrying data for. For example, if the IP packet is carrying TCP data, the protocol field in the IP head& is 6. If it's carrying an ICMP (Internet Control Message Protocol) message, the protocol number is 1. The capability to filter out certain protocols is useful because many of the protocols in use on the Internet were created many years ago when security was not as much of an issue as it is in today's commercial Internet.

Take ICMP, for example. The Ping utility makes use of ICMP packets to determine whether another host is reachable. An ICMP ECHO REQUEST packet is sent to the address of the host computer in question. If it receives the packet, the destination computer sends back an ICMP ECHO REPLY packet. Sounds simple and safe, doesn't it? Well, it is simple, but not necessarily safe. Inside your network, Ping can be a useful tool for quickly determining that somewhere along the network path something is wrong and a computer is not reachable, whether the destination you are pinging is inside your network or on the Internet.

However, just as you wouldn't give out your credit-card number to a stranger, it's not a good idea to give out any information about your network, especially the addresses of the computers on the network, to an outsider. And, that's exactly what the ping command can do. It's easy to write a program that sits back and cycles through a range of IP addresses, sending out ICMP ECHO REQUEST packets and looking to see what replies come back. This saves a malicious hacker time because he now knows that an IP address is in use and can proceed to further try to intrude and compromise the system. Because automated tools are available for continuing the hacker's probe, it's imperative that you keep your network address information secret.

If you've ever received those boring telemarketing calls during the early evening hours, you can understand how this works. The telemarketers just cycle through phone numbers until they get someone to pick up the phone and answer. Allowing ICMP ECHO REPLY packets to respond to requests from outside your network is the equivalent of picking up the phone. Although you can hang up on a telemarketing call, after a hacker has your network address, she can always try back later when you're not around and use a wile variety of tools to probe your system to determine what is needed to get inside.

For this reason, it's usually a good idea to block incoming ICMP ECHO REQUEST packets. You probably don't want to block outgoing packets of the same sort, because they serve a useful purpose. You can allow users inside your network to Ping other servers on the Internet. For example, suppose you want to place an order with a business that has a website, yet it doesn't pop up in your browser when you try to get to its home page. You can use Ping to determine whether the business's computer is on the Net and functioning, and then from there start your troubleshooting efforts to find out why you can't bring up the business's Web page. If you Ping the site and get no response, you can be sure that either it's down or somewhere along the network path a router or another device is not letting traffic get through.

The same goes for you if you offer a service on the Internet. However, in such a case, you should make sure that your Web servers are highly secured and located on a network segment that can limit the damage should these servers be compromised. This network segment is called a demilitarized zone (DMZ).

Another utility that uses ICMP is Tracert. This command probes the network path and returns a list of all the routers and other intermediary devices it passes through to get to a destination address. Again, this is a useful tool when used properly, but you should block this sort of packet at your firewall. Do you want outsiders to know the addresses of routers and other devices on your network? After an outsider has the address and knows that a computer is online using that address, it's easy to use one of the many hacker tools available on the Internet to begin breaking into the computer.

Protocols, Protocols, and More Protocols!

Because the functions provided by a VPN include tunneling, data integrity, and authentication, it makes sense that a VPN is not created using a single protocol. Instead, several protocols can be used to create a VPN, each performing a particular function. In this section the following protocols are briefly examined:

• Internet Protocol Security (IPSec)
• Point-to-Point Tunneling Protocol (PPTP)
• Layer Two Tunneling Protocol (L2TP)

For the most part, only IPSec should be a major factor in VPNs in the coming years. PPTP was used by Windows NT 4.0 as part of its VPN package, and L2TP has replaced it in Windows 2000 and Windows XP VPNs. L2TP is basically just the PPTP protocol combined with the L2F protocol developed by Cisco. However, most VPN vendors are using the IPSec protocols instead, which are described in greater detail than PPTP and L2TP. The IPSec protocols incorporate some of the security mechanisms that were originally designed to be included in IPv6 but have been adapted for use in the existing IPv4 network.

Note

Before you adopt a particular VPN solution, you should determine if the connection will be used by PDAs, Pocket PCs, or smartphones. Many of these devices do not include integrated VPN support, but in some cases updates to the operating system or third-party software does provide this functionality as an additional feature. IPSec is the most common VPN protocol supported by hand-held devices.

IPSec Protocols

As noted previously, IPSec is the emerging standard being adopted by more and more VPN vendors. IPSec was derived from concepts that were originally designed to provide for secure communications in the next generation of the IP protocol, IPv6, which is gradually being developed.

Although Microsoft chooses to use L2TP and IPSec in combination as its VPN solution for Windows 2000 and Windows XP, many hardware and software vendors are sticking with a simple IPSec solution.

The good news is that if you decide on an all-IPSec solution, you can be virtually assured that equipment (or software) from one vendor to another will work together. If you have an all-Windows server environment, this might be of no concern. For those who operate multiprotocol networks, IPSec might be the best choice. As noted previously, IPSec is also the most widely supported VPN protocol on handheld devices.

IPSec is a standard defined in several Request for Comments (RFC) documents. IPSec is transparent to the end user and can traverse the Internet using standard IPv4 routers and other equipment without requiring any modification because it operates at the Network layer. IPSec is also flexible, allowing for the negotiation and use of many different encryption and authentication techniques.

The three main components of IPSec are the following:

• Internet Key Exchange (IKE)—This is the protocol defined in RFC 2048, "Internet Security Association and Key Management Protocol (ISAKMP)," which defines a method for the secure exchange of the initial encryption keys between the two endpoints of the VPN link.
• Authentication Header (AH)—This protocol, defined in RFC 1826, "The Authentication Header," provides for inserting a standard IPv4 header into an additional header that can be used to ensure the integrity of the header information and payload as the packet makes its way through the Internet. AH does not encrypt the actual IP payload data, but instead provides a mechanism to determine whether the payload or header has been tampered with.
• Encapsulating Security Payload (ESP)—This protocol performs the actual encryption of the data carried in the IP packet so that it cannot be understood by anyone who might intercept your data stream.