Tcpip Security

.. s in DNS [RFC2065] 2.7. The lack of unique identifiers When the Internet was still young, back in the 1980’s, one could use an IP address to safely identify and locate a host. Addresses were both spatially unique (no one else had an identical address) and temporally unique (addresses didn’t change). However, this is no longer the case [RFC2101].

Today, IP addresses may exhibit seemly strange behavior that makes identifying and locating hosts much harder. The widespread use of protocols such as PPP/SLIP [RFC1990] and DHCP [RFC1541] allow a specific host’s address to change over time: per-connection in the case of PPP/SLIP, while DHCP allows hosts to lease IP addresses for arbitrary lengths of time. On even larger time scales, details in the current Internet routing structure (i.e., Classless InterDomain Routing, CIDR [RFC1519]) may require that if a domain changes service providers, they will have to change their assigned range of IP addresses. Firewalls, proxy socket servers, and other Network Address Translators further complicate the use of IP addresses as identifiers, because they may translate addresses as traffic moves between the internal and external networks. Different hosts may appear to be using identical IP addresses, or different IP addresses may be the same host.

Thus, IP addresses can no longer be used to uniquely identify a host, even over short time periods. Any security schemes which rely upon IP addresses remaining temporally or spatially unique may have vulnerabilities. 3. Solutions to Problems There are a plethora of papers discussing theoretical weaknesses in the TCP/IP protocol, with more being published all the time. For each paper which warns readers about Security Weakness X, there seems to be a corresponding chunk of code that some individual has written which utilizes this weakness in real life, on actual computers. Corresponding to the SYN flooding attack there is a SYNflood.c freely available for download, which, when compiled and run, will attempt to deny all access to a target host by flooding it with connection requests. There are packages (spoofit is one) which offer menu-driven interfaces for connection-hijacking. Indeed, there are actual, working implementations of all security weaknesses discussed so far.

Going from the paper to the exploit, as the implementations are known, is sometimes not a trivial task; it often requires significant hands-on networking knowledge. The user of the exploit, on the other hand, is not required to understand all the details; the exploits are often well-documented and user-friendly. With more people downloading them every day, it is unremarkable that we have seen an increase in break-ins over the last few years [Bellovin92]. Given that there are often well-written, easy to use implementations of the security vulnerabilities discussed so far, it should come as no surprise that much effort has gone into the elimination of these vulnerabilities. Since TCP/IP is the medium linking the entire Internet together, it is easy to see that billions of dollars worth of hardware are at risk here, discounting entirely the monetary worth of the information on those machines. It would be very nice to squelch these vulnerabilities. Unfortunately, most of the attacks described in this paper are based on inherent vulnerabilities in the TCP/IP protocol; without reworking TCP/IP, there may be little that can be done! While this may indeed be what eventually solves these problems, it is not a task to be undertaken lightly; if there is any way to avoid having to rebuild the Internet with a new version of TCP/IP, people will prefer it.

Let’s explore what can be done within the current incarnation of TCP/IP. 3.1. Problems with Accepting Connections The SYN attacks described earlier are used as a denial-of-service attack to prevent anyone from using a particular host. Often times, this is used as a stepping stone towards a more complicated spoofing attack. This first stepping stone is one of the inherent vulnerabilities in TCP/IP, based on what it was designed to do. As a connection-oriented protocol used to link together machines across the world, TCP/IP must accept some variance in connection-times; i.e.

the computers in New York expect to make connections with other computers in New York as well as computers across the globe. Since the time for messages to pass back and forth between the computers may vary, it is reasonable to allow a generous amount of time for the connection to be completed. As long as this amount of time is finite, then a nearby computer will be able to send a large number of uncompleted connection-requests, and eventually tie up the target host. The very fact that we want TCP/IP to be friendly and connect to computers of varying distances means that these SYN attacks are difficult to eradicate completely. There are, however, some choices that can be made to decrease vulnerability.

Increasing the number of allowable outstanding connections can make more work for the attacker (or dynamically allocating them instead of relying on a fixed maximum). Another practical solution is to decrease the timeout period (currently 75 seconds) to something smaller, thereby increasing the workload for the attacker again. In practice, these solutions may reduce the vulnerability to something negligible, but it should be noted that so long as the timeout period and maximum number of incomplete connections is finite, the problem still exists. 3.2. Problems with Authentication The utter lack of authentication with IP packets is a general weakness with TCP/IP.

