Towards a Policy System for IPsec: issues and an ... - CiteSeerX

Towards a Policy System for IPsec: issues and an experimental implementation Madalina Baltatu, Antonio Lioy, Dario Lombardo, Daniele Mazzocchi Dip. di Automatica e Informatica Politecnico di Torino (Italy)

Abstract IPsec, the standard suite of protocols to provide security in IP networks, and IKE, the commonly used key management protocol for IPsec, do not address the more general problem of how security policies should be distributed to IPsec nodes. Recent IETF work in the area of network security provides a definition of the basic requirements of an IP Security Policy System (IPSP) and a proposal of a Security Policy Protocol (SPP) to exchange security policies. IPSP recommends that traditional mechanisms for distributing network management information (SNMP, COPS) should also be taken into consideration. The first objective of this paper is to evaluate the suitability of existing network management mechanisms to achieve the goals of IPSP. Subsequently, the paper describes and discusses an approach followed in the implementation of an IPSP system, with emphasis on the implementation of SPP.

1

Introduction

With the advent of IPsec [1], security at the network layer is becoming increasingly popular. IPsec is used to create a wide range of protection schemes, like secure virtual private network configurations, secure end-to-end communications, secure remote access and so on. However, IPsec applications have a major drawback: they require prior mutual agreement on acceptable cryptographic parameters and security services on all IPsec devices that participate to the communication. This can result in complex management tasks that become especially difficult as networks scale up. Moreover, consider the general case of two hosts that need to protect their communication across the Internet with IPsec. The related traffic may travel across heterogeneous networks, and may be subject to different security policies, controlled by different administrative entities. In other words, along the communication path between the two hosts there may be other IPsec devices (security gateways), enforcing different policies on the traffic they are forwarding. The end-nodes need a means for discovering

the presence of such gateways, together with the policies they enforce. While a mechanism for negotiating IPsec Security Associations (SAs) between hosts that share common security policy already exists (Internet Key Exchange, IKE [2]), neither IPsec protocols nor IKE offer a means for providing the security policies under which the SAs operate. IPSP [3] was created to offer a comprehensive solution to these problems. The goal of IPSP is to provide a scalable, decentralized framework for managing, discovering and resolving IPsec policies. After a short introduction to the rationales of the approached area, the paper continues, in Section 2, with the presentation of the state of the art in the field of network-level security policy provisioning/distribution, together with concise analyses of each of the mechanisms brought into light. Section 3 addresses important IPSP practical issues while presenting a case study of IPSP implementation at our site. Finally, the conclusions and future work are presented in Section 4.

1.1

Rationales and goals of IPSP systems

Policy systems compliant to the IETF’s IPSP standards provide: a common policy model that defines the semantics of IPsec policy, a reliable mechanism for gateway discovery and policy discovery, a comprehensive and rich enough language in which to express policies, a means for delegating responsibility for policy configuration/distribution, and mechanisms for policy resolution and compliance checking. The administration of policy systems is inherently heterogeneous and decentralized, so IPSP must offer a viable model of trust and authentication of policy exchanges. These issues are addressed by SPP [4], which requires message authentication based on digital signatures, and proposes a trust model for guaranteeing that the policies transported by its messages are provided by authoritative entities. Specific examples of SPP operation and a more detailed evaluation of overall IPSP and SPP architecture can be found in [5]. SPP provides mechanisms for gateway discovery, and for policy discovery, exchange and resolution. SPP can be used

inside single security domains, nested domains and across domains that are under different administration. From an operational point of view, SPP is very similar to DNS: clients ask servers for a specific piece of information (in the particular case of SPP, this information is the policy governing a specific communication), and servers cooperate in resolving the query. For increasing performance, each server also maintains a cache with the most recent queries resolved. Unlike DNS domains, the SPP domains (i.e., the security domains) do not respect a hierarchical structure (except for the particular case of nested domains). The security models proposed by the two systems are also different: in DNS, each RR in a message is signed by the originating server, while in SPP the whole message is digitally signed. SPP messages are verified and re-signed by each server that participates in an SPP exchange. Section 3.4 examines more thoroughly the authentication mechanism.

