Method for establishing trust in a computer network via association

Abstract

A method is disclosed for establishing trusted communications with associations for communications between users on an Internet Protocol based computer network. The method entails the first user's SNIU determining the Internet Protocol (IP) address of a second user's SNIU on the computer network through the use of custom and ICMP Echo Request and Reply messages. The user's SNIUs exchange security related information needed to complete the establishment of a trusted association. The trusted association is maintained during all communications between the first user and the second user.

Claims

What is claimed is:

1. A method for establishing a trusted communications session between a first user and a second user each being associated with a respective secured network interface unit ("SNIU") in a computer network, said method comprising the steps of:

determining by a first SNIU whether a second SNIU exists;

discovering by the second SNIU security parameters associated with the first SNIU for making decisions regarding transmission of information between said first and second users;

discovering by the first SNIU security parameters associated with the second SNIU for making decisions regarding transmission of information between said first and second users; and,

maintaining the security parameters of the first SNIU and the second SNIU during at least one communication between the first user and the second user.

2. The method in accordance with claim 1, wherein the computer network is an Internet protocol (IP) based network.

3. The method of claim 2, wherein said step of determining the existence of the second user includes using an ICMP Echo Reply message.

4. The method according to claim 2, wherein determining the existence of a SNIU on the computer network includes using an address resolution protocol.

5. The method according to claim 2, wherein the second user response to receiving the Internet Control Message Protocol Echo Request returns an Internet Control Message Protocol Echo Reply.

6. The method according to claim 1, wherein trust associated with said trusted communications session is established between the first SNIU and second SNIU at a session layer in a communications stack.

7. The method according to claim 1, further including at least one intermediate SNIU located in between the first SNIU and the second SNIU.

8. The method according to claim 7, wherein a custom Association Request Message carries the first SNIU's security parameter including the users security level and the associated SNIU's certificate.

9. The method according to claim 8, wherein each said at least one intermediate SNIU which receives the custom Association Request Message, authenticates the message, saves a copy of the message, appends an associated certificate to the message, and digitally signs the message before sending it on to the second SNIU.

10. The method according to claim 9, further comprising the step of each said at least one intermediate SNIU generating an ICMP Echo Request message and sending it to the second user.

11. A method for sharing a user's security information with another user over an Internet Protocol (IP) base computer network, said method comprising the steps of:

determining, by a first user's security device, an accessibility of a second user on the computer network;

exchanging, between the first user's security device and a security device associated with the second user, security related information needed to complete the establishment of a trusted association; and,

maintaining the trusted association during at least one communication between the first user and the second user.

12. The method according to claim 11, wherein the step of determining the accessibility of the second user includes utilizing an Internet Control message Protocol (ICMP) Echo request.

13. The method according to claim 12, wherein the second user in response to receiving an Internet Control Message Protocol Echo Request returns an Internet Control Message Protocol Echo Reply.

14. The method according to claim 13, wherein a security device, upon receiving the ICMP Echo reply, determines if transmitting information would violate a security policy.

15. The method according to claim 14, wherein when no security policy would be violated, security device generates a symmetric encryption key to protect the communication between the first use and the second user and encrypts the key for secure transmission to a security device associated with said first user.

16. The method according to claim 11, wherein the step of exchanging security related information to establish trust occurs at the session layer in the communication stack.

17. The method according to claim 11, wherein an Association Request Message carries the first user's security device security parameter including a user's security level and a security device certificate.

18. The method according to claim 17, wherein at least one intermediate security device, in the communications path between the first user's security device and the second user's security device, which receives the Association Request Message, authenticates the Association Request message, saves a copy of the Association Request message, appends an associated certificate to the Association Request Message, and digitally signs the Association Request message before sending it on to the second user's security device.

19. The method according to claim 18, further comprising the step of each intermediate security device generating an ICMP Request message and sending it to the second user address.

20. The method according to claim 11, wherein said step of determining the accessability of the second user's security device includes using an address resolution protocol.

Description

FIELD OF THE INVENTION

The present invention relates in general to computer networks and in particular to establishing trust between secured users in a computer network environment.

BACKGROUND OF THE INVENTION

Multi-level secure (MLS) networks provide a means of transmitting data of different classification levels (i.e. Unclassified, Confidential, Secret and Top Secret) over the same physical network. To be secure, the network must provide the following security functions: data integrity protection, separation of data types, access control, authentication and user identification and accountability.

