Centralized deployment of IPSec policy information

Details Centralized deployment of IPSec policy information Centralized deployment of IPSec policy information

2000-06-09

2004-02-24

Barot, Bharat (Department: 2154)

Electrical computers and digital processing systems: multicomput

Computer network managing

Computer network monitoring

C709S202000, C709S226000, C709S229000, C709S244000, C713S153000

Reexamination Certificate

active

06697857

ABSTRACT:

TECHNICAL FIELD
This invention relates generally to network data transmission security and, more particularly, relates to an improved method and system for deployment of IPSec security policy in a centralized manner.
BACKGROUND OF THE INVENTION
The prevalence of network technology has increased dramatically in recent years. From the Internet to intranets, computers throughout the world have become massively interconnected. Businesses, institutions, and private users alike routinely place sensitive information onto networks and rely upon the security of the network to protect the security of such information.
A majority of network traffic utilizes the Internet Protocol (IP) for data transmission. The Internet Protocol, part of the TCP/IP communications protocol, implements the network layer (layer
3
) of the protocol, which contains a network address used to route messages. IP has no default security scheme associated with it, and accordingly, IP packets are often easily intercepted, read, copied, corrupted, mimicked and so on.
The IP Security Protocol (IPSec) was designed by the Internet Engineering Task Force (IETF) for IP. IPSec supports network-level authentication, data integrity, and encryption, as well as anti-replay and non-repudiation protection. In contrast to Secure Sockets Layer (SSL) and other transport layer security protocols, IPSec operates at the network layer to secure most types of IP packets. IPSec, as defined by the IETF, uses an authentication header (AH) format and/or an encapsulated security payload (ESP) format to secure IP datagrams. The authentication header provides data communication with source authentication and integrity, while the encapsulated security payload provides confidentiality as well as a limited degree of source authentication.
The keying scheme specified by the IETF for IPSec is the Internet Key Exchange protocol (IKE), documented mainly in IETF RFC 2409. This describes a method whereby the sender and recipient negotiate trust and security settings, including the generation of shared secret cryptographic keys to be used for application data encryption in the AH and ESP IPSec formats. If the authentication data in each IPSec packet is valid, the recipient can be confident that the communication originated from the sender and that it was not altered after transmission.
Windows 2000 implements the Identify Protect Mode of the Internet Key Exchange protocol. In this version of IKE, before application data IP packets can be transmitted from one computer to another, three security associations (SAs) must be established between the communicating parties. The first is called the IKE security association (Main Mode or Phase 1 SA), which serves a high level trusted channel established between the two parties. Then two IPSec security associations (Quick Mode, or Phase 2 SAs) are established; one from peer A to peer B, the other from B back to A. An SA is a set of parameters that defines the services and mechanisms, such as keys, to be used to protect communications. The Internet Security Association Key Management Protocol (ISAKMP) defines a framework for supporting the establishment of security associations without being linked to any specific algorithm or key generation method. The Oakley Key Exchange protocol provides a secure method for exchanging cryptographic key material such that an observer of the communication cannot easily discover the secret shared key generated by the two parties. The Internet Key Exchange (RFC 2409) and the IPSec Domain of Interpretation for ISAKMP (RFC 2408) provide detailed specifications from whence ISAKMP and Oakley are integrated to produce a single IPSec-specific key exchange protocol.
The collection of IPSec parameters applicable to a machine are referred to as an EPSec security policy. Although there may be many possible security policies, a given machine may generally have only one security policy active at a given time. A security policy contains certain policy-wide parameters such as the polling interval to be used to detect changes in policy, as well as parameters such as key lifetimes usable for negotiation of a Main Mode security association. Finally, a security policy also contains one or more rules, each of which further contains several other sets of parameters.
It may often be necessary or desirable for ease of administration to configure security policy for a group of machines, such as a corporate network, in a centralized manner. Thus, for example, a network administrator may establish a source of policy information, such as on a directory service, to be periodically downloaded by specific machines to replace their existing security policy. While this provides for ease of policy change and ease of administration, it is important that each machine have the most up-to-date policy available. Furthermore, if there is a temporary loss of connectivity between a machine and the directory service, it is desirable that the machine in question not suffer a lapse in security by having no policy at all in place at any time. There is needed a method of efficiently obtaining new policy information and updating and applying a machine's IPSec security policy such that there is substantially always a security policy in place on a machine if a policy is assigned to that machine, and such that there is never a significant lull in security coverage.
SUMMARY OF THE INVENTION
The invention provides an improved method and system for the maintenance of centrally deployed IPSec security policy information on individual machines. In an embodiment of the invention, a four-state finite state machine is employed to track and maintain the security policy information of a given machine. By residing in and transitioning between the four states, the state machine effectively maintains the security policy of the machine with the most current security policy information accessible.
The invention provides a mechanism for maintaining the security policy on a machine from a number of sources, namely a directory service, a cache, and a local store. The state machine has four states: “Initial,” “DS,” “Local,” and “Cache.” The state machine starts in the initial state, and sequentially tries to plumb, or obtain and apply, the DS policy, Cache policy, and local Store policy. Success at any stage will divert the state machine to the appropriately named state. For example, if plumbing the DS policy succeeds, the state machine transitions to a DS state. From the various states, polling occurs to check for a change in the assigned policy. If the assigned policy has changed, the state machine transitions appropriately to obtain the new policy.


REFERENCES:
patent: 6009455 (1999-12-01), Doyle
patent: 6336128 (2002-01-01), Eisenmann et al.
patent: 6363424 (2002-03-01), Douglas et al.
patent: 6484257 (2002-11-01), Ellis
IPSec, “ICSA IPSEC Product Certification Criteria Version 1.0A”,ICSA IPSec Product Certification Version 1.0A Testing, Dec. 22, 1999 (pp. 1 of 8).
IPSec, “ICSA IPSEC Product Certificat Criteria Version 1.1”,ICSA IPSec Product Certification Version 1.1 Testing, Dec. 22, 1999 (pp. 1 of 4).
Security SnapShot, ICSA.net's Security Snapshot and ESnap are the quickest way's to estimate your company's Internet security posture in six important risk categories, (pp. 1 of 3) Apr. 5, 2000.
Harkins, D. et al., “The Internet Key Exchange (IKE)”, Network Working Group, RFC 2409 (Nov. 1998) pp. 1-38.
Maughan, D. et al., Internet Security Association and Key Management Protocol (ISAKMP), Network Working Group RFC 2408, (Nov. 1998) pp. 1-79.
Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP”, Network Working Group, RFC 2407, (Nov. 1998) pp. 1-30.
Kent, S., et al., “IP Encapsulating Security Payload (ESP)”, Network Working Group, RFC 2406, (Nov. 1998) pp. 1-21.
Madson, C., et al., “The ESP DES-CBC Cipher Algorithm With Explicit IV”, Network Working Group, RFC 2405, (Nov. 1998) pp. 1-10.
Madson, C., et al., “The Use of HMAC-SHA-1-96 within ESP and AH”, Network Working Group, RFC 2404, (Nov. 1998) pp. 1

Affiliated with

Also associated with

Rating

Centralized deployment of IPSec policy information does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Centralized deployment of IPSec policy information, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Centralized deployment of IPSec policy information will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3300075