The present invention relates to providing network security to networks of any or arbitrary size. In particular, this invention relates to secure subnetworks within a general purpose network.
Most companies today have a strong network perimeter defense in place, and yet damaging attacks occur frequently. Many businesses extend their operations to the Internet, linking together their suppliers, customers, employees and partners. A Web-based front-end allows traditional back-end applications to be accessed from anywhere in the world.
There is a well-understood need to protect the network perimeter and to implement access control between an Intranet and the Internet. IT (information technology) departments can choose from a large arsenal of tools, including ubiquitous firewalls, SSL (secure socket layer), and VPN (virtual private network) solutions. Strong encryption and authentication solutions can be deployed to protect sensitive information as it crosses public networks. However, once the network perimeter has been crossed, as shown in
Protecting sensitive data and back-end servers inside enterprise networks is a difficult task. Many enterprises deploy legacy systems and applications that lack the means to protect themselves. While VPNs are effective for protecting data sent between isolated networks, they are virtually impossible or impractical to deploy inside existing enterprise Intranets without extensive rewiring, reconfiguration and major disruption of normal operations.
Techniques used in a network that includes non-trusted devices, in which packets of information communicated across the network include network address information for a source device and a destination device of the packets of information are described herein. According to one embodiment, a process of establishing a more secure subnetwork includes inserting at least one credential into at least one packet of information issued by the source device, the credential assessable by a plurality of devices on the network, enabling transmission of the at least one packet of information from the source device to at least one destination device on the subnetwork, assessing the credential by at least one of the devices, and permitting the source device to communicate with the destination device conditioned upon the results of the assessing step. Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
The present invention will now be described in detail with reference to several embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention. The features and advantages of embodiments may be better understood with reference to the drawings and discussions that follow.
Aspects, features and advantages of exemplary embodiments of the present invention will become better understood with regard to the following description in connection with the accompanying drawing(s). It should be apparent to those skilled in the art that the described embodiments of the present invention provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present invention as defined herein and equivalents thereto. Hence, use of absolute and/or sequential terms, such as, for example, “will,” “will not,” “shall,” “shall not,” “must,” “must not,” “only,” “first,” “initially,” “next,” “subsequently,” “before,” “after,” “lastly,” and “finally,” are not meant to limit the scope of the present invention as the embodiments disclosed herein are merely exemplary.
Accordingly, it is desirable to have a lightweight and easy-to-deploy method of creating secure subnetworks inside an existing general purpose network, such as, for example, an intranet or an Internet, without major reconfiguration of the network. Methods and apparatuses for creating secure subnetworks that allow a selection of a subset of hosts deployed on a network, enable protected communications among the hosts, and prevent eavesdropping and unauthorized accesses are described. The term “host” may refer either to a client computer or to a server computer coupled to a network, which may be computer system 800 shown in
Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
According to one embodiment of the invention, secure network tunnel (SNT) technology creates secure tunnels between peers, also referred to as hosts, connected to unsecured networks. SNT may be based on publicly available technologies such as TLS (transport layer security) and IPSec (Internet protocol security), and/or other proprietary communication authentication schemes. SNT may reside in the TCP/IP (transport control protocol/Internet protocol) stack and allow existing applications to communicate through secure tunnels that may be dynamically established on demand. In one embodiment, no changes in the existing protocols and applications are needed to enable secure communication and no additional security gateway is required, as shown in
Referring to
According to one embodiment, front end servers 701, middleware servers 702, and backend servers 703 are selected to form a subnetwork among a general network, such as an Intranet or an Extranet (e.g., an Internet), which may also include servers 707 to 708. The subnetwork formed by front end servers 701, middleware servers 702, and backend servers 703 is established by connecting these servers through respective secure authenticated tunnels, such as secure tunnels 704. Meanwhile, other connections, such as connections 705 and 706, which connect other unselected servers (e.g., servers 707 and 708) may remain still unsecured and unauthenticated connections, which are subject to attacks externally or internally. In one embodiment, the subnetwork includes the entire general purpose network.
In one embodiment, all data travelling between the servers within the secure subnetwork (e.g., servers 701 to 703) are transmitted via the respective secure and authenticated tunnels. As a result, communications among the servers within the secure subnetwork are protected. Such protected communications prevent eavesdropping and unauthorized accesses.
According to yet another embodiment, each secure connection (e.g., a TCP/IP connection) through the secure tunnel may be authenticated before the connection is established, which will be described in details further below. Data transmitted through the respective secure tunnel connecting the peers may be encrypted according to an encryption algorithm.
According to one embodiment, the secure tunnels may be established by a software program executed within a kernel space of the OS on all selected hosts within the protected subnetwork. As a result, all operations regarding encryption and authentication are transparent to the applications running in a user space. In one embodiment, the software program is embedded in a network driver associated with a network stack, such as the TCP/IP stack of the OS. In a particular embodiment, the software program may be distributed as part of a transport layer of the TCP/IP stack, such that its operations may be transparent to the applications. In addition, since the secure tunnels are implemented through a software program installed at all peers within the subnetwork, no additional hardware (e.g., VPN gateways) and no reconfiguration of the network (e.g., rerouting network traffic through the added VPN gateways) are needed.
According to one embodiment, the SNT are established on demand dynamically. That is, peers establish on-demand secure tunnels when they need to communicate. For example, the original connection between a first peer (e.g., one of the front end servers 701) and a second peer (e.g., one of the middleware servers 702) is an unsecured and unauthenticated connection. When the first peer receives a request for accessing the second peer, the first peer establishes a secure network tunnel with the second peer in response to the request. The secure tunnel may be established statically prior to receiving a request for accessing a host. In one embodiment, the secure tunnels among the peers are established when the peers are in initialization stages (e.g., during booting of the peers). The secure tunnels may be established based on a policy, locally or enterprise wide, governing the connections among the peers. The secure tunnel may be authenticated prior to establishing the connection which is described in details further below. A security policy determines which peers participate in the secure subnetworks and which protocols are tunneled. Any attempt to communicate with a “secured” peer without establishing the protected tunnel may be denied by the software. Technology described herein uses a variety of authentication and encryption techniques and uses enterprise directory services to authenticate participating peers. In one embodiment, the SNT may be governed by an enterprise security policy. Alternatively, the SNT may be governed by a local security policy associated with the host. Furthermore, the enterprise and local security policies may coexist, such that, according to one embodiment, the local security policy may supercede the enterprise security policy.
The SNT may be established using a secure communication protocol, such as SSL or IPSec, etc. The communicating peers involved in the subnetwork may be located on the same network. Alternatively, they may be located on different networks or different networks separated by a firewall. Furthermore, according to one embodiment, the tunneled communications may be performed over a TCP/IP protocol. Alternatively, the tunnel communications may be performed over a UDP, IP, or non-IP protocol.
In one embodiment, an SNT deployment may simplify firewall configuration. With SNT deployed, all traffic between two peers can be tunneled though a single authenticated and encrypted connection and thus the technologies described herein can potentially reduce the number of open ports on a firewall.
When external user 507 logs into a web application 508, user 507 is authenticated 509 against the customer directory service 510 and her request is allowed to proceed to the applications located in middle tier 504 and at enterprise backend server 505.
Referring to
As shown in
During establishment of authenticated secure tunnel 521 or authenticated tunneled connection 522, a connection request carrying a credential 532 reaches server computer 534. SNT network manager module 523 deployed in operating system IP Stack 533 extracts credential 532 and passes it to the SNT authentication and authorization manager (“A2 Manager”) module 524 via an internal programmatic interface.
In one embodiment, a management module such as SNT A2 Manager 524, who wishes to authenticate and authorize a network connection, communicates with enterprise directory 513 via SNT authentication and authorization daemon (“A2 Daemon”) 526 deployed in application space 535 of server computer 534. The communication between SNT A2 Manager 524 and A2 Daemon 526 occurs over an OS level communications mechanism 527 such as, but not limited to, a shared memory segment, memory mapped file, etc. A2 Daemon 526 picks up the request and forwards it to enterprise directory 513 through a dedicated enterprise security system adapter (“ESS Adapter”) 529. ESS Adapter 529 translates the authentication request of A2 Daemon 526 into the format and protocol 530 understood by enterprise directory 513. Examples of the protocols supported by ESS Adapter 529 used to communicate with enterprise directory 513 include, but are not limited to, LDAP (Lightweight Directory Access Protocol), Active Directory from Microsoft Corporation, OS/390 SAF/RACF/ACF2/Top Secret, etc. Other protocols apparent to those with ordinary skills in the art may be utilized.
Further referring to
Depending on enterprise directory 513 responses, A2 Manager 524 makes a decision as to whether to allow establishment of a secure tunnel 521, or to allow a network connection 536 to Application 531, or to deny network communications request 522. A2 Manager 524 may make its decision to allow or to deny the communications request based on a local policy optionally superimposed on a policy provided by enterprise directory 513. For example, enterprise wide system administrator may set up an enterprise policy, which may be included in an enterprise directory service (e.g., enterprise directory 513 of
In the case of a positive enterprise directory 513 response, the A2 Manager optionally adds a record about a newly established network connection 522 to SNT authentication and authorization cache (“A2 Cache”) 525. A2 Manager 524 may support arbitrary authorization models including, but not limited to, RBAC (role based access control) or DAC (discretionary access control). Other models apparent to those of ordinary skill in the art may be utilized.
According to one embodiment, A2 Cache 525 is policy-driven and it allows the retention of temporary authentication and authorization information about established connections. The connection information is stored in the A2 Cache for a limited time or a maximal number of accesses, as determined by a local policy. Once the policy limits are exceeded, the corresponding cache entry is flushed and Enterprise Directory 513 again is accessed to authorize the next peer's communication request 522. Being local to A2 Manager 524, A2 Cache 525 significantly reduces the time required to receive authentication and authorization information without endangering communications security.
SNT technology offers a wide variety of network connection authentication and protection capability. In one embodiment all requests for TCP/IP network connections between the communicating peers are authenticated before connection is permitted, which will be described in details further below.
Connection acceptor 552 communicates with enterprise directory 513 to authenticate connection initiator 551 using her identity and authentication information 556 found in SYN packet 553. If authentication is successful, connection acceptor 552 decrypts connection initiator's 551 challenge. Connection acceptor 552 then transforms it, adds its own challenge and encrypts both values. Connection acceptor 552 then passes authentication payload 557 to connection initiator 551 in TCP/IP SYN/ACK packet 554. Connection initiator 551 decrypts its own transformed challenge value and after making sure that it is correct, transforms and encrypts connection acceptor's 552 challenge value and passes it back to connection acceptor 552 in TCP/IP ACK packet 555. Connection acceptor 552 decrypts and verifies connection initiator's 551 response 558 and hands off the newly established connection to destination application 560. It will be appreciated that pre-connection authentication may be applied to the establishment of tunneled network connections and to the establishment of the secure tunnel, itself.
In an alternative embodiment, referring to
Initiating SNT module 573 and accepting SNT module 574 establish a secure tunnel 521 depending on the security policy set forth at an enterprise directory. Initiating SNT module 573 may optionally superimpose its own non-contradictory local policies such as, but not limited to, allowing only certain accounts on server 571 to establish tunneled connections 522 to server 572.
Secure tunnel 521 can be established by using the SSL/TLS protocol or a variant of it such as WTLS (wireless transport layer security), the IPSec protocol or other communications protocols, which support encrypted communications. Initiating SNT module 573 and accepting SNT module 574 may negotiate a protocol for secure tunnel 521 using the EAP (extensible authentication protocol). Other protocols may be utilized.
During establishment of secure tunnel 521, initiating SNT module 573 and accepting SNT module 574 unidirectionally or mutually authenticate each other via enterprise directory 513. Secure tunnel 521 can be negotiated by the communicating parties without any authentication using, for example, but not limited to, a Diffie-Hellman key agreement method. Secure tunnel 521 can also be established as requiring only message integrity verification and without the privacy property. Application 577 and service 578 can be communicating through secure tunnel 521 using, for example, TCP/IP protocol, UDP protocol, or any other protocols, such as non-IP based network protocols.
According to one embodiment, secure tunnel 521 may be established dynamically on demand. For example, when SNT module 573 receives a request from application 577 to access service 578 located on server 572, SNT module 573 may check whether secure tunnel 521 has been previously established. If SNT 521 has not been established, SNT module 573 may try to establish an SNT with SNT module 574 of server 572. In one embodiment, SNT modules 573 and 574 may mutually authenticate with each other prior to establishing the connection. In addition, SNT modules 573 and 574 may inspect the request originating from application 577 to determine whether such request should be entitled for service 578 via enterprise directory 513. Once SNT tunnel 521 has been established, SNT module 573 may encrypt data received from application 577 and transmit the data to server 572 via SNT 521. It is appreciated that all operations performed by SNT module 573 are performed in a kernel space of the OS executed within server 571, such that the operations are transparent to application 577. In one embodiment, application 577 may be a security-unaware application (e.g., a legacy application). However, the data exchanged between servers 571 and 572 are transmitted via SNT tunnel 521 which are not feasible to attack by an intruder.
According to one embodiment, when SNT module 574 receives an encrypted data from SNT module 573, SNT module 574 may inspect the encrypted data to determine whether such data has been transmitted from a trusted peer via a secure tunnel. The inspection may be performed against enterprise directory 513 services. Note that server 572, which has an SNT with server 571, may also have other connections (e.g., unsecured connections) with other hosts (e.g., non-members of the subnetwork). Once SNT module 574 determines that the data is received from SNT module 573, it decrypts the encrypted data according to an agreed upon encryption/decryption algorithm which may be stored in enterprise directory 513. Thereafter, SNT module 574 transmits the decrypted data to the designated application 578, which may be a security unaware application. It is appreciated that all operations performed by SNT module 574 are performed in a kernel space of the OS executed within server 572, such that the operations are transparent to application 578.
Note that SNT modules 573 and 574 are software programs, which may be installed on all hosts constituting the secure subnetwork within a general purpose network, such as an Intranet. The software package including SNT modules 573 and 574 may be distributed and installed by an enterprise wide system administrator. The software package may be installed in addition to an existing network stack of an operating system. That is, when the software package is installed, it “hooks” on the network stack, such as TCP/IP stack, such that the SNT modules may intercept the network traffic (e.g., outgoing and incoming traffics) within the network stack. Then the SNT modules may perform any necessary operations including, but not limited to, authenticating the request against a directory service, establishing an SNT tunnel with a destination host if it has not been established, encrypting outgoing packets, and decrypting incoming packets, etc. In one embodiment, such operations are completely transparent to the respective applications and do not require any changes at the application level. In one embodiment, the software package may be uninstalled and the original network stack may be restored without the knowledge of the respective applications. Other configurations may be utilized.
In order to selectively prevent the establishment of unauthorized TCP/IP connections, novel measures are taken.
Octets following auth method ID 206 contain authentication data, auth data 207. In one embodiment, auth data 207 length is limited to approximately 23 octets due to the size limitation of the TCP header.
In another embodiment, as illustrated on
When OPTION_B 303 is used, authentication information is placed in the data portion of SYN packet 553. Authentication information begins with a single octet auth info length 209 containing total length of the peer ID 210, auth method ID 211 and auth data 207 fields. This octet is followed immediately by eight octets containing peer ID 210 for the client computer at the site of server computer. The following octet, auth method ID 211, contains a unique identifier of the authentication method used to authenticate the client computer by the server computer. Octets following auth method ID 211 contain authentication data in auth data 207. In one embodiment, auth data 207 length is limited to approximately 128 octets due to the data size limitation of the TCP/IP packet.
Sending a SYN packet to a TCP/IP server is not the only method to discover a network service. Activity in which a party tries to locate services available on a network is called “scanning”. Typically, scanning is performed by sending SYN packets to the ports of the hosts deployed on the network. This type of scanning is called “SYN-scan”.
In addition to SYN-scan, a sophisticated attacker can utilize FIN, ACK or NULL scans. These scans send an unsolicited packet with the respective TCP flag set, as denoted by the name of the scan. Packets sent during these scans are not a part of any valid established TCP connection. The TCP/IP protocol requires the host that receives one of those packets to generate a response, an RST packet, if the TCP port was closed, and to ignore the packet if the TCP port was open. This behavior, prescribed by the TCP/IP protocol standard, allows the attacker to determine which TCP ports are open on a target Host.
In order to prevent open TCP port detection by FIN, ACK or NULL scans, in one embodiment, the server computer tracks all established TCP connections. The host computer generates an RST Packet in response to any packet sent to an open TCP port that does not belong to a valid TCP connection. Providing the same response to packets sent to an open TCP port and to a closed TCP port denies an attacker any useful information.
Before attempting the establishment of an authenticated TCP/IP connection, the client computer and the server computer agree on the type of authentication method that they will use for authentication purposes. Various embodiments include, but are not limited to, the following authentication methods:
Each of these authentication methods includes a variation that introduces additional authentication steps designed to prevent the “man-in-the-middle” (MITM) attacks against the protected server computer.
As illustrated in
As a consequence of such action by adversary 213, upon receiving the amended SYN* packet 217, server computer 101 verifies authentication data in the amended SYN* packet 217 if that authentication data did not include a cryptographically protected reference to the IP address of client computer 100. Given the fact that in a large number of deployments, the source IP address cannot be verified due to the widespread use of Network Address Translation (NAT) technology by network perimeter devices, an MITM (man in the middle) attack could be successfully staged by adversary 213.
A successful MITM attack against server computer 101 forces it to send a response SYN*/ACK packet 218 to adversary 213 instead of to client computer 100. As a result, server computer's TCP/IP session is diverted to adversary 213.
Special variations of the authentication methods include provision for a challenge response exchange between client computer 100 and server computer 101 to further verify the source of the nascent TCP/IP session prior to the establishment of any connection. As illustrated in
In another embodiment, as illustrated on
Encrypted challenge information begins with a single octet, challenge info length 227, containing the length of the following encrypted challenge information. Octets following challenge info length 227 contain encrypted challenge data 224. In one embodiment, challenge data length is limited to approximately 128 octets due to the size limitation of the TCP/IP packet data size.
In another embodiment, as illustrated on
Encrypted response information begins with a single octet, response info length 234, containing the length of the following encrypted response information. Octets following response info length 234 contain encrypted response data 231. In one embodiment, challenge data length is limited to approximately 128 octets due to the size limitation of the TCP/IP packet data size.
When hosts use a secret key-based authentication method, server computer 101 generates an 8 octet long random value, Salt, concatenates it with a shared secret key value, Secret, and with the sequence number field, Seq#, from the TCP header in SYN packet 200 sent by client computer 100. Server computer 101 applies a secure hash cryptographic algorithm (e.g., MD5, SHA-1, etc.) to the resulting octet sequence, thus generating a challenge value, Ch:
Ch=H(Salt|Secret|Seq#)
Then server computer 101 concatenates the Salt value and the challenge value, Salt|Ch, and places the result in encrypted challenge data 224 field of SYN/ACK packet 201.
Upon receiving the challenge, client computer 100 verifies that the challenge value, Ch, was indeed sent by server computer 101 by locally recalculating that value. In order to create a response, client computer 100 concatenates the received challenge value, Ch, with the shared secret value, Secret, and computes a secure cryptographic hash of the result, e.g. MD5 or SHA-1:
H(Ch|Secret)
Client computer 100 places the computed response value in encrypted response data 231 field of the ACK packet 202. Upon receiving ACK packet 202, server computer 101 verifies the response value computed by the client computer 100.
Server computer 101 selects a secure cryptographic hash algorithm according to its local policy. Client computer 100 determines the type of secure cryptographic hash algorithm used by server computer 101 from the value found in the option length 204 field if OPTION_A 301 layout is used (e.g., 16 octets for MD5, 20 octets for SHA-1). If OPTION_B 303 layout is used, then client computer 100 determines the secure cryptographic hash algorithm used by server computer 101 from the value found in the challenge info length 227 field (e.g., 16 octets for MD5, 20 octets for SHA-1). To calculate the response value, client computer 100 must use the same secure cryptographic hash algorithm as is used by server computer 101 when it calculates the challenge value.
When hosts employ public key cryptography-based authentication methods, server computer 101 generates a 12 octet-long random value, Rand, concatenates it with the sequence number field, Seq#, from TCP header 113 in the SYN packet 200 sent by client computer 100, Ch=Rand|Seq#, and encrypts it with server computer 101 private key, Pr vS:
E
Prv
(Ch)
Server computer 101 places the result in encrypted challenge data 224 of SYN/ACK packet 201.
Upon receiving the challenge, client computer 100 decrypts the challenge value using server computer 101 public key, PubS:
Ch=D
Pub
(EPrv
Client computer 100 verifies that the challenge, Ch, was indeed computed by server computer 101 by comparing the value of the Seq# with the sequence number value found in sequence number field as sent by client computer 100 to server computer 101 in SYN packet 200.
After verifying the origin of the challenge value, client computer 100 encrypts the received challenge value, Ch, with client computer 100 private key, Pr vC:
E
Prv
(Ch)
Client computer 100 places the computed response value in encrypted response data 231 field of ACK packet 202.
Upon receiving ACK packet 202, server computer 101 decrypts the value in encrypted response data 231 field of ACK packet 202 using client computer 100 public key, PubC:
Ch=D
Pub
(EPrv
Server computer 101 verifies client computer 100 response by comparing the decrypted Rand value with the random value which it sent to client computer 100 in SYN/ACK packet 201.
As described above, SYN packet 200 contains cryptographically secured data that authenticates client computer 100 to server computer 101. Following are descriptions of various embodiments that are meant to be illustrative, which do not exclude other embodiments of this invention.
Hashed Message Authentication Code (HMAC) is an authentication method that may be used to authenticate client computer 100 to server computer 101. HMAC of SYN packet 200 is computed by concatenating the shared secret key, Secret, with values found in the following fields: source IP address, SrcIPAddr, destination IP address, DestIPAddr, source port number, SrcIPort#, Destination Port Number, DestPort#. In one embodiment, the HMAC computation is performed according to the guidelines found in the IETF RFC 2104 “HMAC: Keyed Hashing For Message Authentication” document (“RFC2104”):
HMAC(SrcIPAddr|DestIPAddr|SrcIPPort|DestIPPort|Secret)
Server computer 101 verifies the HMAC using data in SYN packet 200 sent by client computer 100.
In another preferred embodiment, a different authentication method may be used to authenticate client computer 100 to server computer 101, which is based on a timestamp provided by a trusted third party such as a NTP (Network Time Protocol) server. Client computer 100 concatenates a decimal ASCII value of the NTP timestamp, TC, with the shared secret key, Secret, and, in one embodiment, computes a cryptographic hash value according to the guidelines found in the RFC2104:
H=HMAC(TC|Secret)
Client computer 100 concatenates the timestamp, TC, with the HMAC value, H, TC|H, and sends it to server computer 101.
Upon receiving SYN packet 200 from client computer 100, server computer 101 verifies the HMAC value and, if successful, obtains a NTP timestamp, TS, from a trusted server. Server computer 101 compares the trusted timestamp value, TS, with the timestamp value received from client computer 100, TC, and if the value of the timestamp value received from client computer 100, TC, is within the window allowed by server computer 101 policy, Δ, |TC−TS|≦Δ, server 101 computer accepts the communications session.
In yet another preferred embodiment, the authentication method used to authenticate client computer 100 to server computer 101 is based on one-time password technology. Prior to establishing the first authenticated TCP/IP session, client computer 100 and server computer 101 agree on a pair of publicly known non-zero values, Salt0, and TrfCount0 (where TrfCount0<256). Client computer 100 and server computer 101 also use another publicly known value, SeqCnt, which initially is set to zero.
In order to compute the next one-time password value, both client computer 100 and server computer 101 concatenate the Salt0 value and the shared secret key, Secret, and computes its HMAC TrfCount0 times:
OTP0=HMACTrfCount
To calculate the next one-time password value, OTP1, both client computer 100 and server computer 101 subtract one from the TrfCount0 value. If TrfCount0−1=0, the host (client computer 100 or server computer 101) calculates Salt1 value as:
Salt1=HMAC(Salt0|Secret)
The host also computes the next maximal transformation counter value, TrfCount1, as:
TrfCount1=HMAC(Salt1|Secret)mod 256
If TrfCount1=0, the HMAC is calculated again:
TrfCount1=HMAC(HMAC(Salt1|Secret))mod 256
This calculation continues until a non-zero value for TrfCount1 is obtained. Once a new value of the maximal transformation counter is computed, the host (client computer 100 or server computer 101) increments the SeqCnt value by one.
In order to thwart replay attacks, the host (client computer 100 or server computer 101) which verifies a one-time password value ensures that the sequence counter value, SeqCntC, submitted by the claimant is greater or equal to the locally known sequence counter value, SeqCntV, and that the transformation counter value, TrfCountC, submitted by the claimant is less or equal than the locally known transformation counter value, TrfCountV:
SeqCntC≧SeqCntV and TrfCountC≦TrfCountV
In still another embodiment, the authentication method used to authenticate client computer 100 to server computer 101 is based on public key cryptographic methods. In one embodiment, client computer 100 encrypts the sequence number field, Seq#, from the TCP header in SYN packet 200 which it is preparing for transmission to server computer 101, with client computer 100 private key, Pr vC:
E
Prv
(Seq#)
Upon receiving SYN packet 200 from client computer 100, server computer 101 decrypts the Seq# value using client computer 100 public key, PubC:
Seq#=DPub
Server computer 101 verifies that the sequence number, Seq#, contained in auth data 207 field is the same as the sequence number value found in the sequence number field of SYN packet 200 sent by client computer 100 to server computer 101.
When client computer 100 wishes to establish a new TCP/IP communications session with server computer 101, it sends to security assertion provider 401 a credential request 402 to ask for the issuance of an authentication credential. Security assertion provider 401 issues client computer 100 an authentication credential such as, without limitation, an authentication token, a digital certificate or a Kerberos ticket. Security assertion provider 401 forwards this issued credential 403 to client computer 100.
Upon receiving credential 403 from security assertion provider 401, client computer 100 embeds the credential 403 in SYN packet 200 and sends this packet to server computer 101.
When server computer 101 receives SYN packet 200, it extracts credential 403. Depending on the type of credential 403, server computer 101 verifies it, without limitation, locally, with security assertion provider 401 or any other trustworthy entity capable of verifying credential 403.
Password-based authentication may be used in one embodiment as the authentication method used to authenticate client computer 100 to server computer 101. Client computer 100 incorporates a password in SYN packet 200.
Upon receiving SYN packet 200 sent by client computer 100, server computer 101 compares the received password value with a locally stored value and accepts the connection if password values match.
In this embodiment, an authenticated packet 420, P1, sent by client computer 100, is authenticated for acceptance by the next relay device 421. After authenticating the packet relay device 421 modifies or replaces authentication information in the packet with its own authentication information and forwards this modified authentication packet, P2, to the next relay device 422, etc. Finally, authenticated packet 420, Pn, (a packet whose authentification information has been modified n−1 times before the packet reaches server computer 101) reaches server computer 101.
Upon receiving and verifying authentication information in authenticated packet 420, Pn, server computer 101 transmits the acceptance packet through the same or an alternative chain of relay devices 421-422.
Client computer 100 and/or server computer 101 may be any kind of computer, wireless devices, personal digital assistants (PDAs), laptop computers, phones or other communication devices or combinations thereof.
Furthermore, in one embodiment, client computer 100 is authenticated against a database of hosts stored in a computer readable memory. In such a case, peers being authenticated may have been registered before connection establishment was attempted. This memory may be part of server computer 101 or accessible thereby. In one embodiment, the authentication technique described herein is integrated with enterprise security systems, such as, for example, RADIUS (Remote Authentication Dial-In User Service), Windows Domain, etc., to determine valid peers.
In one embodiment, such a process in which authentication of registered peers may be performed includes accessing a memory storing a list of one or more valid peers, comparing the prospective peer with the list of one or more potentially valid peers and the data used to authenticate them to determine if the prospective peer is in the list, and authenticating the prospective peer if determined to be on the list. The data used to identify the peer is in the SYN packet. After a particular peer is determined to be valid, a server, such as server 101 described above, may use other information, such as, for example, the encrypted information or other forms of information described above in the SYN packet, to determine whether the prospective peer is who they say they are.
As shown in
In conclusion, the present invention provides for low cost and highly efficient security safeguards for standard TCP/IP Servers deployed on private and public IP networks. A method for creating secure subnetworks on a general purpose network disclosed in this invention is based on the SNT technology. SNT is a combination of traditional security methods and an innovative standards-based approach to authenticating and protecting network traffic. SNT provides a wide variety of security options for establishing a secure data pipeline between servers, with the capability of authenticating each connection tunneled within this pipeline. SNT provides an authentication capability to back-end systems, which are otherwise incapable of authenticating themselves, to enable them to communicate with servers and other peers in a secure fashion.
SNT is a software solution and its deployment does not require installing any additional hardware. Since SNT is deployed in the IP stack, applications are unaware of its presence and keep running “as-is” without any changes. Due to SNT's point-to-point nature and its use of well-known technologies, there is no requirement for reconfiguring the network or for opening additional ports on interdepartmental firewalls. SNT may reduce the number of open firewall ports, because multiple application level protocols can be tunneled through a single secure pipe. With SNT, TCP/IP servers remain cloaked to all except authorized parties. Unauthorized parties cannot even identify open ports on the servers, and therefore cannot gain access.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.
This application is a continuation of and claims priority to U.S. patent application Ser. No. 11/729,202, of the same title, filed Mar. 27, 2007, currently pending, which is a divisional of U.S. patent application Ser. No. 10/358,926, filed Feb. 4, 2003, which is abandoned, which is a continuation-in-part (CIP) of U.S. patent application Ser. No. 10/224,098, entitled “Establishing Authenticated Network Connections”, filed Aug. 19, 2002, now U.S. Pat. No. 7,069,438 issued Jun. 27, 2006, which applications/patents are fully incorporated in their entirety by this reference.
Number | Date | Country | |
---|---|---|---|
Parent | 10358926 | Feb 2003 | US |
Child | 11729202 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11729202 | Mar 2007 | US |
Child | 14852473 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10224098 | Aug 2002 | US |
Child | 10358926 | US |