Without authentication, there really is no guarantee that a packet comes from where its source field claims it comes from. This is the foundation of all IP spoofing and consequently, the major issue in IP security. There are many different ways to capitalize on this weakness; we have provided an overview of the problems that come about from the lack of authentication, but our discussion of the myriad ways this may be taken advantage of could never really be complete. Since a lack of authentication is the broadest, more crippling weakness in TCP/IP, we would really like to clamp down on it as much as possible. Since the conventional IP version 4 does not typically use authentication, it is not possible to completely eradicate the threat in the most ideal way, by providing it at the IP level. However, we cannot simply throw up our hands in defeat; there are several techniques we may employ to blunt this weapon. 3.2.1. Preventing Sequence Guessing For host A to successfully impersonate host B in a connection with host C, A must be able to acquire the sequence number which C sends back (to B).

There are a number of ways to get at this number, but one popular technique is to simply guess the number that will be used. If we could prevent people from being able to guess the next sequence number used for a connection based on the previous sequence number used in a connection, we would be able to nip this problem in the bud. In Bellovin’s paper, Security Problems in the TCP/IP Protocol Suite, he outlines an essential problem with the TCP specifications, at least from a security standpoint. Berkeley systems are extremely easy to analyze; their method of incrementing the sequence counter by a constant value every second, and incrementing it by half that for every connection established is trivial to anticipate. But the Berkeley system does not follow TCP specifications, which require the variable to be incremented approximately 250,000 times per second.

Perhaps if we followed the specifications for the protocol we could eliminate sequence guessing. Let us consider whether a counter that operated at a true 250,000 hz rate would help. For simplicity’s sake, we will ignore the problem of other connections occurring, and only consider the fixed rate of change of this counter. To learn a current sequence number, one must send a SYN packet, and receive a response. The first spoof packet, which triggers generation of the next sequence number, can immediately follow the server’s response to the probe packet.

The sequence number used in the response is uniquely determined by the time between the origination of the message and the receipt at the server of the message. But this number is precisely the round-trip time between [spoofer] and [server]. Thus, if the spoofer can accurately measure (and predict) that time, even a 4 microsecond clock will not defeat this attack. How accurately can the trip time be measured? If we assume that stability is good, we can probably bound it within 10 milliseconds or so. Clearly, the Internet does not exhibit such stability over the long-term, but it is often good enough over the short term. There is thus an uncertainty of 2500 in the possible value for [the guessed sequence number].

If each trial takes 5 seconds, to allow time to re-measure the round-trip time, and intruder would have a reasonable likelihood of succeeding in 7500 seconds, and a near certainty within a day. More predictable (i.e., higher quality) networks, or more accurate measurements, would improve the odds even further in the intruder’s favor. Clearly, simply following the letter of the TCP specification is not good enough. [Bellovin89] So it appears that even following the TCP specifications will not work. What can be done? Bellovin goes on to suggest that we utilize a random number generator, which would make things hopefully harder to analyze.

He further suggests that DES could be used in place of a random number generator, since it is well-studied, and the encryptions of an incrementing counter are quite varied and difficult to predict. Of course, all methods of generating pseudorandom numbers are subject to analysis; if nothing else, once the seed is discovered, the whole sequence is known. Whatever we choose as a solution, we should certainly avoid using a simple, easily predicted sequence number generator. 3.2.2. The Benefits of Firewalls A firewall can be a powerful tool in the prevention of would-be spoofers. Putting aside the proxy-services normally offered by firewalls, we concentrate on the benefits derived from packet filtering techniques.

