Automated Ikev2 Authentication to Gp Gateway Using Session Auth Cookie

Internet Key Exchange version 2 (IKEv2) is widely used as a protocol for negotiating and establishing secure communication channels, especially in virtual private networks (VPNs) and enterprise network environments. However, traditional implementations rely heavily on fixed credentials or static cryptographic keys, which can become points of vulnerability if compromised. Additionally, session management in many existing systems is insecure, potentially allowing unauthorized access through stolen or replayed credentials.

The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

As used herein, a security entity may be a network node (e.g., a device) that enforces one or more security policies with respect to information such as network traffic, files, etc. As an example, a security entity may be a firewall. As another example, a security entity may be implemented as a router, a switch, a DNS resolver, a computer, a tablet, a laptop, a smartphone, etc. Various other devices may be implemented as a security entity. As another example, a security entity may be implemented as an application running on a device, such as an anti-malware application.

Session management in many existing systems does not adequately ensure that authentication mechanisms are tied to specific sessions, potentially allowing unauthorized access through stolen or replayed credentials. To overcome these limitations, various embodiments implement dynamic key generation and session-specific authentication, creating a highly resilient authentication framework.

Various embodiments provide a system and method for securing network access through an enhanced Internet Key Exchange Version 2 (IKEv2) authentication mechanism. In modern enterprise networks, safeguarding sensitive resources and assets is paramount as organizations face increasingly sophisticated cyber threats. Conventional authentication methods, while effective in certain scenarios, often fall short of addressing advanced security challenges such as session-specific credential validation, cryptographic robustness, and resistance to unauthorized access attempts. The techniques and/or mechanisms described herein address these challenges by introducing a system that combines the use of a pre-shared key (PSK) and a session authentication cookie to establish a more secure and reliable IKEv2 authentication process.

In some embodiments, the system leverages a PSK that is generated dynamically for each session, ensuring that encryption keys remain unique and valid only within the context of a specific session. The system also integrates a session authentication cookie, which is a unique identifier assigned to an endpoint upon successful login using valid user credentials. The session authentication cookie is securely transmitted to the endpoint and associated with the session, enabling the system to validate authentication requests in a manner that is both session-aware and resistant to replay attacks. This dual-layered approach enhances security by requiring endpoints to present both the encrypted payload and a valid session cookie during authentication.

Various embodiments address the needs of enterprises that demand robust security solutions for protecting their networks and resources. The system ensures that access is granted only to authenticated and authorized endpoints while maintaining the flexibility and scalability required for dynamic and high-volume network environments. By dynamically generating cryptographic keys and tying authentication to session-specific cookies, the system can provide an advanced solution to the challenges of securing enterprise networks against evolving threats. Additionally, the system's design is compatible with existing IKEv2 protocols, making it a versatile enhancement for both current and future network security architectures.

In previous implementations of IKEv2 authentication, the authentication process typically relied on pre-shared keys (PSKs) or digital certificates to authenticate endpoints. For systems using PSKs, the administrator manually created or configured the PSK, which was then shared between the endpoints and the authentication system. This PSK served as the foundation for encrypting and validating communication, ensuring that only parties with the correct PSK could establish secure connections. While conceptually straightforward, this traditional approach introduced significant security vulnerabilities, particularly in the generation, distribution, and management of PSKs.

The process of generating PSKs in prior systems was often susceptible to human error or poor security practices. Administrators tasked with creating PSKs frequently relied on simple, predictable passphrases or passwords that were easy to remember but inherently insecure. Commonly used passwords or easily guessable phrases made these PSKs vulnerable to brute force or dictionary attacks, where malicious actors attempt to gain access by systematically guessing potential keys. This weakness was exacerbated in environments where security training or awareness among administrators was insufficient, leading to the widespread use of weak or repeated keys across multiple endpoints.

Another critical vulnerability in traditional IKEv2 authentication arose from the insecure distribution of PSKs. Administrators often shared the keys with users or endpoints through insecure communication channels such as email, text messages, or printed documents. These methods provided potential interception points for attackers who could eavesdrop on the communication or obtain the PSK through physical or digital means. Once compromised, a PSK allowed unauthorized access to network resources, often without detection, as there were no mechanisms to tie the key to a specific session or endpoint. Furthermore, static PSKs, once distributed, remained valid indefinitely unless manually updated, increasing the likelihood of misuse if an endpoint was lost or compromised.

The lack of session-specific authentication in related art systems further compounded the security challenges in traditional systems. A single PSK could be reused across multiple sessions or endpoints, making it difficult to track or isolate individual connections. This opened the door to replay attacks, where an attacker could use a previously captured PSK to gain unauthorized access without needing to know additional session details. The absence of a robust mechanism for revoking or renewing compromised keys in a timely manner further undermined the overall security of the system.

Overall, these vulnerabilities in related art authentication systems (e.g., other IKEv2 authentication systems) highlight the critical need for a more secure and dynamic approach to key management and authentication.

Various embodiments relate to an advanced system designed to enhance the security and efficiency of IKEv2 authentication processes. The system employs a combination of a PSK and a session authentication cookie to authenticate an endpoint seeking access to a network or its resources. The system ensures that only authorized endpoints are granted access by validating critical elements within the authentication request, thereby bolstering the security framework of enterprise networks.

In some embodiments, the authentication process begins when the system receives an IKEv2 authentication request from an endpoint. The authentication request contains a payload encrypted using a PSK. As an example, the payload comprised int eh authentication request comprises the session authentication cookie. In some embodiments, on the server side, the system utilizes a securely stored PSK to decrypt the payload. In some embodiments, on the server side, the system utilizes a PSK to decrypt the payload, where the PSK is obtained based at least in part on securely stored PSK information (e.g., a master key, a cryptographic salt, etc.). For example, the PSK is generated (e.g., re-generated) based on the PSK information. Upon successful decryption, the system extracts a session authentication cookie from the payload. The extracted cookie is validated by comparing it with a server-stored session authentication cookie associated with the endpoint or a specific session between the endpoint and the system. The validation process includes ensuring that the session authentication cookie is unexpired and matches the stored reference. If both the PSK decryption and cookie validation are successful, the endpoint is authenticated, and the system grants access to the requested network resources or assets. Otherwise, the authentication attempt fails, preventing unauthorized access.

In some embodiments, the session authentication cookie plays an important role for authentication of an endpoint in this system. The session authentication cookie is initially assigned to an endpoint during a login process. Upon receiving and validating the endpoint's login credentials (e.g., a username and password/passcode, etc.), the system generates and assigns a session-specific authentication cookie. This session authentication cookie is securely stored on the server side and shared with the endpoint as part of the login response, for example, over a secure connection. The session authentication cookie is unique to a particular session and is regenerated whenever a new session is initiated by the endpoint. This ensures that each session is uniquely identifiable and secure.

The PSK is another important component of the authentication mechanism. The PSK is dynamically generated by the system in response to a configuration request (e.g., a getconfig request) from the endpoint. The system creates the PSK using a master key and salt, providing it securely to the endpoint within the configuration response. When the endpoint initiates IKEv2 authentication, it utilizes the PSK to encrypt the payload that includes the session authentication cookie. This multi-layered approach (e.g., combining dynamic PSK generation with session-specific authentication cookies) enhances the robustness and security of the authentication process.

In some embodiments, the system is implemented through one or more servers acting as security gateways for enterprise networks. These servers can safeguard access to enterprise resources by strictly authenticating endpoints based on the techniques described herein.

1 FIG. 2 11 FIGS.- 100 200 1100 is a block diagram of an environment for providing a security service to a network according to various embodiments. In some embodiments, systemimplements at one or more of processes-of.