2

Existing policy distribution mechanisms

Since network level security policy can be seen as part of the more general network management framework, and since automated mechanisms for network management already exist, it is natural to try to adopt these mechanisms for security policy distribution. Some of the protocols taht can be taken into consideration are: SNMP, COPS and LDAP. In the followings we examine different aspects related to the possibility of using such protocols for achieving the goals of an IPSP system.

2.1

SNMP

SNMP [6] is traditionally used for performing network level management functions. The IPSP WG has recently proposed a configuration SNMP MIB for IPsec/IKE policy, which allows network administrators to configure IPsec devices [7]. The SNMP’s scope of use is a heterogeneous network environment controlled by the same administrative authority. Therefore, from the perspective of IPSP requirements, SNMP answers the need for policy distribution inside single security domains. Indeed, this task can be easily provided by an SNMP system, using the configuration model of SNMP (SNMP-CONF [8]): by means of SNMP, the policy server configures controlled policy clients with IPsec policies, setting the values of the appropriate MIB policy objects. A client can initiate/accept an IPsec communication if configuration information for that specific communication type has already been distributed to it. SNMP provides authentication/confidentiality services based on symmetric cryptography. As a consequence it

is appropriate for securely distributing configuration information inside single administrative domains and across domains that have prior agreements. SNMP can support neither secure communications between two unknown entities, nor a dynamic policy discovery mechanisms as implemented by SPP. Inside single administrative domains, though, SNMP offers a viable solution for policy configuration. Since at some sites SNMP-based management schemes are already used for common network management tasks, this solution can also prove to come at a low price.

2.2

COPS

COPS [10] with the extensions for provisioning [11] is another protocol that can be used to distribute policy information to IPsec devices. The IPSP working group has proposed a Policy Information Base (PIB) to be used for IPsec/IKE policy provisioning [12]. The IPsec PIB downloaded to IPsec-enabled devices enables them to construct a Security Policy Database (SPD). The policy information transferred with COPS is always the local policy (except for static IPsec scenarios in which policy configuration on PDPs is priorly agreed upon). In general, there cannot exist COPS exchanges between different administrative domains because PDP-to-PDP communications are not supported by COPS, while PEPs from remote domains could hardly communicate with PDPs in domains that are not trusted: according to the COPS architecture and to its symmetric cryptography-based authentication model, the PEPs would have to maintain persistent TCP connections and share a secret with the remote PDPs. These strong limitations make COPS unsuitable for policy discovery across different domains. Furthermore, COPS may prove not to be appropriate for domains that have to provision IPsec policy to numerous end-nodes: a tread-off has to be reached between performance and the number of PDPs inside the domain. In our opinion COPS is a good solution for policy provisioning in domains that enforce IPsec policy prevalently at the network boundaries.

2.3

LDAP

Recent work at IETF [14] specifies the mapping of the generic policy information model classes defined in [13] to a directory that uses LDAPv3 [15] as its access protocol. Since the policy LDAP schema potentially exists, let us examine some of the policy distribution scenarios that could make use of it. Inside a security domain, the nodes that need IPsec policies can be directly given access to an LDAP policy repository, or the policy server relies on an LDAP server for providing policy information to policy client’s queries (the queries may be encapsulated in other protocols,

like SPP). Both these architectures seem to follow a centralized approach. However, this may not be always true: with the intrinsic distributed nature of LDAP, behind the LDAP server known by a single client a whole distributed mesh of LDAP servers may be hidden. The servers manage different policy repositories and cooperate in providing policy information to requestors (using the LDAPv3 standard referral mechanism). This model make us consider LDAP appropriate for the distribution of policy even across security domains that are under different administration. The appropriate security model is the one based on public key infrastructures: theoretically the system can work if servers rely on mutually trusted third parties for authentication. The availability and performance issues of the LDAP model are to be evaluated: IPsec/IKE processing already introduces a considerable overhead to input/output traffic processing, we would surely prefer having an efficient policy distribution system.

