1. Field of the Invention
The present invention relates to the formation and use of secure network connections. More specifically, the present invention relates to safely scanning network connections without sacrificing user privacy.
2. Description of the Related Art
Computer networks, and in particular Wide Area Networks (WANs) such as the Internet, provide opportunities for the misuse and abuse of communications traveling thereover. For example, two users communicating via the WAN may have their communications intercepted and/or altered. Also, it is possible for one user to misrepresent his or her identity to another user. As a final example, a user may utilize network resources and communications to disrupt all or part of the network.
Thus, there is a need for both privacy and authentication between users of the WAN communicating with one another. In other words, users should be able to rely on the fact that their transmissions will not be intercepted or altered, and that transmissions from someone purporting to be a particular user do in fact originate from that user.
One type of defense against ill-intentioned uses of the WAN is a device operating at the edge of a private network, such as a Gateway, Firewall or some other dedicated network appliance. Such a device operates to filter transmissions between the private network and the WAN and/or to protect the transmissions that do go through by encrypting/decrypting (i.e., encoding/decoding) those transmissions.
Other related types of defenses function by establishing the identity of a sender and/or recipient before sending/receiving a communication. Still other defenses include establishing a secure channel between two communicating devices.
A particular conventional protocol for providing security between devices operating over an Internet Protocol (IP) network is known as IPsec. Short for IP Security, IPsec is a set of protocols supporting the secure exchange of IP packets at a network layer. Two of the protocols used are the Authentication Header protocol (AH) and the Encapsulating Security Payload protocol (ESP).
AH is designed to ensure that transmitted packets are not altered during transit over the network, but does not protect the contents of the packets from being viewed by other users of the network such as intercepting parties. ESP, on the other hand, ensures the confidentiality of the packet contents. ESP provides an optional authentication mechanism; however, this mechanism is only for authenticating the data payload of the packet (and associated ESP headers/trailers). Therefore, ESP does not authenticate an IP Header of a packet indicating an original IP address on the network from which the packet originated. It is also possible to use AH and ESP in conjunction with one another, in order to achieve the advantages of both.
Whether using AH or ESP, IPsec operates in either transport or tunnel mode. Transport mode is often used in host-to-host communications; i.e., when the peer devices are the endpoints of communication. Transport mode is most useful within an overall IPsec environment including the two endpoints. Tunnel mode is typically used in communications between an IPsec-protected system and some other endpoint, such as communications sent from a private network over the Internet. In tunnel mode, the payload of a secured IP packet carries another packet containing the actual data payload to be transmitted.
A common use of the tunnel mode is to implement a Virtual Private Network (VPN). VPNs are networks that use publicly-available network resources, such as the Internet, to construct a network accessible only by selected parties. For example, a company may create its own version of a Local Area Network (LAN) using the Internet, or a worker working from a remote location may be able to utilize company resources at a company headquarters.
In order to implement the various protocols and modes of IPsec such as those discussed above, a security association (SA) is typically formed. An IPsec SA is essentially a contract or agreement between parties defining conditions according to which the two parties will communicate. For example, an IPsec SA is typically a one-way connection that defines, for example, encryption algorithms to be used during information exchange. SAs are defined by such parameters as an IP destination address and a security protocol identifier (e.g., AH or ESP). SAs typically include a security parameter index (SPI), which is a 32 bit identification number.
If an IPsec SA is considered a contract or agreement, then the terms thereof can be considered to be negotiated by a separate protocol (or manually). In other words, both communicating parties must agree on actions that will be taken on communicated packets in order to encrypt/decrypt those packets. One such protocol is known as the Internet Security Association and Key Management Protocol (ISAKMP), and one implementation of ISAKMP is known as the Internet Key Exchange (IKE).
IKE typically operates in two phases. In a first phase, parties agree as to how to protect further negotiation traffic. For example, IKE may authenticate a sender by virtue .of, for example, public key encryption, also known as Diffie-Hellman encryption. In public key encryption, each user generates a public and private key, where the public key is then sent to the other party. When each user combines his own private key with the other's public key (and perhaps additional information), they each obtain an identical secret key. This secret key serves as a basis for deriving subsequent cryptographic keys.
In this way, a first user can encrypt a message using the second user's public key, and then only the second user (using his own private key) will be able to decrypt and receive the message.
Also, a first user can use his private key to sign a message and the second user, with the first user's public key, can receive and authenticate the transmitted message. Thus, the first user is authenticated to the second user as the one who sent the transmission; i.e., a “digital signature”.
This latter methodology, however, does nothing to guard against the eventuality that a third party is merely pretending to be the sender (i.e., the first user) when the keys were generated in the first place. Therefore, independent and trusted Certification Authorities (CAs) exist which issue digital certificates verifying the association of a public key with a particular user, along with other identifying information.
There are two primary modes for phase 1 of IKE: main mode and aggressive mode. Main mode, generally speaking, is a more involved but more secure method. Aggressive mode, though faster, sacrifices identity protection; however, using the public key encryption methodology just discussed obviates the need for this feature.
In a second phase, IKE negotiates the actual IPsec SA (over which the actual application layer data exchanges will take place) by setting up the encryption/authentication keys for the AH and/or ESP protocols. In particular, “quick mode” negotiates the SAs for general purpose IPsec communications. Also, it should be noted that, typically, only one phase 1 negotiation is needed for an associated plurality of phase 2 operations by a plurality of peer devices. This allows the multiple peer devices to each take advantage of the phase 1 proceedings, thereby establishing secure connections more quickly and more easily.
As shown in the above discussion, therefore, various solutions exist for implementing private and authenticated network communications.
However, the various conventional solutions suffer from a variety of shortcomings. For example, it is often the case that one device participating in a secure network connection such as IPsec is located behind a gateway or firewall device. As is known, such devices are typically located on the edge of a private network, and serve to intercept and/or route traffic between the private network devices and other devices, frequently via a public network such as the Internet. Firewalls may be implemented by, for example, corporate network administrators and Internet Service Providers (ISPs).
Such firewall devices conventionally serve a number of functions; for example, they are often used to scan or filter network traffic so as to prevent unauthorized data or data types from entering the private networks. In this way, firewalls may prevent viewing of sites prohibited by network administrators, such as gambling sites on the Internet. They may also prohibit data that is deemed likely to contain viruses or other files that could prove harmful to the network. Firewalls may also be used as the sole entry point to the private network from outside of the private network, so that network administrators may require a username/password combination at the firewall in order to allow only authorized users access.
Conventional firewalls, however, are not designed to operate well in conjunction with security protocols discussed above, such as IPsec. For example, if a device on a public network wishes to communicate securely with a device operating behind a firewall on a private network, no satisfactory solution exists.
One conventional solution in this scenario is to simply let encrypted data pass unhindered through the firewall. This solution is shown in FIG. 1A, where devices 100 and 140 (operating on public and private networks 120 and 130, respectively) communicate via firewall 110. However, this solution suffers from the obvious problem that it does not allow the firewall to perform its function of scanning/filtering the data, and may therefore let harmful or undesirable traffic onto the private network.
Another solution would be to establish a secure channel between the remote device and the firewall. Then, decryption can occur at or before the firewall, after which the decrypted packets can be scanned/filtered and forwarded to the recipient device within the private network. However, this solution suffers from the fact that operators of the firewall will have access to the decrypted information intended for the recipient device. In other words, typically a firewall device is not a customer device; it is a service provider device, and, as such, it is not typically secure or desirable (from the customer's viewpoint) to allow access to decrypted packets there. Moreover, if it is necessary to establish a second secure connection between the firewall and the device on the private network in order to re-encrypt the data packets (e.g., negotiate a second SA and set up a second IPsec session), then non-negligible computing resources must be devoted to this task.
Therefore, what is needed is a system and method for establishing a secure connection between a private network device and a second device, even over a WAN such as the Internet, without permitting a firewall operator to access a content of data transmitted via the connection.
USPTO Backgrounds
USPTO Backgrounds