The important part about firewalls from an IP spoofing perspective is that they clearly delineate outside the firewall from inside the firewall; everything inside must go through the ‘inside’ port on the firewall, and everything outside must come in through the ‘outside’ port [Ranum92]. This means that the packet filtering done in the firewall can drop suspicious packets! Suppose the filter sees a packet come from the outside that claims to have a source inside the firewall. It’s a spoofed packet, and should be dropped; it’s claiming to come from inside, but it’s coming from outside [Chapman92]. Likewise, if some packet attempts to leave the firewall claiming to be from anywhere other than inside the known subnet, it can be dropped immediately as well [Ranum92]. In a sense, this sort of filtering partitions the Internet into little zones, none of which can spoof each other. However, even with this sort of filtering going on, spoofing within the subnet cannot be prevented. 3.2.3.

The Benefits of TCP Wrappers Additional protection against authentication weaknesses can be gained from the use of TCP wrappers. A TCP wrapper is a small program run in place of the services which the inet daemon normally starts. For example, with TCP wrappers in place, when a user attempts to rlogin, the standard rlogin program is not run directly; first, the tiny wrapper program is run, which performs some security functions, and then, assuming everything checks out, the actual rlogin program is run. These are a trivial thing to install, nothing like the implementation of a firewall. A typical implementation provides tiny daemon wrapper programs that can be installed without any changes to existing software or to existing configuration files.

The wrappers report the name of the client host and of the requested service; the wrappers do not exchange information with the client or server applications, so are essentially invisible to the users. [Venema92] The usual benefit gained from installing a wrapper is that you can log information about which users are requesting which services, and track suspicious behavior, or suspected persons. Venema discusses how it is possible to add tripwires to the TCP wrapper packages; instead of merely dropping users who are attempting to use some service when they shouldn’t, one can reverse-finger them to gain additional tracking information. Or, one can turn on a more stringent security standard, expecting an attack. And there are some added perks which help defeat some forms of spoofing: some of the inet services, notably rsh and rlogin, rely on name-based authentication, which can be spoofed [Schuba and Spafford94].

If a local copy of names and addresses is available, a TCP wrapper can verify that someone starting up rsh or rlogin has an IP address that agrees with the name they claim. Also, it is likely that a machine may not have local tables, and might have to ask DNS for a name-IP correspondence.. this leaves the machine very vulnerable to anyone doing DNS spoofing. A TCP wrapper can be configured to ask multiple DNS servers for the correspondence and wait for consensus. The benefits that can be gained from TCP wrappers are not in any way impregnable armor; the consensus is that they are not useful in preventing the general case of IP spoofing. However, they do provide some armor against specific variations on the spoofing problem, and they provide a space for extra checks to be inserted where they may not be expected.

For a further discussion of this topic, see [Venema92]. 3.2.4. Add-On Authentication: Kerberos Another method of limiting an attacker’s spoofing abilities is to add authentication onto the application layer. Of course, just adding authentication is not enough without adding encryption; otherwise, after some initial application-level authentication, a hijacking attack may still be successful. An authentication between two parties which exchanges a session key, however is secure; even though the IP packets transmitted back and forth are not individually authenticated, they are all encrypted with the secure session key. This scheme is the goal of the Kerberos Authentication System, developed at MIT. The Kerberos system uses cryptographic authentication algorithms to ensure that a user is really who s/he claims to be, and once this is established, an exchanged session key is used to encrypt all transmissions of whatever service the user has requested.

Without knowledge of this session key, it is impossible for an attacker to spoof meaningful transmissions between sources. Since this key is generated based on secret keys known only to the actual user and the trusted server, it is very hard for an attacker to acquire. The Kerberos system is resilient to replay attacks as well. Kerberos is generally considered to significantly increase the security of a network, although it is not a panacea. There are problems using Kerberos to authenticate between two machines (instead of a user and a machine), and there are difficulties involving where the keys are cached on a multiuser machine. For a discussion of weaknesses in Kerberos, see [Bellovin, Merritt91]. 3.2.5.

Encrypting Individual IP Packets (SKIP) Instead of exchanging a session key, as we might do via Kerberos for a telnet session, we could choose to encrypt all IP packets, all the time, at the IP level. Naturally, we must encrypt them in a way that the destination can successfully decrypt them. There is a special key-distribution scheme designed for packet-level encryption called the Simple Key-Management for Internet Protocols (SKIP). SKIP assumes that each site in the network has a public key, which can be used to create many keys between two sites. The basic idea of the algorithm is to encapsulate the packet-key (the key to decrypt that packet) inside the packet, and encrypt that with shared secret between the two sites.