104 108 110 102 104 106 110 118 102 110 In the example shown, client devices-are a laptop computer, a desktop computer, and a tablet (respectively) present in an enterprise network(belonging to the “Acme Company”). Data applianceis configured to enforce policies (e.g., a security policy, a network traffic handling policy, etc.) regarding communications between client devices, such as client devicesand, and nodes outside of enterprise network(e.g., reachable via external network). Examples of such policies include policies governing traffic shaping, quality of service, and routing of traffic. Other examples of policies include security policies such as ones requiring the scanning for threats in incoming (and/or outgoing) email attachments, website content, inputs to application portals (e.g., web interfaces), files exchanged through instant messaging programs, and/or other file transfers. Other examples of policies include security policies (or other traffic monitoring policies) that selectively blocking or sinkholing traffic, such as traffic to malicious domains, DNS hijacked domains, stockpiled domains, or squatting domains, or such as traffic for certain applications (e.g., SaaS applications). In some embodiments, data applianceis also configured to enforce policies with respect to traffic that stays within (or from coming into) enterprise network.

100 140 180 184 140 104 108 180 Systemcomprises a security platformthat can provide security services for network resources, such as enterprise assets and/or software-as-a-service (SaaS) applications. For example, security platformcan perform authentication services for authentication of endpoints, such as client devices-, in connection with providing access to network resources.

1 FIG. 104 108 110 120 110 Techniques described herein can be used in conjunction with a variety of platforms (e.g., desktops, mobile devices, gaming platforms, embedded systems, etc.) and/or a variety of types of applications (e.g., Android .ask files, iOS applications, Windows PE files, Adobe Acrobat PDF files, Microsoft Windows PE installers, etc.). In the example environment shown in, client devices-are endpoints, such as a laptop computer, a desktop computer, and a tablet (respectively) present in an enterprise network. Client deviceis a laptop computer present outside of enterprise network.