Data integrity protection ensures that data sent to a terminal is not modified enroute. Header information and security level are also protected against uninvited modification. Data integrity protection can be performed by checksum routines or through transformation of data, which includes private key encryption and public key encryption.

Separation of data types controls the ability of a user to send or receive certain types of data. Data types can include voice, video, E-Mail, etc. For instance, a host might not be able to handle video data, and, therefore, the separation function would prevent the host from receiving video data.

Access control restricts communication to and from a host. In rule based access control, access is determined by the system assigned security attributes. For instance, only a user having Secret or Top Secret security clearance might be allowed access to classified information. In identity based access control, access is determined by user-defined attributes. For instance, access may be denied if the user is not identified as an authorized participant on a particular project. For control of network assets, a user may be denied access to certain elements of the network. For instance, a user might be denied access to a modem, or to a data link, or to communication on a path from one address to another address.

Identification of a user can be accomplished by a unique name, password, retina scan, smart card or even a key for the host. Accountability ensures that a specific user is accountable for particular actions. Once a user establishes a network connection, it may be desirable that the user's activities be audited such that a "trail" is created. If the user's actions do not conform to a set of norms, the connection may be terminated.

Currently, there are three general approaches to providing security for a network: trusted networks, trusted hosts with trusted protocols, and encryption devices. The trusted network provides security by placing security measures within the configuration of the network. In general, the trusted network requires that existing protocols and, in some cases, physical elements be replaced with secure systems. In the Boeing MLS LAN, for instance, the backbone cabling is replaced by optical fiber and all access to the backbone is mediated by security devices. In the Verdix VSLAN, similar security devices are used to interface to the network, and the network uses encryption instead of fiber optics to protect the security of information transmitted between devices. VSLAN is limited to users on a local area network (LAN) as is the Boeing MLS LAN.

Trusted hosts are host computers that provide security for a network by reviewing and controlling the transmission of all data on the network. For example, the U.S. National Security Agency (NSA) has initiated a program called Secure Data Network System (SDNS) which seeks to implement a secure protocol for trusted hosts. In order to implement this approach, the installed base of existing host computers must be upgraded to run the secure protocol. Such systems operate at the Network or Transport Layers (Layers 3 or 4) of the Open Systems Interconnection (OSI) model.

Encryption devices are used in a network environment to protect the confidentiality of information. They may also be used for separation of data types or classification levels. Packet encryptors or end-to-end encryption (EEE) devices, for instance, utilize different keys and labels in protocol headers to assure the protection of data. However, these protocols lack user accountability since they do not identify which user of the host is using the network, nor are they capable of preventing certain users from accessing the network. EEE devices typically operate at the Network Layer (Layer 3) of the OSI model. There is a government effort to develop cryptographic protocols which operate at other protocol layers.

An area of growing concern in network security is the use of computer devices in non-secure networks. Such computer devices often include valuable information, which may be lost or stolen due to these computers being accessed through the non-secured network. In light of this problem, a number of related products have been developed. The products developed include Raptor Eagle, Raptor Remote, Entrust, Secret Agent and Veil. Although, these products serve the same purpose, a number of different approaches have been utilized. For example, Raptor Eagle, Raptor Remote, and Veil implement these products as software instantiations. While Entrust and Secret Agent utilize hardware cryptographic components. Additionally, Raptor products are also application independent.

A problem with the above described products is that none are based upon the use of highly trusted software. Veil is an off-line encryption utility, which cannot prevent the inadvertent release of un-encrypted information. While Raptor Eagle and Raptor Remote are based on software instantiations and thus cannot be verified at the same level of assurance. Secret Agent and Entrust while hardware based are dependent upon the development of integration software for specific applications.

Existing security devices require extensive management support or message overhead to establish trust between secured users in a network environment. The extensive management means that, in effect each secure network interface requires knowledge of all other secure network interfaces. This creates either a tremendous planning burden so that the data can be pre-positioned or a significant communications overhead to secure availability and consistency of the network configuration data.

Any scheme using symmetric encryption that requires pre-planning of a network topology also requires key extensive management support. In a tactical environment, the topology changes and one piece of equipment replaces another. Pre-planning becomes expensive and ineffective.