The SKIP technique also provides an easy method of changing the shared secret between two sites [Aziz, Patterson96]. Since this method is not session-based, it can cover all aspects of TCP/IP communication, not merely applications. 4. IP Version 6 The problem of authentication within IPv4 is a challenging one. While firewalls, wrappers, Kerberos and SKIP may help curb spoofers, they are add-ons designed to shore up the deficiencies in IPv4. They are not guarantees of security, and they involve significant efforts for each network that wants to implement them.

Looking back, it would have been better if security had been a goal of the TCP/IP protocol suite from the beginning. Although it is not possible to go back in time and change history, we can look forward to the future. In the 1990s, TCP/IP security is a concern, and a newer version of the protocol has been developed with this concern in mind. In fact, it has been developed with a number of new concerns in mind. One important motivating factor for the development of a new protocol is that the address space is running out. A lot of experience has been gained in the years of usage of IPv4 about what tasks IP should perform, and the new version of IP is redesigned to reflect that experience.

The new version will eventually replace the current version. The current version of the protocol is 4, and the new version designed is version 6, referred to as IPv6. IPv6 attempts to address the newfound knowledge of the importance of routing, security, etc. It promises to provide authentication and encryption on the Internet and could solve a lot of the existing problems with TCP/IP. For a complete description of IPv6, we refer the reader to [Huitema].

We will restrict our focus to the security features introduced in IPv6. IPv6 Header The IPv6 header consists of 64-bit initial header fields, followed by 128-bit source addresses and destination addresses. Version Priority Flow Label Payload Length Next Header Hop limit Source Address Destination Address 1Figure 10. IPv6 Base Header The header shown in Figure 10 is the IPv6 base header. There are no options in the base-header. Instead, the options are specified as extension headers.

These extension headers are placed between the base header and the payload. Payload here refers to the data that is carried by IPv6. The current IPv6 specification defines six extension headers: Hop-by-hop options header Routing Header Fragment Header Authentication Header Encrypted security payload Destination options header For example, if there was an authentication header following the IPv6 base header, we will have a chain of headers as shown in Figure 11. Each header indicates the type of the next header that immediately follows it. In Figure 11, the Base Header indicates that the next header that follows itself is the Authentication header.

The Authentication Header indicates that the TCP header and data follow. Figure 11. Chaining of IPv6 Header Security options in IPv6 IPv6 includes two extension headers that serve as security options, the Authentication Header and the Encryption header. The Authentication Header allows the recipient to ascertain the identity of the sender and the encryption Header ensures that only the recipient is able to look at the contents of the message. Both these options in IPv6 require that the sender and the receiver agree on parameters such as the key, the authentication or the encryption algorithm, and the lifetime of the key. This is termed as a security association in IPv6. The recipient of a packet has to verify or decrypt only in the context of the security association between the sender and the receiver. The security association or the security context is identified using the security parameter index (SPI).

The SPI is normally negotiated as part of the key-exchange procedure. The SPI is usually chosen by the receiver for every (sender, receiver) pair. The receiver uses the SPI to identify the specific security context. In case of multi-casting, where there are multiple receivers, the SPI will be common to all the members of the multicast group. The SPI will be used by all the members to correlate the security context. Key Distribution in IPv6 The establishment of security associations is crucial to both authentication and encryption. During a security association, the keys, other information about the keys such as the life-time of the key, the authentication and the encryption algorithms are exchanged between a receiver and a sender.

In addition to this, this association context can be later referred to using the SPI, the Security Parameter Index. Efficient deployment of IPv6 security will rely on an efficient key distribution mechanism. It is desirable that the key distribution be a zero-knowledge exchange, that is the sender and the receiver should be able to exchange keys without agreeing on any secret a-priori. The Internet community has not yet agreed upon a key distribution method. The leading proposal is called Photuris, which is a modification of the Diffie-Hellman key-exchange algorithm.

[Diffie, Hellman] Diffie Hellman Algorithm Diffie-Hellman was the first public-key algorithm invented, and dates back to 1976. It can be used to generate a secret key, but not for encrypting and decrypting messages. Assume parties A and B are involved and want to generate a secret key. A and B agree on a large prime number, n and a generator g, such that g is primitive mod n. The two integers, n and g do not have to be secret.

