Security Policy System: status and perspective - CiteSeerX

Security Policy System: status and perspective Madalina Baltatu

Antonio Lioy

Daniele Mazzocchi

Politecnico di Torino Dip. di Automatica e Informatica Torino, Italy

Abstract With the recent definition of the Security Policy System, IPsec has joined the area of policy-based networking. This paper discusses the general architectural and functional requirements for systems in charge of security policy provisioning, and presents a critical evaluation of SPS. Some extensions are also suggested to increase SPS functionality in the network access control field.

The paper begins with an analysis of the policy requirements of IPsec networks, followed by an overview of the features of SPS. The central section discusses in detail the critical aspects of SPS from the implementors’ perspective. It also suggests some changes and clarifications that can be made to SPS to improve the system consistency and to extend its functionality in the authorization area. Finally, the conclusions put this work in perspective.

2 Policy System for IPsec 1 Introduction Policy Based Networking (PBN) is a topic of interest to many areas within the networking community. A policy is a set of rules that controls the behaviour of a network under different conditions. Rather than offering an uniform or best-effort service to all users, a policy-enabled network can take into account priorities or other user-level characteristics, and dynamically determine the treatment to give to each packet. Initially considered for the implementation and control of Quality of Service (QoS), policy-based networks are nowadays being deployed for a wider variety of applications, such as security and Virtual Private Networks (VPN). The IETF IPsec working group has recently defined the Security Policy System (SPS) [1] to address policy management issues in this realm. The present work discusses strengths and weaknesses of SPS, outlining the importance of providing strong security mechanisms to such a critical component of a policy-based network. Since the policies provided and enforced by means of SPS are used to guarantee a desired level of protection to all resources inside a given network, the SPS mechanisms themselves have to be highly reliable. As a consequence, fundamental issues for SPS are: authorization, authentication, access control, data integrity, and reliability in operation. In short, all the aspects regarding the intrinsic security of the system.

IPsec [2] is a suite of protocols to provide authentication and confidentiality across IP networks. The AH (Authentication Header) and ESP (Encapsulating Security Payload) offer authentication with and without encryption to IP datagrams. The Internet Key Exchange protocol (IKE) [3] provides key exchange mechanisms for AH and ESP. IPsec security services are offered via Security Associations (SA) established between communicating IPsec systems. A SA is the set of security protocols, modes (tunnel/transport), algorithms, and keys to be applied to an unidirectional IP packet flow. The SA is identified by a set of selectors that describes the IP packet flow to which it applies (e.g., source and destination addresses, transport protocol and ports). Each IPsec node maintains a local database – the Security Policy Database (SPD) – consulted when processing input/output IP traffic. The SPD controls which communications ending at the node are denied, permitted with no restriction, or permitted if protected by IPsec. For the last case, the SPD must point to the SA to be used for processing the traffic. Current practice with IPsec and IKE assumes that communicating hosts have some a-priori knowledge of which communications must be secured and in what manner. In other words, each IPsec node is supposed to have the SPD configured for all possible communications. While this assumption is valid in some cases (e.g., a statically configured VPN), it does not support more general IPsec scenarios.

SECURITY DOMAIN SPS Master File (local policies, security domain information)

database non-local policies external policy Policy Server

Policy Client

SPP

servers and clients

SPP

Security Gateway

SPP

Figure 1. SPS components.

For IPsec to scale in general cases, it is necessary to identify – for each communication and before it actually takes place – which entities require IPsec and what their policies are regarding it: SPS was designed to offer a comprehensive answer to this question.

3 Overview of the Security Policy System A security domain is a set of communicating entities and resources that share a common security policy set, enforced at one or more enforcement points. Briefly, the goal of SPS is to provide mechanisms for discovering, accessing and processing security policy information of hosts and networks of a security domain. The five basic components of the SPS are shown in Figure 1. Each security domain maintains a master file that uniquely defines the security domain by its resources (hosts and networks) and the policies to access them. Local policy information combined with non-local policies form the SPS database. A domain’s SPS database is maintained by the policy server authoritative for the domain. The non-local policy information loaded into this database is received through SPS exchanges. Policy Servers (PS) receive request messages from policy clients and other policy servers, process them, and provide the appropriate policy information to the requester based on access control rules. Policy