3

An experimental implementation of IPSP

As a conclusion of our analysis of ISPS [5], we stated that in spite of its imperfections (mainly derived from its complexity and its deliberate flexibility), ISPS can offer a viable uniform solution to the problem of security policy distribution in TCP/IP networks. Since at the time this paper was written there were no available implementations of IPSP, and since we felt that a concrete implementation of the system could help us in better evaluating its pros and cons, we decided to build a prototypal IPSP system. After testing more open source IPsec distributions, we chose an OpenBSD release 2.7 operating system with a fully compliant in-kernel IPsec stack. OpenBSD was the first operating system to ship with an IPsec stack (since early 2.1 release in 1997). It offers the possibility to manually configure SAs, but also to negotiate them with IKE, and automatically load them into the kernel’s SA database via the PF KEYv2 [17] socket interface. In our implementation (described in detail in [16]), IPSP functionalities are provided by an application-level policy module: a daemon application present on any IPSP system. The module provides three different behaviours, depending on the local system instantiation: policy server, policy client or security gateway, the latter being a special case of the policy client instantiation.

3.1

Policy module architecture

Functionally, the policy module is divided in two layers: the upper layer handles the communication with the local IPsec kernel and manages the policy databases (the cache database on clients, the cache and the domain database on

servers), while the lower layer handles the SPP protocol exchanges (it implements the security policy communication protocol). The two layers architecture, illustrated in Figure 1, permit higher parallelism of policy module operations, therefore an enhanced performance is obtained. Separation of tasks also makes the system easier to manage and control. The protocol layer is practically identical for all module types, with two exceptions: common policy clients do not manage SPP-KEEP ALIVE messages (they are only exchanged between servers and security gateways), while servers also implement authorization control at this level. Indeed, the FSMs that model the protocol layer behaviour have the same number of states on all IPSP systems (five), but server FSMs have slightly more transitions (21, while client FSMs have 19). Is the policy layer that discriminates between the various IPSP module types. While the policy layer on clients provides basically two functions (the communication with the local IPsec kernel via PF KEY, and the management of the policy cache database), the policy layer on servers is also provides policy resolution to hosts inside the local security domain, it responds to queries that come from outside the local domain boundaries, or forwards queries to other domains, it manages the domain’s policy repository, and it provides a policy compliance checking mechanism applied to all the received policies. The policy processing on an end-node IPSP client is triggered by the receipt of a local request for policy resolution. Whenever the IPsec kernel cannot find an SPD entry pointing to an active SA for an outgoing IP packet, it asks the policy module to acquire one. The policy may be found in the local cache from a previous SPP exchange, or a policy resolution process is started (an SPP query message is sent to the policy server authoritative for the domain). The “perpacket” policy processing is a consequence of the IPsec implementation on OpenBSD [18]. On policy servers the IPSP processing is basically triggered by the receipt of a policy query, while on security gateway clients there are two other triggering events: the receipt of an incoming policy configuration SPP message from the authoritative server and the receipt of an SPP message from a remote domain. A fundamental task of security gateways is to forward all SPP messages that come from outside the domain’s boundaries to the local policy server.

3.2

Extended PF KEY API

PF KEY is a standard interface defined for the communication between trusted applications and an operating system’s IPsec kernel. SA information can be inserted into and retrieved from the kernel’s SA databases using a defined set of messages. The PF KEY interface is traditionally used by the IPsec key management layer. By extending the basic PF KEY functionality, we have the policy module interact-

policy db

Policy Management

Key Daemon

Protocol Layer

socket layer (PF_KEY, PF_INET, ...)

Applications OS Kernel

Transport SPD

IP & IPSec Link Layer