A and B can agree to them over an insecure channel. A chooses a large random number x, and computes X = gx mod n A then sends X to B. B chooses a large random, y and computes Y = gy mod n B sends Y to A. A computes k = Yx mod n B computes k’ = Xy mod n After the initial exchange between A and B, A knows x and Y, and B knows X and y. Since this is exchanged over an insecure link, X and Y could be found out by a third-party and are public. But either x or y is not obtainable by the third party.

Steps 3 and 4 yield the session key Z, Z = k = k’ = gxy mod n The computed key Z, can then be used by either the encryption or the authentication algorithm. The Diffie-Hellman algorithm derives its security from the difficulty of calculating discrete logarithms in a finite field, as compared with the ease of exponentiation in the same field. It is difficult for a third-party to compute the discrete logarithm and recover x or y. The choice of g and n is important, and n must be large. As observed earlier, g must be primitive mod n.

One could choose g as small as possible, and usually it is a one-digit number. The security of the system is based on the difficulty of factoring numbers the same size of n. Other mathematical techniques, such as elliptic curve groups could also be used for the key exchange. ADVANTAGES OF DIFFIE-HELLMAN SCHEME The Diffie-Hellman algorithm has two distinct advantages, that could be made use of in protocols. The keys could be computed only when needed.

This makes sure that there is no necessity for a key to remain secret for a long period of time, thereby overcoming the problem of keeping a secret! The key exchange does not require any key-server and can be easily deployed. DISADVANTAGES The original Diffie-Hellman algorithm has a known set of weaknesses. There is no identity of the parties involved in the exchange. It is easily susceptible to man-in-the-middle attacks. A third party C, can exchange keys with both A and B, and can listen to the communication between A and B. The algorithm is computationally intensive.

Each multiplication varies as the square of n, which must be very large. The number of multiplications required by the exponentiation increases with increasing values of the exponent, x or y in this case. The computational nature of the algorithm could be used in a denial-of-service attack very easily. Photuris Photuris tries to rectify certain problems in the Diffie-Hellman algorithm. The algorithm was named Photuris as a tribute to unknown engineers. The Internet draft, by Phil Karn and Simpson describes Photuris.

[Karn96]. It will probably be revised before being published as an Internet RFC. KEY-EXCHANGE IN PHOTURIS Photuris starts using a cookie exchange, which precedes the Diffie-Hellman key exchange. After the keys are exchanged, signed messages are sent over the new protected channels. All Photuris messages are exchanged using UDP, the unreliable transport equivalent of TCP.

The Photuris key exchange A sends a cookie-request to B. Cookie-request ( initiator cookie, group list) The cookie request contains a 128-bit initiator cookie. The initiator cookie is a random number used as an identification for the key-exchange. The cookie request also contains a list of groups. These groups designate the finite fields over which the Diffie-Hellman exchange is carried out.

The current draft supports three groups: the elliptic curve group, the exponential group based on a 1024-bit prime with 2 as the generator, and another exponential group with 5 as the generator. B on receipt of the cookie-request, selects one of the groups provided by A and constructs a cookie-response to send to A. Cookie-response( initiator cookie, responder cookie, selected group, responder attributes) The cookie-response from B contains the responder-cookie. The responder-cookie is computed by applying a one-way function such as MD5 to a string composed of the source address and the UDP port of the message, the initiator cookie and a secret number chosen by B. B does not usually maintain any memory of the exchange. B also sends a list of attributes to A. The list of attributes contains a set of transforms in order of B’s preference.

This feature allows A and B to use any of the listed methods for signatures and encryption. The standard specifies MD5 as the default one-way function to be used for Authentication, and DES-CBC as the encryption scheme. A and B now enter the Diffie-Hellman exchange phase, where they exchange the half-keys and generate a session key k. The Key-request message is sent by A to B. The message contains A’s security parameter index (SPI), in addition to the Diffie-Hellman public value. A lifetime for the request is also sent in the key-request message.