clients generate policy information requests and transform the replies into the appropriate format for the applications that use SPS. Policy servers and clients use the Security Policy Protocol (SPP) [4] to exchange policy information. This protocol provides hosts with the policy information needed to establish SAs with security gateways in the communication path to other hosts, without requiring a-priori knowledge of the identities of the security gateways. A policy transferred by SPP consists of a record to describe the selectors of the communication (the COMSEC record) and zero or more SA records which describe the security associations required to complete the communication. SPP messages are authenticated either by using IPsec or another security mechanism. SPP describes a security mechanism based on digital signatures that can be used to provide authentication and integrity to its messages. The SPP authentication is especially useful when traversing heterogeneous domains and the identity of the policy server authoritative for the destination is unknown. It is out of our scope to describe in detail the SPP. We present here only some of its formats to support the subsequent discussion. The header of SPP messages contains fields identifying the message, the type of message, the status of the message, the number of queries and/or record payloads carried by the message, and the identity of the host

requesting policy information. The message types currently defined are summarized in the following table. message Query Reply Policy Policy Ack Transfer Keep Alive

description request for policy info policy records that answer a query policy up/download-ed to/from a PS acknowledges a policy message bulk policy exchanges between PSs PS informs SGs of its status

There are three payload types defined in SPP: Query, Record, and Signature payloads. When present, the signature is computed over the entire SPP message, including the SPP header. The SPP specification also describes a certificate fetching mechanism for entities that choose to use it as an alternative to other certificate distribution mechanisms.

4 SPS Critical Issues Since SPS provides the policies enforced at security domains’ borders, its intrinsic security is fundamental for the protection of the entire domain. Successful attacks against SPS components might compromise the overall security of the policy-based network.

4.1 SPS intrinsic security The implementation of a policy infrastructure must be secure as far as the following aspects are concerned. First, the mechanisms proposed must minimize security risks and denial of service threats. Security risks in this context may be unauthorized access to read or change policy rules and related objects in the policy repository. The SPS document does not detail security requirements for storage of the IPsec policy repository. Second, it must be ensured that the entities involved in policy-based management can verify each other’s identity and establish necessary trust before communicating. The authentication method is not imposed, but use of the SPP signature payload or of IPsec is suggested.

4.2 Policy storage issues An aspect that can have negative effects on the SPS reliability in operation is the consistency of the policy information inside a security domain. There are several places where the policy information can be found inside a security domain: the domain’s master file, the SPS database maintained by the domain’s policy server and the SPDs of the nodes that are part of the domain. The SPS documents do not indicate a method for maintaining the coherency of the information stored in all these databases. Moreover, they are rather evasive on the roles

of the policy server and clients: the policy server maintains the policy database for the entire domain, both server and clients are allowed to maintain cache policy databases, and additionally, each client has its own IPsec SPD, which acts like a local policy database. The general policy framework working group states in [5] that the right approach to be followed in a policy-based networking environment is “centralized storage, distributed control”. However, for SPS this principle is not straightforward to implement, since it provides mechanisms and special message types for authorized clients to announce new policies to servers. There are three possible approaches for policy storage inside a security domain:

 centralized: the policy server controls everything, therefore the potential policy changes on a particular host are made by modifying the server’s database, and then downloading the policy on the client. The policy clients always contact the server and obtain the updated policies.  distributed: nodes are permitted to define their own policies and to upload them to the server using SPP policy messages; the server then updates its database in order to correctly respond to external queries. This may be a better approach because it is consistent with the SPS philosophy, though less secure (the degree of security lowers as the numbers of responsible entities increases).  combined: only certain hosts of a security domain are allowed to dictate their own policies. In this case we may exploit the definition of security domain (which can be as small as a single node enforcing its own policies), and define these nodes as being authoritative for themselves. When the domain’s policy server receives a query for such a node, it will forward the query to the node itself. All these approaches are supported by SPS, and maybe this provides too much flexibility and leaves room for configuration and management errors. We strongly suggest to carefully weigh the pros and cons, and to stick with the simplest model that fits the security needs of a domain.

4.3 SPS authorization Authorization is at the heart of any system dealing with security policies because they are practically applied by issuing appropriate authorization commands (or setting adequate access rules) on the security gateways. SPS has to deal with authorization for communications originating inside the security domain (outbound traffic), and outside the security domain (inbound traffic).