Figure 1. Two layers policy module architecture. ing with the IPsec kernel in a similar way the key management applications do (see Figure 1). Our extended PF KEY specification defines four message types together with the related message processing ([16]). These messages are to be used only between the kernel and the IPSP application listening on an PF KEY family socket. This way there is a clear separation between the policy acquisition and the SA acquisition processes. Note that in OpenBSD 2.7 the two functions were not always distinguished from each other: apart from SA parameters, the IKE daemon is also allowed to feed policies into the kernel.

3.3

Overall policy system architecture

A critical aspect of the IPSP architecture (as defined in [4]) is its flexibility, which results in the definition of a complex system, therefore a system whose functionality is not trivial to control and which can easily become unmanageable. As though, we strove to obtain simplicity whenever possible during the system design. The definition of the roles played by the various parties involved in policy processing is a point where we felt that SPP specification was loosely, and that some clear decisions could straighten up the system implementation. In our prototypal IPSP system, all policy decisions are taken by the policy servers: neither common IPsec nodes nor security gateways are permitted to directly enforce their own policies. The practical implementation of this behaviour is the following: even if a policy is found in the local SPD (but not an active SA), a policy query is always sent to the local policy resolver. The required policy may already exist in the local cache from a previous SPP exchange, or the configured policy server

will provide for it. If there are hosts inside the domain that are allowed to enforce their own policies, they become policy servers authoritative for themselves. With this architecture, apart from the coherency and the intrinsic synchronization of policy information, we also achieve the simplification of the access control mechanism on servers (only read access has to be granted and verified for the clients, since they are not allowed to update policy on servers using SPP messages). While allowing for local policy decisions may sometimes be seen as a matter of performance, we state that an appropriate dimensioning of the CACHEEXPIRY time on policies can be a better way to achieve performance. Meanwhile, assigning unequivocal roles to IPSP entities allows for more lightweight policy processing on clients: since they completely rely on servers for policy provisioning, they are not required to implement mechanisms for policy compliance checking. Generally, it is undesirable to change user behaviour when introducing new technologies. While emphasizing the role of servers (common hosts are only policy cache holders, so they are minimally involved in the policy decision process), our implementation offers another important advantage: the existence of the IPSP processing becomes transparent for the end-user.

3.4

SPP authentication

After a careful evaluation of the authentication mechanisms proposed for SPP, we reached the conclusion that in general cases IPsec is inappropriate for protecting SPP exchanges. Besides the chicken-and-egg problem that it raises (see [5]), IPsec protection requires up to an order of n2 IKE exchanges (where n is the number of SGs in the com-

munication path) to finally have protected SPP traffic pass through to the other end of the communication. SPP with digital signatures avoids this at the price of making policies public. If policy confidentiality is required, the only possible approach is to divide SPP into two phases (or two protocols): in the first phase the security gateways in the path are discovered, while in the second phase, since the identity of the intermediary gateways are known, policy information can travel encrypted inside IPsec packets. This approach can work if the discovery protocol itself is not subject to policy constraints. The drawback is a loss of efficiency in an already inefficient process. There are benefits to both approaches, confidential versus non-confidential policies, even if the first version of the SPP draft is clearly biased towards the latter. Since we consider the efficiency of SPP too valuable to be affected by the complexity of supporting a protocol that can operate in two ways, and confidentiality of policies is not appreciated as a critical requirement for our open network environment (policy is already secure from tampering and is authentic), in our prototypal IPSP system policy information is always signed, but it travels in the clear from the source to the destination domain. Our implementation uses RSA as the digital signature algorithm (as implemented by the OpenSSL 0.9.6 cryptographic library), and the signature is in PKCS#1 format. We preferred PKCS#1 instead of, for example PKCS#7 detached signature, for obtaining a more lightweight processing of signature data. Furthermore, we decided to separate the process of signature validation from the certificate validation. In this way, more flexibility is allowed for the configuration of the certificate validation procedure on policy servers (may be based on CRLs, OCSP, etc.). We also decided not to load the SPP message processing by implementing the certificate fetching mechanism described in [4]. For efficiency, the default behaviour for policy servers is to always add to the response messages the certificate record. If other certificates are needed for the validation of server certificates, SPP is not the recommended way to obtain them. Policy servers must be able to securely reach the root of trust for a given certificate using a reliable alternative method ([19]).