The alternative to pre-planning is message overhead. The message overhead can involve the introduction of messaging protocols as well as demands on bandwidth. Adding protocols decreases the deployability of the system by increasing the risk that the new protocols will be inconsistent with legacy systems.

Accordingly, an object of the present invention is to provide a security method capable of discovering needed trusted information over a computer network when that information is needed.

SUMMARY OF THE INVENTION

The present invention provides a method for establishing trust between secured users in a computer network. Dragonfly Secure Network Interface Units (SNIUs) use a combination of custom messages and standard ICMP Echo Request and Echo Reply messages to discover other Dragonfly SNIUs between two users on a network and establish a trusted communications path. The SNIUs in the communications path authenticate each other and exchange security parameters. Each SNIU is initialized with its own security parameters, but has no pre-positioned information concerning any other units or network topology. Once the path and an association between two SNIUs has been established, user datagrams are encapsulated in custom Dragonfly messages called Protected User Datagrams for secure transmission between two SNIUs. This collection of messages to establish and utilize associations is referred to as the Dragonfly Trusted Session Protocol (TSP).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood with reference to the following illustrative and non-limiting drawings, in which:

FIG. 1 is a schematic diagram of an MLS network system in accordance with the present invention;

FIG. 2 is a block diagram of the software SNIU installed in a computer host in accordance with the present invention;

FIG. 3 is a data flow diagram for the software SNIU in accordance with the present invention;

FIG. 4 is a chart of the process for establishing trust between secured users through associations in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is directed to a secure network interface unit (SNIU), which is utilized to control communications between a user such as a computer host and a network at a "session layer" of interconnection which occurs when a user on the network is identified and a communication session is to commence. For example, the industry-standard Open Systems Interconnection (OSI) model, defines seven layers of a network connection: (1) physical; (2) data link; (3) network; (4) transport; (5) session; (6) presentation; and (7) application. In the present invention, the network security measures are implemented at the network, transport, and session layers (i.e., layers 3-5 of the OSI model). The SNIU intercepts Internet Protocol (IP) datagrams at the network layer as they are transmitted between the user and the network. The SNIU determines whether each datagram from the user is releasable to the network and if and how it should be encrypted. The SNIU decrypts each datagram from the network and determines whether it is releasable to the user. The method for limited secure write downs is implemented at the transport layer. When a SNIU releases a datagram from a lower classification user or network to a higher classification user or network (i.e. a write up), the datagram is used to predict the expected response. When a datagram is received from the higher classification user or network, the SNIU compares the datagram to the response which was predicted during the write up and, if they match, releases it (i.e., allows the write down) to the lower classification user or network. The SNIU implements a custom Trusted Session Protocol (TSP) to establish associations (described later) at the session layer prior to permitting any communication between a user and a network. The TSP authenticates users, exchanges security parameters between SNIUs, and establishes encryption keys for an association. This method of providing security allows existing network assets and existing network protocols to continue to be used, thereby avoiding the need to replace an installed network base for implementation of the multi-level security system. The connected host or user equipment and the network backbone are therefore not required to be secure (trusted). Conventionally, OSI network applications employ CCITT X.215 which is a non-secure session layer protocol. None of the prior multi-level security systems employ the security measures described herein in the Session Layer.

The SNIU according to the present invention can be configured in a number of different embodiments depending on the particular physical locations and forms of implementation. These embodiments include a stand alone hardware SNIU and a software SNIU.

The hardware embodiment of the SNIU is implemented solely as a stand alone hardware device. Such a configuration is desirable, since the stand alone SNIU is highly trusted. The stand alone SNIU is configured to be inserted between existing hosts and a network. The SNIU is transparent to the host, and any legacy system or application software running on the host. The stand alone SNIU provides protection. for any host connected to an IP based network. There is no requirement that the attached host computers run a trusted operating system. The stand alone SNIU provides a trusted boundary between the protected hosts and the unprotected network. Protected means that the connection is with another known SNIU (a unique digital signature identifies the SNIU), the messages are confidential (encrypted) and unaltered (encrypted checksums validate the packet).