4.4 Authorization for outbound traffic Policy servers provide the appropriate policy information to the requester based on access control rules. The SPP message processing specifies that upon receiving a query, policy, or transfer message, if SPP access control is enabled, then a policy server has to verify if the message is allowed. The verification is based on the “Sender Identity” field in the SPP header. This field can contain two types of identities: IP addresses or host names. Supporting this limited set of identity types seems a rather restrictive choice to us. The policy client’s identity is tied to the host identity, while it may be required to express more detailed identity information fot authorization purposes. On the other hand, if we consider that the policies are enforced by the domain’s security gateways (which may have firewall functionalities too), there definitely exists the need to express policy rules in terms of user identity, or even user@host. A possible approach is to add a new optional field to the SPP header specifying the entity requesting the policy, in other words the entity which requests permission to traverse the security domain enforcement point. The new field may have the same structure as the Identity field in the certificate record in [4]. This field can then be used for authorization purposes when the Sender Identity field is not enough. The Sender Identity field must be left unchanged, since it is currently used in the chain-of-trust mechanism (see section 4.7). Providing additional sender identity information in the SPP header allows a more refined access control, which permits more complex authorization mechanisms to be derived instead of simple access control lists. An appropriate authorization scheme could be based on Attribute Certificates (AC) as described in [6]. In conjunction to authentication services, Attribute Certificates provide a way to transport authorization information securely to applications. For providing authorization inside a security domain, the “pull” model described in [6] scales well: the policy client simply authenticates to the server (by means of digitally signing its query), then the server requests the client AC from a repository or from the domain’s AC issuer. The identity of the client is contained in the Sender Role field inside the SPP header. The “entityName” field in the AC must have the same type and value as the Sender Role information. In order for the proposed scheme to become functional, there is one inconvenient: the need to set up a Public Key Infrastructure or to adhere to an existing one. On the other hand, taking part into a PKI is anyway a requirement for a compliant SPP implementation; the additional work for supporting Attribute Certificates can be done in parallel. IPsec has been charged with lack of user level authentication and authorization [7]. We dare to say that by using an authorization mechanism based on Attribute Certificates in

conjunction with an additional field in the SPP header to refine the sender identity information, IPsec protection could be extended to the user level.

4.5 Authorization for inbound traffic Providing authorization for the communications originating outside the security domain requires a different approach. The SPP policy query may arrive either from a completely unknown entity, or from a local user temporary outside the limits of the security domain (the classical remote access case). In the first scenario the SPP query is intercepted by the security gateway at the entrance of the security domain and passed to the domain policy server. The server verifies if it can accept policy queries from the sender, and if the message contains the right authentication data. After that, the server responds with the appropriate local policy, and configures the security gateway for the subsequent communication. An objection to this mechanism is that the SPP message which triggers it may not have been signed by the originating policy server: SPP messages are verified and re-signed by every policy server in the message path if the server has policies set up for the requested communication. This is the trust model proposed for SPP. In fact, this model is the only appropriate one, with respect to the distributed nature of SPS architecture and its declared purposes. The second scenario is far more interesting since, in our vision, offers the opportunity to solve the IPsec remote access problem. Currently, there is a large amount of standardization work done in the area of secure remote access based on IPsec [8, 9, 10]. All these proposals bring important changes to the IKE negotiation procedure, making it more complex than it already is (see the analisys in [11]). In our opinion the SPS architecture combined with an ACbased authorization mechanism could offer an elegant solution to this problem.

4.6 IPsec authentication for SPP IPsec is one of the recommended mechanisms for the authentication of SPP exchanges. [4] states that the SPP messages must be authenticated either using IPsec or another security mechanism, but does not detail how IPsec should be used for achieving this goal. If we want to use IPsec for SPP authentication, we find ourselves in front of the classical chicken-and-egg problem. In a policy-based networking environment, IPsec completely relies on SPS for the policy provisioning. But the hypothesis is that, SPS uses IPsec for authentication. Let us consider a simple case where SPS is deployed (see Figure 2): there are only two security domains involved, therefore only two security gateways lie in the path from

security domain SD2

security domain SD1

Internet

PS1

Q2 Q1 H1

PS2

Q2

R1

Q2 SG1

SG2

H2

R1

R2