102 140 140 180 102 Data appliancecan be configured to work in cooperation with remote security platform. Security platformcan provide a variety of services, including authenticating endpoints, providing secure access to network resources, resolving DNS queries, providing DNS resolving security services, classifying domains (e.g., predicting whether a domain is a malicious domain, etc.), classifying DNS response records (e.g., predicting whether a domain IP pair in a DNS response is a DNS hijacked record, etc.), classifying network traffic, classifying DNS traffic, providing a mapping of signatures to certain domains or DNS records (e.g., a DNS record for which a predicted likelihood that the record is a DNS hijacked record exceeds a predefined likelihood threshold, etc. a mapping of domains or DNS records to domain or DNS record data (e.g., domain certificates, pDNS data, active DNS data, WHOIS data, etc.), performing static and dynamic analysis on malware samples, monitoring new domains and new DNS records (e.g., detecting new domains for which a certificate is issued/generated), assessing maliciousness of domains, determining whether a DNS record associated with a traffic sample is (or is likely to be) a DNS hijacked record, detecting squatting domains, detecting a DNS cache poisoning attack (e.g., an attempt or a DNS cache entry stored based on an effective DNS cache poisoning attack), providing a list of signatures of known exploits (e.g., malicious input strings, malicious files, malicious domains, etc.) to data appliances, such as data applianceas part of a subscription, detecting exploits such as malicious input strings, malicious files, DNS hijacked records or malicious domains (e.g., an on-demand detection, or periodical-based updates to a mapping of domains or DNS records to indications of whether the domains or DNS records are malicious or benign), providing a likelihood that DNS traffic (e.g., a domain or DNS record comprised in the DNS traffic) is malicious or benign, providing/updating a whitelist of input strings, files, or domains deemed to be benign, providing/updating input strings, files, or domains deemed to be malicious, identifying malicious input strings, detecting malicious input strings, detecting malicious files, predicting whether input strings, files, DNS records, or domains are malicious, providing an indication that an input string, file, DNS record, or domain is malicious (or benign), etc.

102 102 180 In some embodiments, network security services, such as authentication services, are implemented at data appliance. As an example, data appliancecan authenticate endpoints for access to network resources. The authentication services may include performing IKEv2 authentication for the endpoints.

180 In some embodiments, network security services are implemented by one or more servers, such as a cloud service. Examples of the network security services include one or more of: (a) authenticating a login request from an endpoint, (b) obtaining (e.g., generating) session authentication cookies (e.g., in response to login authentications), (c) assigning session authentication cookies to endpoints (e.g., to endpoints for particular sessions between the endpoints and the enterprise network, (d) providing the session authentication cookies to endpoints (e.g., via a secure communication protocol), (e) obtaining (e.g., generating PSKs), (f) providing PSKs to endpoints, (g) performing IKEv2 authentication for endpoints, (h) decrypting IKEv2 authentication requests or payloads in the IKEv2 authentication requests (e.g., using a PSK assigned to the endpoint, (i) extracting a session authentication cookie from the IKEv2 authentication request (e.g., from a decrypted payload comprised in the IKEv2 authentication request), (j) validating the PSK used to encrypt the IKEv2 authentication (e.g., based on a successful encryption of the IKEv2 authentication), (i) validating the session authentication cookie comprised in the IKEv2 authentication request (e.g., based on comparing the session authentication cookie obtained from the IKEv2 authentication request with a server-side version of the session authentication request associated with the endpoint or session of the endpoint), (k) providing access to network resources, etc.

140 160 140 140 140 140 102 140 140 140 140 140 140 In various embodiments, results of analysis (and additional information pertaining to applications, domains, etc.), such as an analysis or classification performed by security platform, are stored in database. In various embodiments, security platformcomprises one or more dedicated commercially available hardware servers (e.g., having multi-core processor(s), 32G+of RAM, gigabit network interface adaptor(s), and hard drive(s)) running typical server-class operating systems (e.g., Linux). Security platformcan be implemented across a scalable infrastructure comprising multiple such servers, solid state drives, and/or other applicable high-performance hardware. Security platformcan comprise several distributed components, including components provided by one or more third parties. For example, portions or all of security platformcan be implemented using the Amazon Elastic Compute Cloud (EC2) and/or Amazon Simple Storage Service (S3). Further, as with data appliance, whenever security platformis referred to as performing a task, such as storing data or processing data, it is to be understood that a sub-component or multiple sub-components of security platform(whether individually or in cooperation with third party components) may cooperate to perform that task. As one example, security platformcan optionally perform static/dynamic analysis in cooperation with one or more virtual machine (VM) servers. An example of a virtual machine server is a physical machine comprising commercially available server-class hardware (e.g., a multi-core processor, 32+Gigabytes of RAM, and one or more Gigabit network interface adapters) that runs commercially available virtualization software, such as VMware Six, Citrix eServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, a virtual machine server may be under the control of the same entity that administers security platformbut may also be provided by a third party. As one example, the virtual machine server can rely on EC2, with the remaining portions of security platformprovided by dedicated hardware owned by and under the control of the operator of security platform.

140 138 170 140 According to various embodiments, security platformcomprises/implements network traffic classification serviceand/or gateway service. Security platformmay include various other services/modules, such as a malicious file detector, a malicious traffic detector, a parked domain detector, an application classifier or other traffic classifier, etc.

138 Network traffic classification serviceis used in connection with analyzing network traffic (e.g., websites, domains, sample files, etc. pertaining to the network traffic) and/or automatically detecting malicious network traffic.

170 180 170 180 170 170 170 170 180 182 184 Gateway serviceis used in connection with providing security services for a network and network resources. Gateway servicecan be implemented to perform IKEv2 authentication for endpoints, such as in connection with exposing network resourcesto endpoints connected to the network. In some embodiments, gateway serviceperforms an IKEv2 authentication to authenticate endpoints based at least in part on a session authentication cookie (e.g., assigned for a particular session between the endpoint and the system) and the PSK. Gateway servicecan manage the session authentication cookies and PSKs for authenticating endpoints, and provide the session authentication cookies and PSKs to the applicable endpoints via a secure connection. In response to receiving an IKEv2 authentication request, gateway servicecan use server-side versions of a session authentication cookie and a PSK to validate the versions of the session authentication cookie and PSK that were used in connection with generating the IKEv2 authentication request. In response to validating the versions of the session authentication cookie and PSK used in connection with generating the IKEv2 authentication request, gateway serviceauthenticates the endpoint and, for example, provides the endpoint with access to network resources(e.g., enterprise assetsand SaaS applications).

180 140 170 In connection with attempting to access certain secure resources, such as network resources, the endpoint performs an IKEv2 authentication with the system. The endpoint obtains the session authentication cookie (e.g., the locally stored session authentication cookie) and inserts it into a payload in an IKEv2 authentication request. The endpoint subsequently uses the PSK (e.g., the locally stored version of the PSK) to encrypt at least part of the IKEv2 authentication request, for example, the payload of the IKEv2 authentication request. The endpoint then sends the IKEv2 authentication request to the system (e.g., to security platform, or specifically, the gateway service).

170 In response to receiving the IKEv2 authentication request, the system (e.g., gateway service) determines the PSK associated with the endpoint, obtains the PSK (e.g., the server-side version of the PSK, for example, a PSK generated/re-generated at the server-side based on PSK information stored at the server-side), and uses the PSK to decrypt the IKEv2 authentication request (e.g., the session authentication cookie). In response to obtaining the decrypted payload of the IKEv2 authentication request, the system extracts a session authentication cookie and validates the extracted session authentication cookie (e.g., which had been locally stored at the endpoint) with the server-side version of the session authentication cookie. For example, the system determines whether the extracted session authentication cookie matches the server-side version of the session authentication cookie (e.g., is for the particular session between the endpoint and the system), and determines whether the extracted session authentication cookie is valid (e.g., unexpired).

170 172 174 176 178 In some embodiments, gateway servicecomprises one or more of login authentication service, session authentication cookie service, PSK management service, and/or IKEv2 authentication service.

170 170 170 Gateway serviceprovides security services for network resources, for example, by providing IKEv2 authentication of endpoints. In connection with providing such services, gateway servicecan perform login authentication for endpoints, manage session authentication cookies for sessions between the system (e.g., gateway service) and endpoints, manage PSKs for endpoints, and use the appropriate session authentication cookie and PSK to authenticate a received IKEv2 authentication request.

170 172 172 Gateway serviceuses login authentication serviceto authenticate a login request. Before seeking IKEv2 authentication an endpoint may log into the system using a set of credentials, for example, a username (or other identifier) and passcode (e.g., password, pin, alphanumeric string, etc.). Login authentication servicecan receive a login request from an endpoint and in response to receiving the login request, perform a login authentication (e.g., determine whether the passcode associated with the username is valid).

170 174 174 174 174 174 Gateway serviceuses session authentication cookie serviceto manage session authentication cookies. Session authentication cookie servicecan obtain (e.g., generate) a session authentication cookie in response to a successful login authentication (e.g., in connection with login to a gateway and a new session between the system and the applicable endpoint). In some embodiments, the session authentication cookie servicegenerates a random session authentication cookie for a particular session between a particular endpoint and the system. The session authentication cookie servicecan store the session authentication cookie (e.g., at the server-side/gateway-side) in association with the endpoint and/or the particular session. The session authentication cookie servicesends the session authentication cookie to the endpoint (e.g., for local storage), such as by a secure connection. In some embodiments, the system sends the session authentication cookie in connection with (e.g., comprised in) the login response for the login authentication request.

170 176 176 176 176 176 176 Gateway serviceuses PSK management serviceto manage PSKs. PSK management servicecan obtain (e.g., generate) a PSK in response to a getconfig request received from the endpoint. In some embodiments, the PSK management servicegenerates a PSK for a particular endpoint. For example, the PSK can be generated for a particular session between the endpoint and the system. In some embodiments, the PSK management servicecan store the PSK (e.g., at the server-side/gateway-side) in association with the endpoint and/or the particular session. In some embodiments, the PSK management servicecan store PSK information (e.g., at the server-side/gateway-side) in association with the endpoint and/or the particular session. At the server side, the PSK information (e.g., a master key, a cryptographic salt, etc.) can be used to generate (e.g., re-generate) the PSK. The PSK management servicesends the PSK to the endpoint (e.g., for local storage), such as by a secure connection in a getconfig response.

170 In some embodiments, the endpoint is required to be logged into the system (e.g., the login authentication with the gateway is successful) before performing an IKEv2 authentication with the system (e.g., the gateway, such as gateway service). When the endpoint attempts to perform an IKEv2 authentication, the endpoint uses the session authentication cookie and PSK, such as in connection with obtaining (e.g., generating) the IKEv2 authentication request. For example, the endpoint uses (e.g., inserts) the session authentication cookie as a payload for the IKEv2 authentication request and uses the PSK for encryption associated with the IKEv2 authentication request. The endpoint can encrypt the payload for the IKEv2 authentication request based at least in part on the PSK.

170 178 178 178 178 178 Gateway serviceuses IKEv2 authentication serviceto perform authentication of IKEv2 authentication requests received at the system/gateway such as from endpoints connected to the network. In some embodiments, IKEv2 authentication serviceperforms the authentication based at least in part on a session authentication cookie and a PSK. For example, IKEv2 authentication serviceuses the session authentication cookie stored at the server-side (e.g., the gateway-side) for the particular session to validate a session authentication cookie comprised in IKEv2 authentication service. IKEv2 authentication serviceperforms a lookup with respect to a mapping of endpoints (or sessions with endpoints) to session authentication cookie to obtain the appropriate session authentication cookie to use for the authentication.

178 178 178 178 178 178 178 178 178 178 In some embodiments, in response to receiving the IKEv2 authentication request, IKEv2 authentication servicedetermines the endpoint and/or session with which IKEv2 authentication request is associated. IKEv2 authentication servicecan obtain the appropriate PSK (e.g., the server-side/gateway-side stored PSK, re-generate the PSK based on PSK information such as a master key, cryptographic sale, etc.) to use in connection with the authentication. In some implementations, the IKEv2 authentication serviceperforms a lookup with respect to a mapping of endpoints (or sessions with endpoints) to PSKs to obtain the appropriate PSK to use for the authentication. In some implementations, the IKEv2 authentication serviceperforms a lookup with respect to a mapping of endpoints (or sessions with endpoints) to PSK information to obtain the appropriate PSK information that is to be used to regenerate the PSK to use for the authentication. IKEv2 authentication serviceuses the PSK for decrypting information comprised in IKEv2 authentication request, such as the payload comprised in IKEv2 authentication request. In response to successful decryption using the PSK, IKEv2 authentication servicecan deem the PSK used by the endpoint (e.g., to encrypt the payload) as being validated. IKEv2 authentication serviceobtains the decrypted payload and extracts a session authentication cookie embedded in (e.g., comprised in) the IKEv2 authentication request. The obtained session authentication cookie corresponds to a version of the session authentication cookie stored at the endpoint-side and used to generate the IKEv2 authentication request. For example, the extracted session authentication cookie is the session authentication that had been stored locally at the endpoint, which the endpoint had used in connection to generate the IKEv2 authentication request (e.g., to insert into the payload for the IKEv2 authentication request). IKEv2 authentication serviceobtains a server-side version of the session authentication cookie associated with the endpoint and/or the particular session with the endpoint and validates the version of the session authentication cookie extracted from the IKEv2 authentication request (e.g., the decrypted payload of the IKEv2 authentication request) based at least in part on the server-side version of the session authentication cookie. For example, IKEv2 authentication servicecompares the server-side version of the session authentication cookie with the session authentication cookie extracted from the IKEv2 authentication request. In response to determining that the server-side version of the session authentication cookie matches the session authentication cookie extracted from the IKEv2 authentication request, IKEv2 authentication servicedeems the session authentication cookie extracted from the IKEv2 authentication request to be valid.

178 178 170 180 In some embodiments, IKEv2 authentication servicedetermines that the IKEv2 authentication is successful in response to validation using the appropriate PSK and validation using the appropriate session authentication cookie. For example, IKEv2 authentication servicein response to determining that (i) the PSK used by the endpoint to encrypt at least the payload comprised in the IKEv2 authentication request is valid, and (ii) the session authentication cookie extracted from the (decrypted) payload of the IKEv2 authentication request is valid. In response to determining that the IKEv2 authentication is successful, the system (e.g., gateway service) can provide the endpoint with access to network resources.

138 146 152 156 144 138 Network traffic classification servicemay comprise an anomaly detector(e.g., configured to detect anomalies in network traffic, file samples obtained by intercepting traffic, DNS traffic, or DNS records, etc.), a decision engine(e.g., configured to predict whether network traffic, intercepted file samples, or whether a DNS record is malicious), domain profiles, and/or a similarity detector. In some embodiments, network traffic classification servicedetects malicious network traffic or malware obtained from intercepted network traffic (e.g., by classifying a file sample obtained by a security entity or other network node requesting a maliciousness classification).

138 Network traffic classification servicecan determine the classification for network traffic (e.g., a file sample obtained from network traffic, a DNS record, a DNS query, a DNS response, a website content, etc.) based at least in part on querying a classifier(s). The classifier that is queried to provide a classification of the network traffic sample associated with the network activity is a fingerprinting-based classifier, a heuristics-based classifier, another rule-based classifier, and/or a machine-learning based classifier. The classifier may be trained based at least in part on historical samples (e.g., samples of network traffic samples extracted from network traffic). The classifier can be trained based at least in part on a machine learning process.

The classifier(s) may implement one or more machine learning models that may be trained according to a machine learning process. Examples of machine learning processes that can be implemented include random forest, linear regression, support vector machine, naive Bayes, logistic regression, K-nearest neighbors (KNN), decision trees, gradient boosted decision trees, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, a neural network (NN), XGBoost, a convolutional neural network (CNN), and LLM etc.

140 According to various embodiments, security platformmay receive a query from a security entity (e.g., inline firewall, such as a next generation firewall) for a real-time or offline classification of a network traffic sample, such as a file.

138 100 100 100 100 According to various embodiments, in response to network traffic classification serviceclassifying the network traffic sample, systemhandles the corresponding network traffic according to a predefined policy (e.g., a security policy). For example, in response to predicting that the network traffic sample corresponds to malicious network traffic (e.g., that the domain associated with the network traffic is a squatting domain), systemcan cause the network traffic to be blocked or quarantined, etc. As another example, systemcan cause traffic to/from a compromised host (e.g., the client system associated with the intercepted network traffic from which the malicious domain was extracted) to be quarantined or sinkholed, etc. (e.g., at least until an administrator actively configures systemto proceed with permitting traffic to/from the client system, such as in response to the compromised host being remediated).

138 100 140 According to various embodiments, in response to network traffic classification serviceclassifying the network traffic (e.g., the network traffic sample, or a domain associated with the network traffic sample), systemhandles the network traffic according to a predefined policy (e.g., a security policy). For example, the system queries a traffic handling policy to determine the manner by which the network traffic (e.g., network activity for a session associated with the network traffic sample) is to be handled. The traffic handling policy may be a predefined policy, such as a security policy, etc. The traffic handling policy may indicate that network traffic associated with certain domains (e.g., domains classified as squatting domains) or having certain characteristics/profiles is to be blocked and network traffic associated with other domains (e.g., domains not deemed to be squatting domains or otherwise malicious) or having other characteristics/profiles is to be permitted to pass through the system (e.g., routed normally). The traffic handling policy may correspond to a repository of a set of policies to be enforced with respect to network traffic. In some embodiments, security platformreceives one or more policies, such as from an administrator or third-party service, and provides the one or more policies to various network nodes, such as endpoints, security entities (e.g., inline firewalls), etc.

140 138 140 140 140 140 140 In response to determining a classification for a newly analyzed network traffic sample (e.g., a newly analyzed domain for a particular network traffic sample, such as a DNS request or DNS response), security platform(e.g., network traffic classification service) sends an indication that network activity (e.g., other network traffic samples) associated with the domain are associated with, or otherwise correspond to, the determined classification. Security platformcan provide an indication that network traffic matching the network traffic sample predicted to be malicious (e.g., network traffic matching a domain predicted to be a squatting domain) is to be handled as a malicious network traffic. For example, security platformdetermines (e.g., computes) a signature or identifier for the network traffic/activity (e.g., a hash or other signature, or identifier for the corresponding network session or domain), and sends to a network node (e.g., a security entity, an endpoint such as a client device, etc.) an indication of the classification associated with the signature (e.g., an indication whether the network traffic/activity is a malicious or non-malicious). Security platformmay update a mapping of signatures to network traffic sample classifications and provide the updated mapping to the security entity. In some embodiments, security platformfurther provides to the network node (e.g., security entity, client device, etc.) an indication of a manner by which network traffic/activity matching the network traffic sample or otherwise be associated with the same session as the network traffic sample classified as malicious or matching the signature is to be handled. For example, security platformprovides to the security entity a traffic handling policy, a security policy, or an update to a policy.

138 According to various embodiments, in response to determining the maliciousness classification for a network traffic sample (e.g., obtaining the predicted maliciousness classification, such as from a classifier), network traffic classification serviceprovides an indication of the maliciousness classification, such as to the applicable security entity (e.g., the security entity that provided the network traffic sample or a security entity mediating network traffic for the session associated with the network traffic sample).

1 FIG. 120 130 104 130 150 150 Returning to, suppose that a malicious individual (using client device) has created malware or malicious sample, such as a file, an input string, etc. The malicious individual hopes that a client device, such as client device, will execute a copy of malware or other exploit (e.g., malware or malicious sample), compromising the client device, and causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform tasks (e.g., cryptocurrency mining, or participating in denial-of-service attacks) and/or to report information to an external entity (e.g., associated with such tasks, exfiltrate sensitive corporate data, etc.), such as C2 server, as well as to receive instructions from C2 server, as applicable.

1 FIG. 122 126 122 110 124 110 114 116 126 150 122 124 126 170 122 140 As an illustrative example, the environment shown inincludes three Domain Name System (DNS) servers (-). As shown, DNS serveris under the control of ACME (for use by computing assets located within enterprise network), while DNS serveris publicly accessible (and can also be used by computing assets located within enterprise networkas well as other devices, such as those located within other networks (e.g., networksand)). DNS serveris publicly accessible but under the control of the malicious operator of C2 server. Enterprise DNS serveris configured to resolve enterprise domain names into IP addresses, and is further configured to communicate with one or more external DNS servers (e.g., DNS serversand) to resolve domain names as applicable. In some embodiments, gateway serviceis implemented at enterprise DNS serverrather than, or in addition to, being implemented at security platform.

128 104 104 122 124 104 128 150 104 126 104 126 150 104 As mentioned above, in order to connect to a legitimate domain (e.g., www. example. com depicted as website), a client device, such as client devicewill need to resolve the domain to a corresponding Internet Protocol (IP) address. One way such resolution can occur is for client deviceto forward the request to DNS serverand/orto resolve the domain. In response to receiving a valid IP address for the requested domain name, client devicecan connect to websiteusing the IP address. Similarly, in order to connect to malicious C2 server, client devicewill need to resolve the domain, “kj32hkjqfeuo32ylhkjshdflu23.badsite.com,” to a corresponding Internet Protocol (IP) address. In this example, malicious DNS serveris authoritative for *.badsite.com and client device's request will be forwarded (for example) to DNS serverto resolve, ultimately allowing C2 serverto receive data from client device.

102 104 106 110 118 102 110 Data applianceis configured to enforce policies regarding communications between client devices, such as client devicesand, and nodes outside of enterprise network(e.g., reachable via external network). Examples of such policies include ones governing traffic shaping, quality of service, and routing of traffic. Other examples of policies include security policies such as ones requiring the scanning for threats in incoming (and/or outgoing) email attachments, website content, information input to a web interface such as a login screen, files exchanged through instant messaging programs, and/or other file transfers, and/or quarantining or deleting files or other exploits identified as being malicious (or likely malicious). In some embodiments, data applianceis also configured to enforce policies with respect to traffic that stays within enterprise network. In some embodiments, a security policy includes an indication that network traffic (e.g., all network traffic, a particular type of network traffic, etc.) is to be classified/scanned by a classifier that implements a pre-filter model, such as in connection with detecting malicious or suspicious domains, detecting parked domains, or otherwise determining that certain detected network traffic is to be further analyzed (e.g., using a finer detection model).

140 102 102 102 In some embodiments, security platformcomprises a network traffic classifier that provides to a security entity, such as data appliance, an indication of the traffic classification. For example, in response to detecting the C2 traffic, network traffic classifier sends an indication that the domain traffic corresponds to C2 traffic to data appliance, and the data appliancemay in turn enforce one or more policies (e.g., security policies) based at least in part on the indication. The one or more security policies may include isolating/quarantining the content (e.g., webpage content) for the domain, blocking access to the domain (e.g., blocking traffic for the domain), isolating/deleting the domain access request for the domain, ensuring that the domain is not resolved, alerting or prompting the user of the client device the maliciousness of the domain prior to the user viewing the webpage, blocking traffic to or from a particular node (e.g., a compromised device, such as a device that serves as a beacon in C2 communications), etc. As another example, in response to determining the application for the domain, the network traffic classifier provides to the security entity with an update of a mapping of signatures to applications (e.g., application identifiers).

2 FIG. 200 210 220 210 is a block diagram of a system for providing access to network resources according to various embodiments. In the example shown, systemcomprises a security service clientand a firewall. Security service clientmay be installed/running on an endpoint, such as a client system.

220 230 230 230 232 232 232 232 230 234 232 234 240 In some embodiments, firewallcomprises gateway service. Gateway servicemay be a management plane. Gateway servicemay comprise gateway session service, which may be a process or service that provide backend logic for an SSL VPN or security service. As an example, gateway session serviceis primarily concerned with configuration data. Gateway session servicecan handle user-related information. This includes specifying which RAS objects can be created, their options, and how they are connected. When an application requests an object, such as a message logger, gateway session servicecreates it from its configuration data and returns it. Additionally, gateway servicemay comprise Key management service, which may be a process or service that performs key repository management. Gateway session serviceand Key management servicemay be used to provide security for a data plane.

252 210 220 220 230 232 254 232 220 230 232 210 258 220 230 260 230 232 262 230 232 232 264 232 234 266 234 240 268 220 234 240 240 270 220 240 At, the endpoint (e.g., via security service client) sends a login request to firewall. Firewall(e.g., gateway service) uses gateway session serviceto perform an authentication of the endpoint, such as based on login credentials comprised in the login request. At, gateway session service iongenerates a session authentication cookie upon successful login authentication of the endpoint. Firewall(e.g., gateway service, or specifically gateway session service) sends the session authentication cookie back to the endpoint (e.g., the security service client). At, the endpoint sends to firewall(e.g., to gateway service) a getconfig request. In response to receiving the getconfig request, at, gateway service(e.g., gateway session service) configures a tunnel, such as including generating a tunnel identifier, and populating the appropriate keys. At, gateway service(e.g., gateway session service) sends a getconfig response to the endpoint. For example, gateway session servicesends tunnel configuration information, including the populated keys. Additionally, at, gateway session servicesends (e.g., pushes) this configuration information to key management service. In response to receiving the tunnel configuration information, at, key management servicesends the tunnel configuration information to data plane. At, firewall(e.g., key management serviceor data plane) installs or configures the tunnel with data plane. At, firewallprovides the endpoint with access to data planevia the configured tunnel.

210 2 210 210 230 330 210 2 FIG. 3 FIG. According to various embodiments, in connection with performing IKEv2 authentication, an endpoint (e.g., a security service clientrunning on the endpoint) initiates a IKEv2 key exchange via an IKEv2 SA_INIT initiation message and IKEv2 authentication message. One of the options is to use a pre-shared key in the authentication payload during IKEv2 authentication. As part of the IKEVauthentication message, the endpoint (e.g., a security service clientrunning on the endpoint) sends a PSK as the identity field to authenticate the end-user or the endpoint (e.g., a security service clientrunning on the endpoint). This PSK is a pre-shared and pre-agreed upon phrase between the initiator and the responder. The system (e.g., a gateway service, such as gateway serviceofor gateway serviceof) will authenticate the endpoint (e.g., a security service clientrunning on the endpoint) during a gateway IKEv2 authentication session. For example, the system authenticates the endpoint based on the authentication payload information comprised in the IKEv2 authentication message. In related art systems, however, the IKEv2 authentication message will not have any information related to the end user to authenticate at the firewall (e.g., the gateway service). Accordingly, related art firewalls or gateway services prompt the user to enter the username/password to validate and authenticate the user's IKE session. This will pose a manual intervention problem at the client end (e.g., at the endpoint). In addition, the user/endpoint is now caused to enter username/password twice (e.g., once during login and another during IKE authentication, which is duplicate effort).

2 Usually, user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks. In addition, in some instances these attacks are not prevented in a PSK-based IKEVauthentication method. Accordingly, any intruder who can guess the password (e.g., the login credentials) of the user or knows the PSK can initiate an IKEV2 authentication session with the firewall (e.g., the gateway service) and become IKEv2 authentication with respect to the gateway service. This poses a security threat to IKEv2 for the gateway service. Accordingly, a more secure way to validate that the end user is required. Various embodiments address these security concerns and facilitate automatic and secure IKEv2 authentication with the gateway service.

In some embodiments, the system uses a session authentication cookie in connection with an IKEv2 authentication. The system may authenticate an endpoint based at least in part on the session authentication cookie used during IKEv2 authentication. The session authentication cookie is generated when the user logs into a gateway service (e.g., a gateway provided by a firewall) by submitting login credentials. As an example, the login credentials include a user identifier (e.g., a username) and passcode (e.g., a password, a pin, etc.). The gateway service provides the endpoint with the session authentication cookie (e.g., in response to login authentication) and a PSK over a hypertext transfer protocol secure (HTTPS) secure channel. The endpoint (e.g., the security service client running on the endpoint) uses this PSK in connection with determining the IKEv2 authentication request message. For example, the endpoint inserts the PSK into the identity field (e.g., the authentication payload) of the IKEv2 authentication request message. As another example, the endpoint uses the PSK to encrypt the information comprised in the identity field (e.g., the authentication payload) of the IKEv2 authentication request message. According to various embodiments, the endpoint (e.g., the security service client) inserts the session authentication cookie (e.g., for the particular session between the endpoint and the gateway) into the identity field (e.g., the authentication payload) of the IKEv2 authentication request message. As an example, the endpoint inserts the session authentication cookie into the authentication payload and uses the PSK to encrypt the authentication payload. At the firewall (e.g., the gateway service), the firewall decodes (e.g., decrypts) the authentication payload the PSK information. For example, the gateway service obtains a PSK for the endpoint that is stored on the gateway-side, and uses the obtained PSK to decrypt the IKEv2 authentication request message (e.g., the authentication payload extracted from the IKEv2 authentication request message). In response to decoding (e.g., decrypting the authentication payload), the gateway service extracts a session authentication cookie from the authentication payload. The gateway service uses the extracted session authentication cookie to validate and authenticate the endpoint (e.g., the user) with the gateway service. For example, the gateway service compares the extracted session authentication cookie with a gateway-side stored version of the session authentication cookie assigned for the particular endpoint session, and determines that the extracted session authentication cookie is valid if the two versions of the session authentication cookie match.

Accordingly, in some embodiments, the gateway service can authenticate the IKEv2 session of the end user automatically without prompting for the user to enter input credentials (e.g., a username/password) again.

3 FIG. 300 310 320 310 320 330 330 330 is a block diagram of a system for providing access to network resources according to various embodiments. In the example shown, systemcomprises a security service clientand a firewall. Security service clientmay be installed/running on an endpoint, such as a client system. In some embodiments, firewallcomprises gateway service. Gateway servicemay store a master key, for example, a unique key among master keys for the various gateways in the network. Gateway servicecan use the master key in connection with generating the PSK for the endpoint.

320 330 330 332 332 332 332 30 334 330 336 336 332 334 336 340 In some embodiments, firewallcomprises gateway service. Gateway servicemay comprise gateway session service, which may be a process or service that provide backend logic for an SSL VPN or security service. Gateway session servicemay be responsible for handling user-related configuration on the gateway, allocate IP addresses to endpoints (e.g., to clients), generating session authentication cookies, and/or validating an end user in conjunction with another authentication process. As an example, gateway session serviceis primarily concerned with configuration data. This includes specifying which RAS objects can be created, their options, and how they are connected. When an application requests an object, such as a message logger, gateway session servicecreates it from its configuration data and returns it. Gateway servicemay additionally comprise key service, which is configured to perform IKEv2 authentication for endpoints. Additionally, gateway servicemay comprise key management service, which may be a process or service that performs key repository management. For example, key management servicemay be responsible for dispatching keys to the data plane and/or other clusters. Gateway session service, key service, and key management servicemay be used to provide security for a data plane.

352 310 320 320 230 332 354 332 320 330 332 310 358 320 330 360 230 332 330 330 330 362 330 332 330 At, the endpoint (e.g., via security service client) sends a login request to firewall. Firewall(e.g., gateway service) uses gateway session serviceto perform an authentication of the endpoint, such as based on login credentials comprised in the login request. At, gateway session servicegenerates a session authentication cookie upon successful login authentication of the endpoint. The session authentication cookie can be randomly generated and may be a unique value for the particular session (e.g., the cookie may be unique across other session authentication cookies for sessions at the gateway). Firewall(e.g., gateway service, or specifically gateway session service) sends the session authentication cookie back to the endpoint (e.g., the security service client). At, the endpoint sends to firewall(e.g., to gateway service) a getconfig request. In response to receiving the getconfig request, at, gateway service(e.g., gateway session service) obtains the PSK for the endpoint. In some embodiments, gateway servicegenerates the PSK, such as based on the master key (e.g., the master key assigned to and locally stored at the gateway service) and a salt. The salt may be a random value, such as a random value added to a password or data (e.g., the master key) before the value is hashed. A unique salt may be generated for each PSK to be generated. In some embodiments, the salt and the master key are combined and then hashed using a secure algorithm (e.g., a predefined algorithm/hashing function). Gateway servicecan store the session authentication cookie and salt (or the PSK) locally. At, gateway service(e.g., gateway session service) sends a getconfig response to the endpoint. Gateway servicecan embed the PSK in the getconfig response.

364 330 334 330 334 368 330 334 310 320 330 At, the endpoint sends an IKEv2 initiation message. In response to receiving the IKEv2 initiation message, gateway servicecan provide the message to key service. Gateway service(e.g., key service) can provide an IKE response message to the endpoint. At, the endpoint configures an IKEv2 authentication request message and provides the IKEv2 authentication request message to gateway service(e.g., key service). In some embodiments, the endpoint generates the IKEv2 authentication request message based at least in part on (a) obtaining the session authentication cookie for the session between the endpoint (e.g., security service client) and firewall(e.g., gateway service), (b) embedding the session authentication cookie in the payload for the IKEv2 authentication request message, (c) obtaining the PSK (e.g., the PSK for the authentication between the endpoint and the gateway service), and (d) encrypting the payload for the IKEv2 authentication request message based at least in part on the PSK.

370 330 330 330 334 330 In response to receiving the IKEv2 authentication request, at, gateway servicecan perform the IKEv2 authentication of the endpoint. In some embodiments, performing the IKEv2 authentication includes (i) obtaining the PSK associated with the endpoint, (ii) decrypting the IKEv2 authentication request (e.g., the payload for the IKEv2 authentication request), (iii) extracting a session authentication cookie (e.g., from the decrypted payload), and (iv) validating the extracted session authentication cookie. In some implementations, the obtaining the PSK includes performing a lookup (e.g., based on the endpoint or the particular session with the endpoint) of a locally stored (e.g., stored at the server-side or gateway-side) PSK. In other implementations, the system performs a lookup (e.g., based on the endpoint or the particular session with the endpoint) of the salt used to generate the PSK provided to the endpoint, and gateway servicelocally re-generates the PSK, such as based on the salt and the master key for gateway service. For example, key servicemakes an API call to gateway serviceto decrypt the IKEv2 authentication request (or the payload comprised in IKEv2 authentication request) and to authenticate the endpoint.

330 330 330 330 In response to determining that the IKEv2 authentication request (or the payload comprised in IKEv2 authentication request) is successfully decrypted with the server-side/gateway-side version of the PSK (e.g., the locally stored PSK or the PSK generated using the salt stored in association with the session authentication cookie, etc.), gateway servicedeems the PSK used by the endpoint (e.g., to encrypt the payload) as being validated. In response to successfully decrypting the IKEv2 authentication request (or the payload comprised in IKEv2 authentication request), the system validates the session authentication cookie extracted from the decrypted payload. For example, gateway serviceperforms a lookup for the locally stored (e.g., stored server-side or gateway-side) version of the session authentication cookie, such as based on an identifier of the endpoint and/or a session identifier for the session between the endpoint and gateway service. In response to obtaining the locally stored version of the session authentication cookie, gateway servicevalidates the session authentication cookie extracted from the decrypted payload based at least in part on the locally stored version of the session authentication cookie. For example, the system determines whether the session authentication cookie extracted from the decrypted payload matches the locally stored version of the session authentication cookie.

In some embodiments, the system determines that the IKEv2 authentication of the endpoint is successful if both the PSK and the session authentication cookie used to generate the IKEv2 authentication request are validated.

374 330 334 372 330 334 340 376 330 334 378 330 334 330 334 380 334 336 334 336 382 336 340 384 320 336 240340 340 386 320 340 At, gateway service(e.g., key service) provides an IKEv2 authentication response. As an example, the IKEv2 authentication response indicate whether the IKEv2 authentication was successful. Additionally, upon successful IKEv2 authentication, at, gateway service(e.g., key service) generates/populates the appropriate keys, such as the keys to be used in connection with establishing a tunnel with data plane. At, the endpoint and gateway service(e.g., key service) perform a key exchange. At, gateway service(e.g., key service) generates a request for establishing a tunnel. For example, gateway service(e.g., key service) makes an API call to obtain data (e.g., the appropriate keys) for establishing the tunnel. At, key serviceprovides the data (e.g., the appropriate keys) to key management service. For example, key servicesends (e.g., pushes) this configuration information to key management service. In response to receiving the tunnel configuration information, at, key management servicesends the tunnel configuration information to data plane. At, firewall(e.g., key management serviceor data planeinstalls or configures the tunnel with data plane. At, firewallprovides the endpoint with access to data planevia the configured tunnel.

4 FIG. 1 FIG. 3 FIG. 3 FIG. 400 100 300 400 170 100 330 is a flow diagram of a method for validating an endpoint according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In the example shown, the system receives an authentication request and performs an authentication (e.g., IKEv2 authentication) of the endpoint. In some embodiments, processis implemented by a firewall or gateway, such as gateway serviceof systemand/or gateway serviceof.

400 400 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

405 410 415 400 400 400 400 400 400 400 405 At, the system obtains an authentication request from an endpoint. At, the system validates the endpoint using the PSK and the session authentication cookie. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, no further endpoints are to be authenticated, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

5 FIG. 1 FIG. 3 FIG. 3 FIG. 500 100 300 500 170 100 330 is a flow diagram of a method for validating an endpoint according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by a firewall or gateway, such as gateway serviceof systemand/or gateway serviceof.

500 500 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

505 510 515 500 520 500 525 530 500 500 500 500 500 500 500 505 At, the system obtains an authentication request from an endpoint. At, the system validates the endpoint using the PSK and the session authentication cookie. At, the system determines whether the endpoint is validated. In response to determining that the endpoint is validated, processproceeds toat which the system provides access to one or more resources. For example, the system provides the endpoint with access to the one or more resources exposed by the network (e.g., an enterprise network). In response to determining that the endpoint is not validated, processproceeds toat which the system fails the authentication request. In connection with failing the authentication request, the system can provide an indication to the endpoint that the authentication has failed. The system may additionally prompt the endpoint to retry authentication, or direct the endpoint to reinitiate a session with the system. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

6 FIG. 1 FIG. 3 FIG. 3 FIG. 600 100 300 600 170 100 330 is a flow diagram of a method for obtaining a session authentication cookie for an endpoint according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by a firewall or gateway, such as gateway serviceof systemand/or gateway serviceof.

600 600 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

In some embodiments, the system generates the session authentication cookie as a unique identifier that facilitates secure and session-specific authentication for an endpoint. The session authentication cookie is created when an endpoint initiates a login process by sending a login request to the system. This request includes user credentials, such as a username and password, which the system validates to verify the identity of the user or device associated with the endpoint. Upon successful validation of the credentials, the system generates a session authentication cookie to associate with the specific session initiated by the endpoint.

The generation of the session authentication cookie may involve the use of a session authentication cookie service that produces a random and unique alphanumeric code or value. This randomness ensures that the cookie is difficult to predict or replicate, thereby reducing the risk of unauthorized access or replay attacks. The session authentication cookie is tied specifically to (e.g., associated with) the session for which it is created, and if the endpoint initiates a new session, the system generates and assigns a new session authentication cookie. This session-specific design adds an additional layer of security, ensuring that each session is uniquely identifiable and authenticated independently.

Once generated, the session authentication cookie is securely provided to the endpoint as part of the login response. The system transmits the session authentication cookie to the endpoint through a secure communication channel, such as an encrypted HTTPS connection. This secure transmission prevents interception or tampering by malicious actors during transit. By embedding the session authentication cookie within the login response, the system ensures that the endpoint receives the cookie in a manner that preserves its confidentiality and integrity.

The endpoint stores the session authentication cookie for use in subsequent authentication requests, such as during the IKEv2 authentication process. When the endpoint needs to authenticate with the system, it includes the session authentication cookie within the payload of the authentication request. This cookie, combined with other security measures like a PSK, enables the system to validate the session and authenticate the endpoint. The secure generation and provision of the session authentication cookie play a critical role in enhancing the overall security and reliability of the authentication process.

605 610 615 600 620 620 625 600 630 635 600 600 600 600 600 600 600 At, the system obtains a login request from an endpoint. At, the system authenticates the endpoint based at least in part on credentials comprised in the login request. At, the system determines whether the endpoint is authenticated. In response to determining that the endpoint is authenticated, processproceeds to. At, the system obtains a session authentication cookie. At, the system provides the session authentication cookie in connection with a login response. In response to determining that the endpoint is not authenticated, processproceeds toat which the system fails the authentication request. In connection with failing the authentication request, the system can provide an indication to the endpoint that the authentication has failed. The system may additionally prompt the endpoint to retry authentication, or direct the endpoint to reinitiate a session with the system. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to 605.

7 FIG. 1 FIG. 3 FIG. 3 FIG. 700 100 300 700 310 is a flow diagram of a method for obtaining a session authentication cookie for an endpoint according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by an endpoint or a security service client running on an endpoint, such as security service clientof.

700 In some embodiments, processis implemented by an endpoint, such as an endpoint attempting to connect to a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. The endpoint may authenticate with the cloud service to obtain access to network resources.

705 710 715 720 725 700 700 700 700 700 700 700 705 At, the system provides a login request. At, the system receives a login response. At, the system extracts a session authentication cookie. For example, the endpoint extracts the session authentication cookie that was generated and provided by the firewall/gateway. At, the system stores the session authentication cookie. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, no further session authentication cookies are to be generated, no further endpoint login requests are to be processed, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

According to various embodiments, the system dynamically generates a PSK to enhance the security of the IKEv2 authentication process by ensuring that the key is unique and session-specific. The PSK is created in response to a configuration request, such as a getconfig request, received from the endpoint. To generate the PSK, the system can use a cryptographic process that involves a master key and a salt value. This combination ensures that the resulting PSK is sufficiently randomized and difficult to predict, providing a robust level of security against brute force or other attacks aimed at guessing the key.

The generation process is designed to be automated and repeatable within the system, removing the need for manual intervention by administrators, which often introduces vulnerabilities. By dynamically generating PSKs for each session or endpoint, the system avoids the pitfalls of static keys that may be reused across multiple connections. This dynamic approach ensures that even if one PSK is compromised, it does not jeopardize the security of other sessions or endpoints, thereby limiting the potential impact of a breach.

Once the PSK is generated, the system securely transmits it to the endpoint as part of the configuration response to the getconfig request. The delivery process leverages secure communication protocols, such as an encrypted HTTPS connection or a similar method, to ensure that the PSK remains confidential during transit. By transmitting the PSK through a secure channel, the system mitigates the risk of interception or unauthorized access by malicious actors who may attempt to exploit weak or unsecured communication methods.

The endpoint receives the PSK and uses it as part of its subsequent IKEv2 authentication requests. Specifically, the PSK is used to encrypt the payload of the authentication request, which includes critical elements like the session authentication cookie. This encrypted payload is then transmitted back to the system for decryption and validation. By coupling the dynamically generated PSK with session-specific elements, the system ensures that the authentication process is highly secure and resistant to common attack vectors such as replay attacks or key compromise. This approach provides a robust framework for managing secure access to network resources while maintaining flexibility and ease of deployment for enterprise environments.

8 FIG. 1 FIG. 3 FIG. 3 FIG. 800 100 300 800 170 100 330 is a flow diagram of a method for obtaining a pre-shared key (PSK) according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by a firewall or gateway, such as gateway serviceof systemand/or gateway serviceof.

800 800 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

805 810 815 820 825 800 800 800 800 800 800 800 805 At, the system obtains a getconfig request from an endpoint. At, the system obtains a pre-shared (PSK). For example, the system generates the PSK based at least in part on a locally stored master key and a cryptographic salt. At, the system stores information pertaining to the PSK in association with a session authentication cookie assigned to the endpoint for the particular session between the endpoint and the gateway. In some embodiments, the system stores the PSK in association with an identifier for the endpoint. At, the system provides to the endpoint a getconfig response comprising the PSK. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, no further PSKs are to be generated, no further endpoint login requests are to be processed, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

9 FIG. 1 FIG. 3 FIG. 3 FIG. 900 100 300 900 310 is a flow diagram of a method for obtaining a pre-shared key (PSK) according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by an endpoint or a security service client running on an endpoint, such as security service clientof.

900 In some embodiments, processis implemented by an endpoint, such as an endpoint attempting to connect to a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. The endpoint may authenticate with the cloud service to obtain access to network resources.

905 910 915 920 925 900 900 900 900 900 900 900 905 At, the system provides a getconfig request to a gateway. At, the system obtains a getconfig response from the gateway. At, the system extracts a PSK from the getconfig response. At, the system stores the PSK. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, no further IKEv2 authentications are to be performed with the gateway, no further network resources are to be accessed by the endpoint, a session between the endpoint and the gateway has ended, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

To perform IKEv2 authentication, the endpoint initiates a request by preparing a payload that includes authentication data, such as the session authentication cookie. The session authentication cookie is a unique identifier previously assigned to the endpoint during a secure login process with the system. By including the session authentication cookie in the authentication payload, the endpoint ensures that the authentication process is tied to a specific session and incorporates an additional layer of security to validate its legitimacy.

Before transmitting the payload, the endpoint encrypts it using the PSK that was securely received from the system during the configuration process. The PSK, generated dynamically by the system and transmitted via a secure channel, serves as a critical component in protecting the confidentiality and integrity of the payload. Encryption of the payload ensures that the session authentication cookie and any other sensitive information included in the request cannot be intercepted or tampered with by malicious actors during transmission.

The encryption process utilizes cryptographic algorithms compatible with the IKEv2 protocol, ensuring secure and efficient encryption of the payload. By encrypting the session authentication cookie and other authentication data, the endpoint prevents unauthorized access or manipulation of the information in transit. This encryption also ensures that only the intended recipient, the system, which holds the corresponding decryption key (derived from the PSK), can access and validate the contents of the payload.

Once the payload is encrypted, the endpoint encapsulates it within the IKEv2 authentication request and transmits the request to the system. The system receives the IKEv2 authentication request and uses its server-side stored PSK (or a contemporaneously generated PSK based on a server-side salt stored in association with the endpoint and/or session) to decrypt the payload. Upon successful decryption, the system extracts the session authentication cookie and validates it by comparing it with the corresponding server-side stored session authentication cookie. If the session authentication cookie is valid and unexpired, and the payload is correctly decrypted, the system authenticates the endpoint and grants access to the requested resources.

This process ensures a secure and efficient mechanism for authenticating endpoints, leveraging dynamic PSK generation and session-specific cookies to mitigate risks associated with static keys and replay attacks. By encrypting the payload with the PSK, the endpoint safeguards the authentication request, maintaining the confidentiality and integrity of the session while facilitating robust network access control.

10 FIG. 1 FIG. 3 FIG. 3 FIG. 1000 100 300 1000 170 100 330 is a flow diagram of a method for validating an endpoint in connection with an Internet Key Exchange version 2 (IKEv2) authentication according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by a firewall or gateway, such as gateway serviceof systemand/or gateway serviceof.

1000 1000 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

According to various embodiments, when the system receives an IKEv2 authentication request from an endpoint, it begins the authentication process by decrypting the payload of the request. The payload, encrypted by the endpoint using the PSK, contains critical authentication data, including the session authentication cookie. The system retrieves the server-side stored PSK (or a contemporaneously generated PSK using a server-side stored salt and master key), which corresponds to the endpoint or the session, and uses it to decrypt the received payload. This decryption step ensures that the contents of the payload can only be accessed by the system and confirms the integrity of the transmitted data.

After successfully decrypting the payload, the system extracts the session authentication cookie included by the endpoint. This session authentication cookie is a unique identifier that the system previously assigned to the endpoint during a secure login process. To validate the cookie, the system compares the extracted value with a server-side stored session authentication cookie associated with the endpoint or the specific session. The comparison ensures that the session authentication cookie matches the expected value and has not been tampered with during transmission.

In addition to verifying the match, the system checks the validity of the session authentication cookie by ensuring it has not expired. The session authentication cookie may have a predefined validity period, and the system evaluates whether the cookie is still within this timeframe. This step ensures that even if a session authentication cookie were intercepted, it could not be reused beyond its intended duration, protecting the system against replay attacks.

If the decryption of the payload is successful and the session authentication cookie is both valid and matches the stored reference, the system authenticates the endpoint. This successful authentication grants the endpoint access to the requested network resources or assets behind the system. Conversely, if the payload cannot be decrypted, the session authentication cookie does not match, or the cookie is expired, the system denies the authentication request, effectively blocking the endpoint from accessing protected resources.

This process ensures a robust authentication mechanism that combines dynamic key management and session-specific validation. By utilizing the PSK to decrypt the payload and validating the session authentication cookie, the system provides a secure method for confirming the identity and legitimacy of endpoints seeking access to critical network assets. This layered approach mitigates risks associated with static credentials, unauthorized access, and replay attacks, delivering a highly secure and scalable solution for enterprise environments.

10 FIG. 1005 1010 1015 1020 1025 1000 1000 1000 1000 1000 1000 1000 1005 Returning to the example shown in, at, the system obtains an IKEv2 authentication request. At, the system obtains a payload comprised in the IKEv2 authentication request. At, the system obtains a PSK based at least in part on PSK information (e.g., a cryptographic salt, a master key, etc.) stored in association with the endpoint. At, the system validates the endpoint based at least in part on the PSK and the payload. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

11 FIG. 1 FIG. 3 FIG. 3 FIG. 1100 100 300 1100 310 is a flow diagram of a method for validating an endpoint in connection with an Internet Key Exchange version 2 (IKEv2) authentication according to various embodiments. According to various embodiments, processis implemented at least in part by one or more of systemofand/or systemof. In some embodiments, processis implemented by an endpoint or a security service client running on an endpoint, such as security service clientof.

1100 1100 In some embodiments, processis implemented by a cloud service (e.g., one or more servers) that provides other network security services to various network endpoints or security entities. For example, the system may implement processto authenticate endpoints such as in connection with exposing network assets to the endpoint.

1105 1110 1115 1120 1125 1130 1100 1100 1100 1100 1100 1100 1100 1105 At, the system obtains an indication to validate the endpoint in connection with an IKEv2 authentication request. At, the system decrypts a payload extracted from the IKEv2 authentication request based at least in part on PSK information (e.g., a cryptographic salt, a master key, etc.) stored in association with the endpoint. At, the system obtains a session authentication cookie from the decrypted payload. At, the system validates the session authentication cookie. At, the system provides an indication of a result of validating the session authentication cookie. At, the system determines whether processis complete. In some embodiments, the system determines processto be complete in response to a determination that authentication of the endpoint has completed, a session between an endpoint and gateway service is terminated, no further endpoints are to be authenticated, an administrator indicates that processis to be paused or stopped, etc. In response to a determination that processis complete, processends. In response to a determination that processis not complete, processreturns to.

Various examples of embodiments described herein are described in connection with flow diagrams. Although the examples may include certain steps performed in a particular order, according to various embodiments, various steps may be performed in various orders and/or various steps may be combined into a single step or in parallel.

Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.