Providing Security Policies and Encryption Keys


(T) To continue on my previous article about data encryption and access control, following is a new approach to provide security policies and encryption keys for IP Security (IPSec) network encryption.

This approach can combine a network access control (NAC) system with the encryption system. In other words, only when the users have been given access to the network can they encrypt their data.

IPSec provides network data encryption and authentication services. But the management and scale of IPSec policies and the key exchange mechanisms require by IKE (Internet Key Exchange) create a number of practical deployment limitations.

 IKE is based on a connection being established between two endpoints and a key negotiation being completed. IKE cannot be used if the traffic is sent from point-to-multipoint or multipoint-to-multipoint since there is no single pair of points that can perform key negotiation. As the result, IKE does not enable the scale of IPSec policies for large networks. For example, for 100 IPSec nodes with 20 subnets at each node, the number of security associations (SAs) could reach 79,200!

 Recently the IETF MSec working group has proposed two new protocols for key distribution the Group Domain of Interpretation (GDOI) RFC 3547 and the Group Secure Association Group Management Protocol (GSAKMP) RFC 4534, but that effort is limited to multicast. Data privacy shall be provided over any network topology such as point-to-multipoint and mesh networks and for any kind of IP traffic not only unicast but multicast and broadcast as well.

 By dividing policy and key management into separate components, a management plane and a control plane, from the IPSec Encryption Security Payload (ESP) data plane, we can change the fundamental connection-oriented nature of IPSec using IKE for encrypting data in motion.

 The management plane or policies are not defined for a device but for an end-to-end network. Multiple PEPs can be grouped together over the same policy in order to encrypt data for point-to-point, mesh, and hub-and-spoke networks.

 The control plane or keys are shared by multiple PEP devices such as for instance for multiple paths in a resilient network or for many end points in a multicast application.

 This new three-layer approach to network security includes the following functional components:

  • Policy Enforcement Point (PEP): The PEP devices still exist in the network to protect traffic, but rather than exchanging keys on a one-to-one basis using IKE with other PEPs, they each receive their policies and keys externally from a centralized entity;
  • Key Authority Point (KAP): The KAP generates the encryption keys and SAs associated with policies that it then distributes to the PEP units and peer KAP devices.
  • Management and Policy Server (MAP): The MAP provides network-wide policy management and policy distribution to the KAP servers. The MAP can also be combined with existing NAC services. The PEP client is authenticated via a NAC service. If remediation is required, the client accesses the remediation server, if not, the client accesses the network with its security policies generated by the MAP and distributed by the KAP server.

This network security overlay for the generation of policies and keys can accommodate all data privacy requirements in particular for resilient, multicast and MPLS networks and is transparent to the network routing and switching infrastructure.

 However, this architecture must be designed as a secure, resilient and scalable system. Security must be designed at the unit, system and communication layer. Resilient key operations must be provided. And it must scale to serve hundreds of end-points. 

Copyright © 2005-2008 by Serge-Paul Carrasco. All rights reserved.
Contact Us: asvinsider at gmail dot com.

Categories: Cybersecurity