Figure 2. Test case for SPP protected by IPsec.

H1 to H2. For clarity, we split the path in three parts: those inside the source and destination security domains, and the Internet part. For simplicity we do not consider any security gateway that might exist in the Internet part. While inside the security domains, the SPP traffic can be easily offered IPsec protection. A plausible approach is to use IPsec AH SAs between the policy clients and the policy server, and between the latter and the security gateways. Coming back to Figure 2, the IPsec SAs between H1 and PS1, and between PS1 and SG1 protect SPP query messages Q1 and Q2 inside the source security domain. If we consider the most general case, PS1 does not know about the existence of PS2, so it sends Q2 directly to H2. SG1 has to forward Q2 to H2, and does not have an appropriate SA for protecting it. To solve this problem SG1 can start an IKE negotiation with H2. This will most probably fail at SG2. The IKE messages can be silently discarded or, hopefully, SG1 will receive an error message from SG2. SG1 can now try to start a direct IKE negotiation with SG2, if it is permitted by the its policy. Alternatively, SG1 can send a “security gateway query” to H2 to find out which security gateways are in the path. Obviously this message cannot be protected with IPsec, otherwise the previous situation would repeat. SG1 has to send the message without authentication, and, even worse, it has to trust a possible non-authenticated answer from an entity which intercepted the query and declares to be PS2. In the most optimistic case, SG2 accepts to trust the sender identity it sees in the SPP header, and proceeds in one of the following ways:

 sends back to SG1 the expected answer without authentication. SG1 can now start an IKE negotiation with SG2 for establishing the SA needed to authenticate subsequent SPP traffic between the two security domains.  asks its policy server for the policy governing the communications with SD1, then starts an IKE negotiation with SG1. This negotiation will establish the SA needed to authenticate subsequent SPP traffic between the domains.  SG2 sends back an authenticated SPP message with an error code. SG1 learns the SG2 identity from the SPP header, chooses to trust this information, and starts the negotiation for the IPsec SA. The case is even worse if the communication path has to traverse multiple security domains. The huge overhead introduced by the negotiation and establishment of IPsec SAs between all the security gateways involved makes IPsec protection unsuitable for use with SPP. Moreover, we cannot ignore that IPsec offers a somehow limited protection for a protocol like SPP, and might be easily considered not strong enough. Whatever the scenario imagined for deploying IPsec in the given example, there will always be an initial amount of unprotected SPP traffic. Some security domains might consider this an unacceptable security risk. In conclusion, IPsec protection for SPP can be suitable at most for messages that travel inside a security domain, or when some trust relationships already exists between communicating security domains. In general cases, we think

security domain SD2

security domain SD1

security domain SD3 PS1

PS2

SG1 R3

PS3

Q3

Q2

Q1 H1

Internet

SG3

SG2 R2

H2

R1

Figure 3. Test case for SPS chain-of-trust.

that using IPsec for SPP authentication is a bad idea and should not be pursued in wide and open implementations.

4.7 SPS chain-of-trust A critical aspect of the SPP operation is the chain-oftrust mechanism. The message processing rules require that policy servers receiving Reply messages “cryptographically” validate the chain-of-trust reconstructed using the policy server records found in the message itself. Besides the policy server records, certificate records are present for all servers that added policy records to the Reply message. In spite of this, there is still no cryptographic proof to validate the chain of trust. The simple presence of the certificates records inside the message does not “cryptographically” prove anything. The only authentication data present in the message is the signature provided by the last server in the chain. The problem is: can this signature be considered appropriate for validating the chain-of-trust? Let us consider the case shown in Figure 3. The policies regarding the communication between the two end nodes H1 and H2 are summarized in the table bellow: entity H1 PS1 PS2 PS3 H2

policy ESP Transport SA with H2 ESP Tunnel SA between SG1 and SG2 ESP Tunnel SA between SG1 and SG2 ESP Tunnel SA between SG3 and H1 ESP Transport SA with H1

Prior to communication, H1 sends an SPP Query to PS1 for finding out the policies that are enforced in the path to H2.