The software embodiment of the SNIU is implemented primarily as a software function resident in and executed from the host machine. The only hardware required is a commercially available cryptographic card (e.g., a Fortezza card) which plugs into the host computer's PCMCIA card reader. Such a configuration is desirable, since the software SNIU is designed to be installed in existing portable computers, which avoids the additional cost of additional hardware required by a stand alone hardware SNIU. The software SNIU provides the same network security features as the stand alone SNIU when the host computer is connected to home enterprise's network. The software SNIU also extends that same level of security across the Internet (or any other unprotected network) when the user is on the road and is remotely communicating with the enterprise network or other remotely located computer devices including a similar software SNIU.

The software SNTU provides all of the functionality and security of the stand alone SNIU as well as complete operability with these devices. The software comprising the software SNIU is based on the same software utilized in the stand alone hardware SNIU. The user of the software SNIU assumes an acceptable risk in exchange for not requiring additional hardware required by a stand alone SNIU, which cannot be circumvented or corrupted via attacks originating from external hardware. By providing reasonable physical protection (not allowing unauthorized personnel physical access) and software protection (anti-virus protection), a software SNIU can be utilized providing the user with an acceptable level of risk. If the user is confident that the software comprising the software SNIU is not circumvented or modified, then he can enjoy the same degree of confidence as the user of a stand alone device.

Referring to FIG. 1, there is shown an example of a Multi-Level Security (MLS) System in accordance with the present invention. This system incorporates the various embodiments of the SNIUs in order to provide MLS for computer networks such as the Internet. For example, the Guard devices 14,16 which are hardware embodiments of the SNIU are coupled between computer networks 34,36,38 providing inter-network security. Additional Guard devices 12,18 are coupled between users such as computer hosts 28 and 30, and the respective networks 34 and 38. The software embodiment of the SNIUs are implemented as a Companion within computer hosts 24,26, to provide network security without requiring additional hardware. The auditors 20,22 are also hardware SNIUs which are configured to communicate directly with the other SNIUs to log audit events and potentially signal alarms. The above described system enables secured and non-secured users such as a web site 40 to communicate with each other without the danger of compromising security.

During operation, the SNIUs included in the above described system communicate with each other thereby creating a global security perimeter for end-to-end communications and wherein the network may be individually secure or non-secure without compromising security of communications within the global security perimeter.

Security System Policies

The SNIU devices in accordance with the present invention may implement a number of security policies suitable to the circumstances of a given network environment. The major policy areas are: discretionary access control; mandatory access control; object reuse; labeling; identification and authentication; audit; denial of service detection; data type integrity; cascading control; and covert channel use detection.

Discretionary access control is a means of restricting access to objects (data files) based on the identity (and need to know) of the user, process, and/or group to which the user belongs. It may be used to control access to user interface ports based on the identity of the user. For a single-user computer unit, this mechanism may be implemented in the SNfU, whereas for a multi-user host, the DAC control may be implemented at the host machine. Discretionary access control may also be implemented as discretionary dialog addressing, wherein the addressing of all communications originated by a user is defined, and for user discretionary access denial, wherein a user may refuse to accept a communication from another user.

Mandatory access control is a means of restricting access to objects based on the sensitivity (as represented by a classification label) of the information contained in the objects, and the formal authorization (i.e., clearance) of the user to access information of such sensitivity. For example, it may be implemented as dialog lattice-based access control, wherein access requires a correct classification level, integrity level, and compartment authorization, dialog data-type access control, wherein correct data type authorization is required for access, and cascade protection, wherein controls are provided to prevent unauthorized access by cascading user access levels in the network.

Object reuse is the reassignment and reuse of a storage medium (e.g., page frame, disk sector, magnetic tape) that once contained one or more objects to be secured from unauthorized access. To be secured, reused, and assigned to a new subject, storage media must contain no residual data from the object previously contained in the media. Object reuse protection may be implemented by port reuse protection, session reuse protection, dialog reuse protection, and/or association reuse protection.

Labeling requires that each object within the network be labeled as to its current level of operation, classification, or accreditation range. Labeling may be provided in the following ways: user session security labeling, wherein each user session is labeled as to the classification of the information being passed over it; dialog labeling, wherein each dialog is labeled as to the classification and type of the information being passed over it; and host accreditation range, wherein each host with access to the secured network is given an accreditation range, and information passing to or from the host must be labeled within the accreditation range.

