Electrical computers and digital processing systems: support – System access control based on user identification by... – Using record or token
Reexamination Certificate
1999-11-08
2004-11-30
Sheikh, Ayaz (Department: 2131)
Electrical computers and digital processing systems: support
System access control based on user identification by...
Using record or token
C713S173000, C713S175000, C713S176000, C713S152000, C713S152000
Reexamination Certificate
active
06826690
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for using device certificates for automated authentication of communicating devices.
2. Description of the Related Art
In client-server networking environments, a device functioning as a client generally seeks to locate a device functioning as a server in order to access data (such as a Web page, a traditional flat file, etc.) or perform transactions with application programs executing on the server. Neither clients nor servers typically attempt to locate other clients—that is, communications are usually established by the client and not by the server. The client typically locates a server that can perform the desired service by issuing a get_host_by_name( ) function call (or equivalent) using a known host name (such as an Internet Protocol, or IP, name), in order to resolve this server host name to a server address (such as an IP address). The get_host_by_name( ) function call causes a query to be issued to a Domain Name System (DNS) service. A DNS server maintains a stored mapping of host names to IP addresses. Upon receiving a query for a particular host name, the DNS server can then return the stored IP address mapped to (i.e. associated with) that host name. These stored mappings are typically statically administered, and therefore it is typically important for a particular host name to have a constant IP address in order to facilitate dynamic access to that host (i.e. server) in a predictable manner that is independent of factors such as the timing of issuing the get_host_by_name( ) call. Traditionally, enabling use of a constant IP address is achieved by statically configuring the server's IP address at the server itself and at the DNS.
Client and server devices tend to attach to a network dynamically, and remain attached for varying lengths of time. Each such device must obtain a network address (such as an IP address), if it has not already been configured with one, in order to participate in network communications. In local area network (LAN) configurations, it is common practice to dynamically assign an IP address to a device when it connects to the LAN (for instance, when the device powers on). Protocols such as the Bootstrap Protocol (also known as “BootP”) and the Dynamic Host Configuration Protocol (commonly known as “DHCP”) are often used, among other purposes, to enable automatic dynamic assignment of an IP address to an IP host. (“Host” in this context merely refers to a computer device that has the capability of communicating with other computers.) A host requesting an IP address using DHCP is referred to as a “DHCP client”, and the host which implements the DHCP service and responds to such requests is referred to as a “DHCP server”. Similarly, in the BootP protocol the hosts are referred to as “BootP clients” and “BootP servers”. The policies and techniques with which the BootP and DHCP protocol implementations manage the assignment of IP addresses to hosts generally differ depending on whether the host is a client or a server. As described above, server addresses are typically statically configured, and constant in value. Thus, the benefits of BootP and DHCP for automatic IP address generation and configuration are therefore not generally available for hosts whose primary function is as a server. Instead, the server's address must be entered into the server manually, and if the server changes to a different physical location then a different address must be entered. (BootP is defined in the Internet Engineering Task Force's Request for Comments (RFC)
951
, titled “BOOTSTRAP Protocol (BootP)”, and DHCP is defined in RFC 1541, titled “Dynamic Host Configuration Protocol”.)
In view of the advantages of using BootP and DHCP, it would be desirable to enable use of these protocols for servers. Currently, if the physical topology of a LAN is changed, IP addresses of servers previously connected to segments of the changed topology may be no longer valid, and routers will then be unable to route traffic to those invalid addresses. The IP addresses of affected servers must first be changed in the DNS mapping, concurrently with reconfiguring each such server to use its new address. Typically, the reconfiguration of the server is a manual process, and the DNS update may sometimes be a manual process as well. If BootP or DHCP were available for dynamic address assignment to a server when a topology change occurred, this would enable significant improvements in the ability to centrally manage an IP network. For example, the BootP or DHCP service could dynamically manage which P addresses are associated with segments of the physical network, without needing to closely synchronize this activity with the physical location of computers acting in a server role, and without requiring these computers to be reconfigured concurrently with changes to the physical topology. The need for such improvements is compounded by the fact that enterprises (that is, large-scale computing installations and/or computing networks) are moving away from a centralized computing model to a highly distributed model of application deployment. As this move towards distributed computing progresses, more and more systems in the corporate network will take on the capability of performing in a server role. In the absence of automated IP address generation and management (such as that provided by BootP and DHCP), extra effort will be required to administer and manage the IP addresses for this increasing number of servers.
It would be advantageous to dynamically and automatically assign (e.g. using BootP or DHCP) an IP address to a host acting in a server role, such that the server's IP address would reflect the current IP address definition associated with its host name in the DNS hostname-to-address mapping. Some implementations of this technique are already in practice. However, these known techniques are deficient because of their inability for the network management component to know for sure what device is requesting an IP address assignment. These techniques do not have the capability of preventing a malicious third party from attaching to the network and masquerading as a host that is currently off-line (and is therefore not using its assigned IP address). This deficiency leaves such implementations vulnerable to the masquerading attack. Exploring this scenario in more detail, it would be possible for a malicious individual to program a different computer to simulate the functions of the host under attack, and then to cause a loss of power or a network disconnection such that the original host becomes disconnected or fails, and finally to enable the new (attacking) host to contact a BootP or DHCP server and impersonate the original host. Once an attacking host obtains the DNS identity of the original host by substituting its own IP address into the DNS mapping for the original host's name, the attacking host is then in a position to perform any number of security attacks (such as a Trojan horse attack, a denial-of-service attack, passing programs containing viruses or other harmful software to users, etc.). Or, the masquerading host could attempt to steal secrets (such as user identification, passwords, and/or private personal data) from users who log on to the masquerading host believing it to be the original host.
Given the current state of the art, it is also easy for an attacker to set up a fake DHCP service (or, similarly, a fake BootP service)—that is, one where the masquerading host assumes the responsibility for, inter alia, assigning IP addresses—thereby opening up an array of additional attacks by which the attacker actually assumes the identity of its victim server host, while the victim is still running. Current art does not provide any way for a DHCP server, before assigning an IP address, to distinguish an authentic requesting host from an attacker. Nor does it provide a mea
Hind John R.
Peters Marcia L.
Doubet Marcia L.
Herndon Jerry W.
LaForgia Christian
Ray-Yarletts Jeanine S.
Sheikh Ayaz
LandOfFree
Using device certificates for automated authentication of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Using device certificates for automated authentication of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using device certificates for automated authentication of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3294825