Patent Application
20150058913
The present disclosure relates to establishing secure Internet Protocol Security (IPsec) sessions, and to allowing such sessions to be context aware during first negotiation.
In cloud-based environments, resources are frequently shared between multiple clients, creating a multi-tenant environment. As each client has the capacity to create and establish one or more security policies for negotiating access into cloud-based environments, it is important to ensure that individual policies are respected, and in particular, that conflicts between policies do not occur.
During establishment of an IPsec session, an initiator and a responder exchange a series of messages in order to negotiate selection of various security parameters and perform authentication. In protocols such as Internet Key Exchange (IKE) or Internet Key Exchange version 2 (IKEv2), security parameters are selected during first exchange of messages. However, the identity of the initiator is not known by the responder during this first exchange, and therefore, the proper security policy may not be selected by the responder.
Techniques are presented for establishing context awareness during first negotiation of secure key exchange. These techniques may be embodied as a method, apparatus or instructions in a computer-readable storage media. At a first network device, a message is received from a second network device as part of an initial exchange of information of a secure key exchange, the message containing information indicating one or more secure key exchange policies acceptable to the second network device and defining one or more associated security parameters. The message further contains context-specific information identifying a context of the second network device. The first network device selects a secure key exchange policy for communicating with the second network device based upon the context-specific information and sends a response message to the second network device as part of the initial exchange of information of the secure key exchange. The response message contains the selected secure key exchange policy, and if the context was understood, the response message also includes context-specific information.
IPsec is a protocol suite for securing (Internet Protocol) IP communications by encrypting IP packets of a data stream. IPsec uses the IKE/IKEv2 protocol to set up a security association by handling negotiation of protocols and algorithms used to generate encryption and authentication keys for IPsec communications. IPsec uses the Encapsulating Security Payload (ESP) protocol to provide authentication and confidentiality for IP packets. Thus, IPsec can be used to secure upper layer communications, e.g., user datagram protocol (UDP) over IPsec, or Transport Control Protocol (TCP) over IPsec, and application-to-application communications like Java Message Service.
Cloud Service Providers (CSPs) providing Virtual Private Networks (VPNs) as a service may share infrastructure among two or more clients, and provide Web Application Programming Interfaces (APIs) that enable clients to define their own IKE Proposal/Policy on IKE endpoints.
With regard to typical IKE/IKEv2 protocols, neither the initiator nor the responder is aware of the multi-tenancy nature of the environment, and therefore, a policy created by client A 130 may conflict with a policy created by client B 140, thereby impacting the characteristics of IKE sessions for each client. For example, client A 130 may opt for cipher Advanced Encryption Standard 256 (AES256) and client B 140 may opt for Triple Data Encryption Standard (3DES or Triple DES); however, during establishment of an IKE session for client A 130, 3DES may be selected by a responder.
As previously discussed, although the IKE/IKEv2 protocol has provisions for exchanging identity, identity exchange does not occur during the first exchange (denoted IKE_SA_INIT).
Instead, identity exchange occurs during a subsequent exchange of messages, i.e., during security association-authentication (denoted IKE_SA_AUTH), after selection of certain security parameters, such as a cryptographic algorithm, has already occurred. In other words, selection of a cryptographic algorithm occurs during IKE_SA_INIT, prior to identity exchange.
In a multi-tenant environment, different policies may be established for different tenants based upon a variety of context associated-information, such as corporate identity, geographic location, and application. Accordingly, it is important to provide a mechanism to enable a particular tenant or client to be authenticated with their proper established policy, and ensure that conflicts or overlaps do not occur with other tenants that have access to different resources and different established policies. Because the IKE/IKEv2 protocol does not have the ability to enforce proposal/policy validation during initial exchange of information (IKE_SA_INIT), a modification/extension is proposed as part of a secure key exchange, which adds context-specific data to information provided to a responder as part of an incoming negotiation. This modification ensures that, as negotiation proceeds, the responder is aware of the allowable policies for a particular tenant, and a correct policy is chosen as part of the negotiation process. Thus, adding context awareness to the protocol ensures that client-specific policies, location-specific policies, or application-specific policies can be enforced during initial exchange of information (IKE_SA_INIT).
IKE and IKEv2 protocols are described in, e.g., Request for Comments RFC2409 and RFC5996.
As seen from
An IKE proposal is a set of algorithms that two peers (e.g., an initiator and a responder) may use to establish a secure connection. IKE negotiation begins with each peer agreeing upon a common (shared) IKE policy. This policy states which security parameters will be used to establish a secure channel.
To define an IKE proposal, an encryption method for IKE negotiation is specified to protect data and ensure privacy; a Diffie-Hellman group is specified to determine the strength of the encryption-key-determination algorithm as well as to derive encryption and hash keys. An authentication method is used to ensure the identity of the peers.
As discussed previously, IKE performs mutual authentication between two parties and establishes an IKE security association. During IKE/IKEv2 communication, an initiator sends a message to a responder, and the responder evaluates the request and sends a response to the initiator. This pair of messages, the request and the response, is collectively known as an “exchange”. The first exchange is referred to as IKE_SA_INIT and the second exchange is referred to as IKE_SA_AUTH. The second set of exchanges contains a pair of messages, a request and a response, to complete authentication (IKE_SA_AUTH). During this step, client identities are exchanged, peer authentication is performed, and a security association is set up. A modified IKE_SA_INIT exchange is discussed in more detail below.
According to the techniques presented herein, the initial exchange of messages during IKE_SA_INIT is modified to allow the responder to become context aware during first negotiation. During the first exchange of a modified IKE session (modified IKE_SA_INIT), security parameter negotiation occurs. Referring to
As shown in
As shown by this exchange, security parameters are negotiated during IKE_SA_INIT, one of which is a particular cryptographic algorithm. Modification of the IKE_SA_INIT to include a context-specific parameter CTX provides visibility regarding the identity of the client, at the responder end, during the initial negotiation phase. Therefore, in a multi-tenant environment, in which different protocols have been established by different clients, the responder will have the capability during IKE_SA_INIT to identify the client or the particular requirements of the client, and to ensure that negotiation proceeds according to the policies established by the client.
In one approach, when IKE negotiation begins, the second network device that initiates the negotiation may send one or more acceptable policies to the first network device (usually peer-to-peer), and the first network device searches for a match with its own policies. The policies of the second network device may be provided in priority order, to indicate preferred policies. As an example of a compatible security policy between an initiator and a responder, both policies would have the same encryption, hash, authentication, and Diffie-Hellman parameter values. If a match is not found, negotiation is typically refused and an IKE secure association is not established.
Different encryption algorithms include Data Encryption Standard (DES), a symmetric secret-key block algorithm; 3DES or Triple DES, an algorithm that processes each block of data using DES three times, each time with a different key; and AES, an algorithm that provides greater security than DES and is computationally more efficient than 3DES, as well as offers three different key strengths: 128-, 192- and 256-bit keys.
Importantly, the cryptographic suite chosen by the responder is determined by the CTXi provided in the IKE_SA_INIT message from the initiator. If the responder (e.g., gateway) is a shared resource (e.g., cloud environment with multiple tenants), the responder will select the cryptographic suite associated with the context-specific information CTXi provided from the initiator.
The context ID type and context ID payload data is unique to an initiator (e.g., client) and responder (e.g., gateway) that creates an IKE/IKEv2 proposal and policy on IKE/IKEv2 endpoints. When the responder processes the IKE_SA_INIT request, the responder evaluates the incoming request against the proposal/policy associated with the same context. When an IKE/IKEv2 request is initiated, the context ID payload data and context ID type are included in the IKE_SA_INIT request as a payload. When the responder processes the IKE_SA_INIT request, the responder evaluates the incoming request against the proposal/policy associated with the same context as that of the IKE_SA_INIT request. In particular, the context ID type and context ID payload data is part of a global IKE/IKEv2 policy which is applicable for all incoming requests. The context ID type and context ID payload data from the initiator is used to filter and select one or more appropriate IKE/IKEv2 policies on the responder. If the context is matched, IKE/IKEv2 policy as per context is selected and normal processing of IKE_SA_INIT continues, with acceptable context-specific information included as part of the context ID payload of the IKE_SA_INIT response. If the context is not matched on the responder as per configured policy, normal IKE/IKEv2 policy selection happens and context-specific information is not included in the IKE_SA_INIT response.
The responder has a set of rules to process context-specific information and to make decisions regarding selection of a security policy. Upon receipt of context-specific information from the initiator, the responder will store the context-specific information, and apply a set of rules to match the context of the received information with an appropriate policy of the responder, ensuring that an acceptable policy is selected. In another approach, the context-specific information may be used to filter a group of secure key exchange policies of the responder into a subset of policies, which all may be acceptable to the initiator.
Prior to first exchange of messages, the responder may also be pre-configured with context-specific information, including one or more of the following: location of initiator, location of responder, customer name, customer ID, application name and application ID. The pre-configured information stored at the responder may be used in matching the context of the received information from the initiator with one or more appropriate policies of the responder.
This modification of the IKE protocol ensures isolation between configurations for different tenants. Upon receiving a request with context-specific information, the responder stores this information, and therefore, is now aware that a policy needs to be selected based upon the provided context-specific information.
If the responder understands the context-specific information provided by the initiator, the same context-specific information is sent back to the initiator in the response message, as shown in
Importantly, in the event that the responder does not understand the context-specific information (e.g., is not capable of processing context-specific information, is unaware of the context-specific information, or is unable to find a matching context), context-specific information will not be included in the reply. Importantly, the absence of context-specific information in the response indicates to the initiator that the context was not understood. The initiator may choose to proceed further with the negotiation, or alternatively, may send out a teardown message to release reserved resources involved in establishing a secure session. If the context is not understood, the responder (e.g., gateway) may select a secure key exchange policy, and the initiator (e.g., client) determines whether to drop the connection or accept the policy and proceed with authentication. Thus, by including context-specific information in the response message from the first network device to the second network device, an indication is provided that the selected secure key exchange policy was selected in view of the context-specific information provided by the initiator.
As shown in
As another example, it may be desirable to employ particular ciphers (e.g., with increasing strength) when accessing resources from a particular geographic location (e.g., a particular country). Application Programming Interfaces (APIs) may allow a client to establish multiple globally accessible policies for a particular client. By including context-specific information, the ability to determine a particular context for a client is realized, and the responder has the ability to select a proper policy.
The examples presented herein are not intended to be limited to a particular type of context information, but include, any type of context information which would assist with determination of one or more secure key exchange policies for a particular client in a multi-tenant environment.
Advantages of the techniques presented herein include inter-operability, that is, being able to exchange and utilize information. Additionally, the techniques presented herein are scalable/extendable to networks with different types of topologies and sizes. Also, the techniques presented herein do not leverage mechanisms involving modifications of routing domains, which may involve time consuming and costly configurations.
Memory 530 is one or more computer readable storage media that may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. Processor 520 is, for example, a microprocessor or microcontroller that executes instructions for the secure key exchange and policy selection logic 532. Thus, in general, the memory 530 may comprise one or more tangible computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the processor 520) it is operable to perform the operations described herein in connection with secure key exchange and policy selection logic 532. In other approaches, proposed policies and context-specific information 534 from the initiator as well as supported policies and context based policy selection rules 536 from the responder are stored in one or more databases accessible by processor 520.
Additionally, the techniques presented herein may be applied to a Managed Service Provider (MSP) environment. A MSP environment may have a distributed architecture with multiple modules (line cards), with each module serving one customer (e.g., all Company A employees or all Company B employees). In such scenarios, context awareness may be used to direct an incoming session to the line card configured for the customer.
In summary, a multi-tenant cloud environment, it is important to ensure that policies configured by different customers do not influence each other. While IKE/IKEv2 protocols have provisions for exchanging identity, this exchange of information does not occur during first exchange of messages, at which time certain security parameters are selected. Hence, the IKE/IKEv2 protocol does not have the ability to enforce proposal/policy validation during first exchange of messages. The techniques described herein add context awareness through modification of the IKE/IKEv2 protocol to allow client-specific policies to be enforced during the initiation phase.
Although the apparatus, system, and method are illustrated and described herein as embodied in one or more specific examples, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made therein without departing from the scope of the apparatus, system, and method and within the scope and range of equivalents of the claims. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the apparatus, system, and method, as set forth in the following claims.
The above description is intended by way of example only. Various modifications and structural changes may be made therein without departing from the scope of the concepts described herein and within the scope and range of equivalents of the claims.