Identification is a process that enables recognition of an entity by the system, generally by the use of unique user names. Authentication is a process of verifying the identity of a user, device, or other entity in the network. These processes may be implemented in the following ways: user identification; user authentication; dialog source authentication, wherein the source of all communication paths is authenticated at the receiving SNIU before communication is allowed; SNIU source authentication, wherein the source SNIU is authenticated before data is accepted for delivery; and administrator authentication, wherein an administrator is authenticated before being allowed access to the Security Manager functions.

An audit trail provides a chronological record of system activities that is sufficient to enable the review of an operation, a procedure, or an event. An audit trail may be implemented via a user session audit, a dialog audit, an association audit, an administrator audit, and/or a variance detection, wherein audit trails are analyzed for variance from normal procedures.

Denial of service is defined as any action or series of actions that prevent any part of a system from functioning in accordance with its intended purpose. This includes any action that causes unauthorized destruction, modification, or delay of service. The detection of a denial of service may be implemented for the following condition: user session automatic termination, such as when unauthorized access has been attempted; user machine denial of service detection, such as detection of a lack of activity on a user machine; dialog denial of service detection; association denial of service detection, such as detection of a lack of activity between SNIUs; and/or data corruption detection, such as when an incorrect acceptance level is exceeded.

Covert channel use is a communications channel that allows two cooperating processes to transfer information in a manner that violates the system's security policies. Detection of covert channel use may be implemented, for example, by delay of service detection, such as monitoring for unusual delays in message reception, or dialog sequence error detection, such as monitoring for message block sequence errors.

Details Of the Software SNIU

Referring to FIG. 2, a block diagram of the software SNIU installed in a computer host is shown. The software SNIU 44 is implemented as a software function within a host computer 42. The SNIU 44 interfaces with the communications stack of the host computer 58 in order to send and receive messages over the Ethernet or token ring cable 74. The communications stack 58 is a typical OSI model including a physical 72, data link layer 70, network layer 68, transport layer 66, session layer 64, presentation layer 62 and application layer 60. The network layer 68 includes an ARP/RARP module which is utilized to process Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP). As can be seen from FIG. 2, the SNIU 44 is installed between the network and data link layers of the communications stack 68,70, which enables it to be transparent to the other high order software.

The main modules of the SNIU include a Host/Network Interface 46, Session Manager 48, Scheduler and Message Parser 50, Audit Manager 52, Association Manager 54 and Fortezza API 56. The primary data structures included in the SNIU are the Association Table, Sym_Key Table, Certificate Table, Waiting Queue and Schedule Table. These data structures are described later in the description of the protocol.

The Host/Network Interface 46 provides the interfacing between the SNIU 44 and communications stack 58. The Fortezza API 56 is a driver for the card reader 8 included in the host computer 42. The card reader 8 is adapted to receive a Fortezza card which is a PCMCIA card configured to perform integrity and authenticating functions. The Fortezza card performs the integrity function by encrypting messages leaving the SNIU 44 and decrypting incoming messages. The authentication function is accomplished by the Fortezza card generating and reading digital signatures which are unique to each SNIU . The Fortezza card includes a private key to generate the digital signature and a public key to read the signatures. The other SNIU modules will be described in conjunction with the data flow diagram of FIG. 3.

Referring to FIG. 3, there is shown a data flow diagram for the software SNIU. When the host computer communicates with another computer over a network, the communications protocol stack within the computer processes the data to be transmitted. If a user on the computer is transmitting a file to another computer, the user may select the file to send by interacting with application layers software. The display which the user sees is controlled by presentation layer software. Session layer software checks the users permission codes to determine if the user has access to the file. Transport layer software prepares Internet Protocol Datagrams containing blocks of file data and determines that the transmitted file data is properly received and acknowledged or is re-transmitted.

The Host/Network interface 46 is utilized to intercept the data packets transmitted between the network and data link layers 68,70. The interface 46 is utilized to format the data packets into an appropriate format depending on whether the data packet is incoming or out going. The interface 46 accomplishes this by removing the hardware address header when it receives a data packet and re-applies the same header when the packet is released (even if the underlying IP address header was changed). Since the interface in the software SNIU 46 does not handle ARP and RARP message for the host computer, it can be smaller than the one utilized in the hardware SNIU. As previously described, the ARP/RARP module included in the network layer 68 performs this function.