3.5

Chain-of-trust validation

The cornerstone of the policy validation mechanism is the validation of the chain-of-trust. By means of the SPP policy server record a server claims its authorization over a node. The presence of such a record is not enough for proving the server’s authoritativeness. To this purpose, a signed proof has to be provided (e.g., inside the server’s certificate). The two methods for providing this proof (new extension in the servers certificates and/or the use of attribute certificates) are described in detail in the extended version of the present paper.

3.6

SPP authorization mechanism

Implementing access control on policy servers may seem somewhat redundant, since the policy itself should indicate what nodes are allowed to do. Though, authorization checks at this level may be useful for increasing performance: the policy resolution process is quite expensive, so, when possible, it is better to decide in advance if the requesters are allowed to trigger it. Consistent with this approach is the implementation of a lightweight “black list” mechanism. While this approach works for policy requests that arrive from inside the security domain, for policy requests that come from outside the domain’s boundaries it may not be enough, depending on the local administrative policy. Since the identity of the remote policy requester is not always priorly known, we propose two solutions for authorization: either allow access to policy information to all authenticated policy servers, or provide additional checks based on a dynamically built acl. The authorization mechanism is described in detail in the extended version of this paper.

3.7

Comments on IPSP implementation

Even if our implementation supports all message types defined by the SPP document, there are some query types that our IPSP systems will not use. These are the certificate and the security gateway query. Though, if these queries are received, the correct reply will be provided to them encapsulated respectively in a certificate record or a security gateway record. Certificate queries are not sent because the certificate fetching mechanism (the initiator side) is not supported for reasons explained in Section 3.4. As far as the security gateway queries are concerned, we implement only the responder side of this mechanism, for the sake of interoperability. We do not consider fundamental nor effective for the SPP operation supporting this mechanism (except for the case when policy confidentiality is needed, see the related discussion in Section 3.4). In our opinion the policy discovery mechanism is enough for almost all possible scenarios of use of SPP.

3.8

Some considerations on testing and performance

An important step for the IPSP practical implementation is the evaluation of resource requirements for running the IPSP server/client software. Since the requirements are straightly related to the size of the controlled security domain, we decided to study a specific case: our campus network, which is up to 4000 systems (hosts and network devices), and 50 interconnected 10 Mbits/s LANs. The first aspect that we approached was the implementation of the policy databases. The main database is the policy database, which has a known size, and contains the

description of the security domain, together with the local policies. For performance reasons, each IPSP node mainatains a cache database, which has a variable size, and contains combined local and remote policies received during SPP exchanges. Again, note the analogy with DNS’s zone and cache databases. The policy cache database is implemented as a dynamic structure: the policy records stay in this database as long as indicated by the CACHE-EXPIRY value present in each record. The CACHE-EXPIRY is a 32-bit field also transported with each policy record inside SPP messages. The dimensioning of the CACHE-EXPIRY parameter together with a correct allocation of memory resources are very important for the overall system’s performance. As always in these cases, a trade-off has to be reached between the amount of memory and the expense of generating SPP traffic. Till the widespread deployment of IPSP, for a good approximation of the upper memory size we can look at DNS, even if the memory requirements for DNS should be a bit over-dimensioned for IPSP. The SPP protocol layer introduces on average 5 ms of delay to the message processing (non-authentiucated messages). Though, the operations that inflict the most on performance are the RSA digital signature and signature validation. The cryptographic library used was OpenSSL 0.9.6 on a 700 MHz Pentium III with 128MB of memory. On average, it takes 9 ms for signing and 0.5 ms for verifying the signature. Note that for each type of SPP message, the sum of these values has to be multiplied by the number of servers involved in an SPP exchange. For a completed policy resolution process, at least two types of messages are employed: the query traveling from the source domain to the destination, and the reply traveling in the opposite direction, so the number of public key operations indicated before is doubled.