Let us examine in more detail the content of the Reply message received by PS1. Apart from the signature payload, this message includes:

 the SPP header: the sender identity field contains the IP address of PS2.  the original Query payload: contains a COMSEC record with the description of the requested communication.  three record payloads containing SA records which describe the three SA to be established for the communication (the ESP tunnel between SG1 and SG2, the tunnel between H1 and SG3, and the end-to-end ESP transport).  two record payloads of the type “policy server”: the first states that PS3 is authoritative for H2, while the second states that PS2 is authoritative for PS3. For verifying that it has received a response from a server authoritative for the destination (H2), PS1 uses the policy server records to construct a chain of hosts from the destination host to this server. Since PS2 is authoritative for PS3, which is authoritative for the destination H2, PS1 can trust the policy information received in the reply. The information in the message (including the chain-of-trust) is authenticated with the PS2 signature. Each policy server in the path has to validate the chain-of-trust, and to verify and re-calculate the message signature. The last server has to know/trust only the public key of its closest server. The only “cryptographic” validation of the chain-of-trust is

the validation of the entire message signature. The successful signature verification made by means of the public key of the closest server in the path, implies that the verifying server trusts all the signature validations made along the reconstructed chain-of-trust, and confers authenticity to the chain-of-trust. In other words, there is no origin authentication and we must always trust the closest policy server to have correctly performed all the verifications. This is a point that raises strong security concerns (do we trust all the servers along the path to the destination?), and that can limit applicability of SPS in open networks.

4.8 Complexity Complexity is a critical issue for any protocol implementation. It is demonstrated that excessive complexity has disastrous effects on a protocol reliable operation, and especially on the security features offered by the protocol [11]. The SPS complexity is mainly due to the chain-of-trust and the authentication mechanisms. In spite of its complexity, we state that the SPS approach is the only appropriate one for IPsec. There currently exists some standardization work done by the RSVP Admission Policy (RAP) working group, which defines COPS (Common Open Policy Service) extensions for VPN connectivity [12]. COPS [13] describes a simple client-server model for supporting policy control over QoS signaling protocols. Even if COPS defines an architecture similar to that of SPS, it does not address all the specific security policy requirements. Practically COPS lacks support for the communications between policy servers. The various security domains do not exchange information with COPS, while for SPS this is the core part of the policy discovery mechanism.

5 Conclusions Conceptually SPS responds to all requirements in [14], but it is not clear if policy conflict resolution is supported too. This is somewhat connected to a critical issue that we have already mentioned: SPS is too flexible a mechanism in some aspects, and this can result in confusion about the roles of the various entities. The need for authorization, which is a common request in today’s Internet, has generated the need for representing, discovering, exchanging, and managing the policies that control access to network resources in a scalable, secure and reliable manner. The goal of SPS is, without doubt, a very ambitious one. Nevertheless, we think that SPS can offer a viable uniform mechanism for security policy provisioning, and can be further extended to cover other security protocols besides IPsec. Our future work is focused on defining such an extension for making SPS suitable for use with application and transport layer security protocols.

References [1] L.A. Sanchez, M.N. Condell, Security Policy System, Internet Draft, November 1998 [2] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998 [3] D. Harkins, D. Carrel, The Internet Key Exchange, RFC 2409, November 1998 [4] L.A. Sanchez, M.N. Condell, Security Policy Protocol, Internet Draft, July 1999 [5] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, Policy Framework, Internet Draft September 1999 [6] S. Farrell, R. Housley An Internet AttributeCertificate Profile for Authorization, Internet Draft, October 1999 [7] Scott Kelly, Jim Knowles, Bernard Adoba, User-level Authentication Mechanisms for IPsec, Internet Draft, October 1999 [8] Y. Dayan, S. Bitan, IKE Base Mode, Internet Draft, January 2000 [9] R. Pereira, The ISAKMP Configuration Method, Internet Draft, 1999 [10] Baiju Patel, Bernard Adoba, Scott Kelly, Vipul Gupta, DHCP Configuration of IPsec Tunnel Mode, Internet Draft, 2000 [11] Niels Ferguson, Bruce Schneier, A Cryptographic Evaluation of IPsec, Counterpane Internet Security, Inc., 2000, http://www.counterpane.com. [12] M. MacRae, S. Ayandeh, Using COPS for VPN Connectivity, Internet Draft, February 1999 [13] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. Sastry, The COPS Protocol, Internet Draft, November 1999 [14] P. Srisuresh, L.A. Sanchez, Policy Framework for IP Security, Internet Draft, February 1999