When the untrusted Host/Network Interface 46 completes re-assembling an IP datagram from a host computer, the datagram is passed to the Trusted Computing Base (TCB) of the SNIU for processing. The TCB is the collection of hardware and software which can be trusted to enforce the security policy. In the Dragonfly Guard the trusted Scheduler software module controls the hardware which controls access to memory and guarantees that IP datagrarns are not passed directly from the host-side Host/Network Interface module to the network-side Host/network interface module or vice versa. Rather each IP datagram is passed to the SNIU's other trusted software modules (Message Parser, Association Manager, Session Manager, etc.) which determine if the IP datagram is allowed to pass through the SNIU and if it is encrypted/decrypted. In a Dragonfly Companion the hardware is controlled by the host's operating system software and not the SNIU's Scheduler module. Therefore, the Dragonfly Companion is not as trust worthy as the Dragonfly Guard even though most of the software is identical.

The Message Parser 50B is the first module in the TCB which processes an IP datagram received from the host computer. The Message Parser 50B checks the Association Table 76 and determines whether or not an association already exists for sending the datagram to its destination. If no association exists, the datagram is stored on the Waiting Queue and the Association Manager 54 is called to establish an association between this SNIU and the SNIU closest to the destination host. If an association does exist, the Session Manager 48 is called to encrypt the datagram, check security rules, and send the encrypted Protected User Datagram (PUD) to the peer SNIU.

When the Association Manager 54 is called, it prepares two messages to initiate the association establishment process. The first message is an Association Request Message which contains the originating host computer security level and this SNIU's certificate (containing it's public signature key). This message is passed to the Fortezza API 56 which controls the Fortezza card which signs the message with this SNIU's private signature key. The second message is an ICMP Echo Request message which will be returned to this SNIU if it is received by the destination host. Both messages are passed to the network-side Host/Network Interface Module 46 to be transmitted to the destination host.

If another SNIU exists in the network between the originating SNIU and the destination host, the messages are first processed by the SNIU's receiving port's Host/Network Interface 46 which reassembles the messages and passes them to the trusted software. The Message Parser module 50B passes the Association Request Message to the Association Manager 54 module and deletes the ICMP Echo Request message. The Association Manager 54 passes the message to the Fortezza API 56 which verifies the digital signature. If not valid, the Audit Manager 52 is called to generate an Audit Event Message to log the error. If the signature is OK, the Association Manager 54 saves a copy of the received Association Request Message in the Waiting Queue, adds this SNIU's certificate to the message, calls the Fortezza API 56 to sign the message, generates a new ICMP Echo Request message, and passes both messages to the Host/Network Interface module 46 to transmit the messages to the destination host. If the messages are received by any other SNIU's before reaching the destination host, this process is repeated by each SNIU.

If the destination host computer does not contain the Companion SNIU software, the host's communications protocol stack software automatically converts the ICMP Echo Request message to an ICMP Echo Reply and returns it to the SNIU which sent it. However, the destination host does not contain any software which can process the Association Request Message; so it is ignored (i.e., deleted).

If the destination host computer does contain Companion SNIU software, the host's data link layer software converts the stream of bits from the physical layer into packets which are passed to the Companion's Host/Network Interface module 46. The hardware address headers are stripped off of the packets and saved; and the packets are re-assembled into IP datagrams which are passed to the Message Parser 50B. The ICMP Echo Request message is ignored; and the Association Request Message is passed to the Fortezza API 56 to have the signature verified. If valid, the message is passed to the Association Manager module 54 which saves the originating host and SNIU data and generates an Association Grant Message. This message contains the SNIU's IP address (which is the same as the destination host's), the SNIU's certificate, the host's security level, and sealer keys for the originating SNIU and the previous intermediate SNIU (if there was one). The sealer keys (a.k.a. Message Encryption Keys) are explained elsewhere.

The Fortezza API 56 is then called to sign the message which is passed to the Host/Network Interface module 46. The Association Grant Message is converted from an IP datagram to network packets and passed back to the host's hardware packet drivers (in the data link layer) for transmission back to the originating host.