4

Conclusions and future work

Currently, we are working at the implementation of the policy management layer of our policy module. Specifically, the parts that are under construction are the internal language used by IPSP systems to express security policies and the policy compliance checking mechanism. Aside from the Security Policy Specification Language (SPSL) proposed by the IPSP working group in [20], we are taking into consideration KeyNote [21]. At the present we are evaluating the performance of the KeyNote compliance checking mechanism, and the flexibility offered by its policy language. Since one of our objectives (as stated in [5]) is to study how IPSP can accommodate the policy provisioning needs of other security protocols and applications (e.g., TLS, S/MIME [23]), we are working at the definition of the requirements of an extended policy language for supporting more different sets of security policies.

References [1] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998 [2] D. Harkins, D. Carrel, The Internet Key Exchange, RFC 2409, November 1998 [3] M. Blaze, A. Keromytis, M. Richardson, L.A. Sanchez, IPsec Policy Architecture, Internet Draft, July 2000 [4] L.A. Sanchez, M.N. Condell, Security Policy Protocol, Internet Draft, July 2000 [5] M. Baltatu, A. Lioy, D. Mazzocchi, Security Policy System: Status and Perspective, Proceedings of the IEEE International Conference on Networks 2000 (ICON 2000), pages 278-284, September 2000 [6] J. Case, R. Mundy, D. Partain, B. Stewart, An introduction to Version 3 of the Internet-standard Network Management Framework, RFC 2570, April 1999 [7] M. Baer, R. Charlet, W. Hardaker, D. Partain, J. Sapeira, C. Wang, IPsec Policy Configuration MIB, Internet Draft, February 2001 [8] M. MacFaden, J. Sapeira, W. Tackabury, Configuring Networks and Devices with SNMP, Internet Draft, November 2000 [9] U. Blumenthal, B. Wijnen, User-based Security Model for version 3 of the SNMP, RFC 2574, April 1999 [10] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, The COPS (Common Open Policy Service) Protocol, RFC 2748, January 2000 [11] K.H. Chan, D. Durham, S. Gai, S. Herzog, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, COPS Usage for Policy Provisioning (COPS-PR), Internet Draft, September 2000 [12] M. Li, D. Arneson, A. Doria, J. Jackson, C. Wang, IPsec Policy Information Base, Internet Draft, November 2000 [13] B. Moore, E. Ellesson, J. Strassner, A. Westerinen, Policy Core Information Model Version 1 Specification, RFC 3060, February 2001 [14] J. Strassner, E. Ellesson, B. Moore, R. Moats, Policy Core LDAP Schema, Internet Draft, March 2001 [15] M. Wahl, T. Howes, S. Kille, Lightweight Directory Access Protocol (v3), RFC 2251, December 1997 [16] M. Baltatu, TCP/IP Networks Security and Policy Based Networking, Ph.D. thesis, Politecnico di Torino, Computer Science Department, October 2000 [17] D. McDonald, C. Metz, B. Phan, PF KEY Management API, Version 2, RFC 2367, July 1998 [18] A. Keromytis, J. Ioannidis, J. Smith, Implementing IPsec, Proceedings of Global Internet (GlobeCom) ’97, pages 1948-1952, November 1997 [19] Rodney Thayer, Charles Kunzinger, Paul Hoffman, A PKIX Profile for IKE Internet Draft, December 1999 [20] M. Condell, C. Lynn, J. Zao, Security Policy Specification Language, Internet Draft, March 2000 [21] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis, The KeyNote Trust Management System version 2, RFC 2704, September 1999 [22] T. Dierks, C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999 [23] B. Ramsdell, S/MIME Version 3 Message Specification, RFC 2632, June 1999