The initiator transform field indicates the transforms chosen by A out of B’s transform priorities. A also sends its own transform priority list using the Initiator attributes. The Group Index, indicates the mathematical group to be used in the Diffie-Hellman scheme. A indicates its value for the Security Parameter Index in the initiator SPI field. Key Request (Group Index, Initiator Lifetime, initiator SPI, Initiator Cookie, Responder Cookie, Initiator Public Value, Initiator Transform, Initiator Attributes) B sends its Diffie-Hellman half-key using the Key-response message.

The parameters to the message are similar to the Key-request message. Key Response ( Responder Lifetime, Responder SPI, Initiator Cookie, Responder Cookie, Responder Transform, Responder Public Value, Key Transform) The cookie exchange and the Diffie-Hellman exchange do not protect against the man-in-the-middle attack. This problem can be solved by requiring A to send its signature to B, and B could verify the signature. This assumes that A has B’s certificate, and B has A’s certificate. These certificates might have been signed by a trusted authority outside the protocol. (initiator-cookie, responder-cookie, signature, certificate) : A B and B A A signs the session-key concatenated with the public value of the key, B’s public value, and optionally the identifying public key, certificate, or the distinguishing name of A.

Inclusion of both public values in the signature guarantees that a third party, the middle man has not substituted its own value. If B is able to verify A’s signature correctly, then B sends its own signature to A, for A to authenticate B. In case of a failure, the security association is dropped. Key Distribution for Multicast groups The Diffie-Hellman scheme can be easily extended for three or more parties. [Schneier96]. But for multi-casting, it is ideal to have a key-server distribute a single key to all the parties concerned.

The Authentication Header in IPv6 IPv6 uses the daisy chaining of options to support authentication as well. One of the extension header that can be sent after the base header could be an authentication header (AH). The AH has a very simple format as shown in Figure 12. The SPI or the Security Parameters Index, denotes the security context of the sender and the receiver. SPI would be used by the receiver to retrieve the security context of the sender.

The sender computes a signature of the payload data, some fields of the IPv6 header and the extension headers, and this signature is sent as the authentication data. The algorithm used for the signature is negotiated as part of the key-exchange process. The MD5 algorithm is specified as a default to make sure all implementations can at least use one common algorithm. The receiver retrieves the appropriate security context, using the SPI indicated and verifies the signature. There are intrinsic details in creating the signature that are interesting to note.

The Authentication header has to ensure that the entire IPv6 packet is not modified or tampered with. But, there are certain fields in the IPv6 header that need to be modified by routers on the way. For example, the hop count field is decremented at every hop. Some hop by hop options may also be updated in transit. In order to take care of this, the sender needs to prepare a special version of the message that is independent of the changes that can take place in transit, such as setting the hop count to zero. The Authentication Option could be used between routers or between end-nodes.

Using it between routers could solve common routing attacks that are prevalent today. The IP spoofing attacks could be prevented by using the Authentication option. Next Header Length RESERVED Security Parameters Index (SPI) Authentication Data Figure 12. IPv6 Authentication Header Encryption Header in IPv6 The Encrypted Security Payload (ESP) header, when used forms the last of the extension headers in the chain of headers (see Figure 13). All data following the encryption header is encrypted, and the data preceding the encryption header is in plain-text. The format of the encryption header is shown in Figure 14.

The SPI is used by the receiver to retrieve the security context of the sender, and then decrypt the data following it. IPv6 Base Header Extension Headers ESP header Encryption header Figure 13. Encryption using the ESP header The encryption scheme is negotiated during the key-exchange. DES-CBC is the default encryption scheme that is supported. SPI (Security Parameter Index) Encrypted Data And Parameters Figure 14. The ESP Header Application of Security Options in IPv6 IPv6 has introduced network layer authentication and encryption.

This enables the use of both encryption and authentication by all protocol layers above IPv6. The routing protocols, that are totally insecure today, could be made secure using IPv6 security options. Secure channels could be established over the insecure Internet. Securing Routing protocols Network integrity depends on the integrity of the routing protocols. If the routing protocols are not secure, then they cannot guarantee network integrity.

The protocols that are used today between routers, RIP, OSPF and others are run over an insecure link. If intruders forge the routing upd.