Any intermediate SNIU's which receive the Association Grant Message process the message up through the communications stack protocol layers to the network layer which calls the Message Parser 50B to process the message. The signature on the message is verified by the Fortezza API 56 and audited via the Audit Manager 52 if not valid. Otherwise, the validated message is processed by the Association Manager 54 module which removes and saves one of the sealer keys (a.k.a. a release key) which will be used by this SNIU and the previous SNIU (which generated the key) to authenticate PUD messages exchanged via this association in the future. The Fortezza API 56 is called to generate and wrap another sealer key to be shared with the next SNIU in the association path. The new key and this SNIU's certificate are appended to the message. The Fortezza API 56 aligns the message. The Host/Network Interface 46 transmits the message on its way back to the originating SNIU.

The originating SNIU re-assembles the Association Grant Message via the physical, data link 70, and network layers 68 as previously described. The signature is validated and audited if necessary. If valid, the Association Manager 56 uses the Fortezza API to unwrap the sealer key(s). If two keys are in the received message, the bottom key is a release key to be shared with the first intermediate SNIU; and the top key is an association key to be shared with the peer SNIU (which granted the association). If there is only one key, it is the association key which is shared with the peer SNIU; and the association path does not contain any intermediate SNIUs. Once the keys are stored and the Association Table 76 is updated, the association is established and the Session Manager 48 is called to transmit the original user datagram which was stored in the waiting Queue prior to issuing the Association Request Message.

The Session Manager 48 enforces the security policy, determines whether IP datagrams received from host computers can be transmitted via the network to their destination host, and encapsulates these user datagrams in PUDs using the sealer keys for the appropriate association. The security policy is enforced by comparing the security levels of the host and destination. If the security levels are the same, the Session Manager checks the Association Table and identified the appropriate peer SNIU and sealer key(s). The user datagramn is encrypted by the Fortezza API 56 using the association key. If the association contains any intermediate SNIUs, the Fortezza API 56 calculates a message authorization code using the release key. The Session Manager 48 creates a PUD addressed from this SNIU to the peer SNIU, encloses the encrypted user datagram, appends the message authorization code (if any), and passes the new datagram to the Host/Network Interface module 46 on the network-side of the SNIU. The datagram is broken into packets and transmitted as previously described.

If an intermediate SNIU receives the PUD, the data is passed through the data link layer software 70 to the network layer where the re-assembled datagram is passed to the Session Manager 48. The source IP address is to identify the release key which is shared with the previous SNIU. The Fortezza API 56 uses the release key to verify the message authorization code. If not valid, the Session Manager 48 deletes the datagram and calls the Audit Manager 52 to generate an Audit Event Message. If the code is valid, it removes the code from the datagram, and uses the destination IP address to identify the release key shared with the next SNIU. The Fortezza API 56 generates a new message authorization code. The Session Manager 48 appends the new code and passes the datagram to the opposite port's Host Network Interface module.

When the peer SNIU (i.e., the destination IP address) received the PUD and it has been reassembled into a datagram, the Message Parser 50B passes the datagram to the Session Manager 48. The source IP address is used to identify the corresponding association key. The Fortezza API 56 decrypts the original user datagram. The Session Manager checks the message authorization code and the security levels of the source and destination hosts. If the code is valid (i.e., the message was not modified during transmission over the network) and the security levels match, the decrypted datagram is passed to the Host/Network Interface 46 to be released to the destination host. If either is not correct, the Audit Manager 52 is called.

Associations

To establish trust between pairs of SNIUs, within all Internet protocol (IP) based networks, the present SNIU uses "associations". An association is a sharing of trusted information developed within the SNIU on an as needed basis. The SNIU discovers the trusted information it needs, when it needs it. There is no need for pre-positioned network configuration data. The SNIU uses custom messages and existing protocols to determine the existence 701 and security parameters of other SNIU devices and maintains that information, called an association, as long as it is needed and unchanged 711. The SNIUs establish an "association" at the session layer in the communications stack which provides a trusted communications path for a period of variable duration between the SNIUs. While creating the association, the two SNIUs exchange security parameters 707 in a trust worthy manner. While an association is open, the two SNIUs use the association's security parameters to make security decisions 708, 710 for each Internet protocol (IP) packet of information exchanged.

When a host behind a SNIU attempts to communicate with someone else over the network, the SNIU transmits an Association Request Message and an ICMP Echo Request to the intended destination. The Association Request Message is used to identify other SNIUs in the communications path and to carry the originating SNIU's security parameters.

Each SNIU which receives the Association request message authenticates the message, sends it on to the destination, and transmits a new ICMP Echo Request to the destination. The destination host does not recognize the Association Request Message, but does recognize the ICMP Echo Request message; so it returns an ICMP Echo Reply message.

The SNIU which receives the ICMP Echo Reply message is the terminating SNIU (i.e., closest to the destination) in the potential association's communications path. This SNIU determines if the association should be permitted, i.e., would not violate the security policy. The terminating SNIU creates an Association Grant Message, inserts its security parameters, and sends it back to the originating SNIU. When the originating SNIU receives the Association Grant Message, it authenticates the message and extracts the destination's security parameters.

Address Resolution Messages

Address Resolution Protocol (ARP) allows a host to find the hardware address of another host on the same network, given its IP address. The host broadcasts an ARP Request message which contains its hardware and IP addresses and the IP address of the target host. The target host (or an intermediate gateway) returns to the requesting host an ARP Response message which contains the hardware address of the target host (or the gateway).

Reverse Address Resolution Protocol (RARP) allows a host which only knows its hardware address to obtain an IP address from the network. The host broadcasts a RARP Request which contains its hardware address; and a server on the network returns a RARP Response containing an IP address assigned to the requestor's hardware address.

All ARP and RARP messages have the same format and are contained within the frame data area of a single Ethernet frame (they are not IP datagrams). According to Douglas E. Comer, the format is as follows:

         0      8      16      24      31
         HARDWARE TYPE                PROTOCOL TYPE
         HLEN               PLEN        OPERATION
         SENDER'S HA (bytes 0-3)
         SENDER'S HA (bytes 4-5) SENDER'S IP (bytes 0-1)
         SENDER'S IP (bytes 2-3) TARGET'S HA (bytes 0-1)
         TARGET'S HA (bytes 2-5)
         TARGET'S IP (bytes 0-4)

    0      8      16      24      31
    NEXT
    PREVIOUS
    IP ADDRESS
    PEER SNIU IP ADDRESS
    ASSOCIATION KEY POINTER
    RELEASE KEY POINTER
    ASSOC-TYPE     RELKEY-TYPE      SECURITY-     AC-CLIENT
                                    LEVEL

    0      8      16      24      31
    NEXT
    DISTINGUISHED NAME (bytes 0-3)
    . . .
    DISTINGUISHED NAME (bytes 28-31)
    MEK (bytes 0-3)
    MEK (bytes 4-7)
    MFK (bytes 8-11)
    IV (bytes 0-3)
    IV (bytes 4-7)
    IV (bytes 8-11)
    IV (bytes 12-15)
    IV (bytes 16-19)
    IV (bytes 20-23)
    CERTIFICATE POINTER
              INDEX            SPARE            SPARE

• Inventors
  Boyle, John; Holden, James M.; Levin, Stephen E.; Maiwald, Eric S.; Nickel, James O.; Snow, David Wayne; Wrench, Jr., Edwin H.;
• Assignee
  ITT Manufacturing Enterprises (Wilmington, DE)
• Published
  Apr-3-2001
• Current US Classes:
  380/255
  380/277
  380/278
  380/287
  713/150
  713/168
  713/189
  713/200
  713/201
• Application #
  848823
• International Classes
  H04K 001/00; H04L 009/00
• Field of Search
  395/186 395/187.01 380/4 380/9 380/23 380/25 380/49 380/50 380/159 380/255 380/256 380/287 380/277-286 380/44-47 380/28 380/29 380/30 713/150-152 713/155-159 713/164-181 713/189 713/200 713/201
• Examiner
  Gregory; Bernarr E.
• Agent
  Plevy; Arthur L. Buchanan Ingersoll PC
• US Patent References:
  4694492
  4799153
  4868877
  4882752
  4885789
  4896319
  4962449
  4984272
  4991208
  5032977
  5056140
  5075884
  5111390
  5113499
  5126728
  5163147
  5204961
  5228083
  5249212
  5249231
  5283828
  5287519
  5295266
  5323146
  5355474
  5361359
  5369702
  5369707
  5375244
  5414833
  5414844
  5416842
  5465299
  5469556
  5469569
  5511122
  5519704
  5526489
  5537544
  5548721
  5555373
  5557742
  5574912
  5577209
  5583940
  5590266
  5596718
  5602920
  5606668
  5619657
  5627766
  5638446
  5692124
  5802178
  5828832
  5832228