Search

US-20260129038-A1 - AUTHENTICATION (AUTHN) AND AUTHORIZATION (AUTHZ) BINDING FOR SECURE NETWORK ACCESS

US20260129038A1US 20260129038 A1US20260129038 A1US 20260129038A1US-20260129038-A1

Abstract

Techniques for combining independent sessions between application(s) and a VPN, proxy service, or similar system, including inner protocol sessions (e.g., such as QUIC, etc.), coming from a single device to form a single logicalsession, where the single logical session could share a single authentication/authorization token are described. The techniques include receiving, from a device within a network, a request for a first application to access a service associated with the proxy service or the VPN, sending, to the device, a first authentication request, and receiving, from the device, a message including a token. The techniques may further include authenticating, by the proxy service or the VPN, the token using a unique identifier associated with the device and enabling, by the proxy service or the VPN, the device to access the service via a first session flow.

Inventors

  • Vincent E. Parla
  • Kyle Andrew Donald Mestery

Assignees

  • CISCO TECHNOLOGY, INC.

Dates

Publication Date
20260507
Application Date
20251230

Claims (20)

  1. 1 . A method comprising: receiving, from a device within a network, a first request for a first application to access a service associated with a proxy service or a virtual private network (VPN); sending, to the device, a first authentication request; receiving, from the device, a message including a token, the token having a signature generated using a client certificate associated with the device; authenticating, by the proxy service or the VPN, the token by verifying the signature as being generated using the client certificate; enabling, by the proxy service or the VPN, the first application to access the service via a first session flow; receiving, from the device, a second request for a second application to access a second service; sending, to the device, a second authentication request; receiving, from the device, a second token signed using the client certificate; authenticating, by the proxy service or the VPN, the second token as being signed using the client certificate; and injecting, by the proxy service or the VPN, a cookie into a second session flow of the second application, wherein the cookie prevents the second application from receiving an interactive authentication request.
  2. 2 . The method of claim 1 , wherein the first authentication request comprises an interactive authentication request and the second authentication request comprises a passive authentication request.
  3. 3 . The method of claim 2 , wherein the passive authentication request comprises a request for the device to provide proof of possession of the client certificate without requiring user input.
  4. 4 . The method of claim 1 , wherein the client certificate comprises a public key and a private key pair, and wherein the signature is generated using the private key.
  5. 5 . The method of claim 4 , wherein the public key is stored in a database associated with the proxy service or the VPN.
  6. 6 . The method of claim 1 , wherein the proxy service comprises a multiplexed application substrate over QUIC encryption (MASQUE) proxy service.
  7. 7 . The method of claim 6 , wherein the MASQUE proxy service is executing on a first proxy node of one or more nodes, the first proxy node being deployed in an enterprise network associated with at least one of a DNS server or an application node.
  8. 8 . The method of claim 1 , wherein prior to receiving the first request to access the service, the method further comprises: receiving, by the proxy service or the VPN, a request to register the device within the network; assigning, by the proxy service or the VPN, the client certificate to the device; storing, by the proxy service or the VPN, the client certificate in a database associated with the proxy service or the VPN; and sending, to the device, the client certificate.
  9. 9 . The method of claim 1 , wherein the token is generated using at least one of WebAuthN, FIDO, TPM, or OS protected client certificate private keys.
  10. 10 . The method of claim 1 , wherein the client certificate is shared across disparate applications on the device including the first application and the second application.
  11. 11 . A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving, from a device within a network, a first request for a first application to access a service associated with a proxy service or a virtual private network (VPN); sending, to the device, a first authentication request; receiving, from the device, a message including a token, the token having a signature generated using a client certificate associated with the device; authenticating, by the proxy service or the VPN, the token by verifying the signature as being generated using the client certificate; enabling, by the proxy service or the VPN, the first application to access the service via a first session flow; receiving, from the device, a second request for a second application to access a second service; sending, to the device, a second authentication request; receiving, from the device, a second token signed using the client certificate; authenticating, by the proxy service or the VPN, the second token as being signed using the client certificate; and injecting, by the proxy service or the VPN, a cookie into a second session flow of the second application, wherein the cookie prevents the second application from receiving an interactive authentication request.
  12. 12 . The system of claim 11 , wherein the first authentication request comprises an interactive authentication request and the second authentication request comprises a passive authentication request.
  13. 13 . The system of claim 12 , wherein the passive authentication request comprises a request for the device to provide proof of possession of the client certificate without requiring user input.
  14. 14 . The system of claim 11 , wherein the client certificate comprises a public key and a private key pair, and wherein the signature is generated using the private key.
  15. 15 . The system of claim 14 , wherein the public key is stored in a database associated with the proxy service or the VPN.
  16. 16 . The system of claim 11 , wherein the proxy service comprises a multiplexed application substrate over QUIC encryption (MASQUE) proxy service.
  17. 17 . A device comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: sending, to a proxy service or a virtual private network (VPN), a first request for a first application to access a service associated with the proxy service or the VPN; receiving, from the proxy service or the VPN, a first authentication request; generating a first token having a signature using a client certificate associated with the device; sending, to the proxy service or the VPN, a message including the first token; establishing, in response to the first token being authenticated, a first session flow between the first application and the service; sending, to the proxy service or the VPN, a second request for a second application to access a second service; receiving, from the proxy service or the VPN, a second authentication request; generating a second token signed using the client certificate; sending, to the proxy service or the VPN, the second token; and establishing, in response to the second token being authenticated, a second session flow between the second application and the second service, wherein the second session flow includes a cookie that prevents the second application from receiving an interactive authentication request.
  18. 18 . The device of claim 17 , wherein the first authentication request comprises an interactive authentication request and the second authentication request comprises a passive authentication request.
  19. 19 . The device of claim 18 , wherein the passive authentication request comprises a request for the device to provide proof of possession of the client certificate without requiring user input.
  20. 20 . The device of claim 17 , wherein the first token and the second token are generated using at least one of WebAuthN, FIDO, TPM, or OS protected client certificate private keys.

Description

RELATED APPLICATIONS This application is a continuation of and claims priority to U.S. Application No. 17/902,201, filed on September 2, 2022, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD The present disclosure relates generally to computer networking and more particularly to combining independent sessions with a proxy service, including inner protocol sessions (e.g., such as QUIC, etc), coming from a single device to form a single logical session, where the single logical session could share a single authentication/authorization token. BACKGROUND Cloud-based service provider networks, often described as ‘hyperscalers’, offer cloud-based services to fulfill users’ computing-service needs without the users having to invest in and maintain computing infrastructure required to implement the services. For example, cloud service providers may operate networks of data centers housing significant numbers of interconnected computing systems, such as public data centers, that are configured by the service provider to provide cloud-based services to users (or “customers”). These service provider networks may provide network-based computing resources on an as-needed basis. For example, a service provider network may permit users to purchase and utilize computing resources such as virtual machine (“VM”) instances, compute resources, data storage resources, database resources, networking resources, network services, and other types of computing resources. Users may configure the computing resources provided by a service provider network to implement desired functionality, such as to provide a network-based application or another type of functionality to an enterprise of users. While hyperscaler-based datacenters are growing in popularity, traditional enterprise-managed datacenters are still widely used. The combination of these deployments is usually described as ‘hybrid’ datacenters. Generally, remote users are able to connect to these network-based applications and/or enterprise functionalities using virtual private network (VPN) or proxy-based (ZTN) solutions. While there may be additional methods for remote users to connect to private enterprise applications, traditionally, VPN tunneling and reverse proxy technologies are among the most common. However, both approaches come with limitations. While VPN tunneling can work with any application and protocol, it can also open up a large attack surface within the network. Additionally, while proxy-based solutions allow for better edge controls, which results in a smaller attack surface, they generally don’t work well with protocols that are not transmission control protocol (TCP)-based, and require additional solutions to convert from a non-TCP protocol to a TCP protocol or to encapsulate the non-TCP protocol in TCP, which may impact performance of the proxies themselves, among other things. Further, proxy nodes executing proxy solutions serve as a middle box into a connection (e.g., a TCP or UDP connection) and allow clients to connect to a public internet protocol (IP) address while the backend processing may be performed on nodes not connected to public IP addresses. Proxies typically achieve this by taking incoming connections, terminating them, and opening new connections on the backend. While these proxying techniques are traditionally performed on the TCP and (user datagram protocol) UDP protocols, these same proxying techniques may be performed on the QUIC protocol. However, since the QUIC protocol utilizes UDP as the underlying transport, it may be difficult to handle failover or replacement of a QUIC proxy node and provide the seamless user experience provided by typical TCP or UDP proxies. Moreover, the QUIC protocol was designed to not interoperate with version unaware middle boxes. Additionally, QUIC can migrate sessions in a manner in which only the endpoint and the QUIC server may be aware of such a change. Finally, the Multiplexed Application Substrate over QUIC Encryption MASQUE) protocol provides a mechanism for proxying different types of protocols (e.g., HTTP proxying, DNS over HTTPS, QUIC proxying, UDP proxying, and IP proxying) using a single proxy solution. However, proxy protocols typically operate at the application / process layer. This means that each instance of an application, or different applications, from the same device will have a completely unique session with the proxy server. Accordingly, a user may be asked for authentication and/or authorization information each time an instance of an application or different application attempts to access the proxy server. Accordingly, it may be desirable to be able to bind disparate sessions together, coming from a common user on a common device at the server side so that it is possible to share a single Authentication / Authorization session across all disparate applications and proxy sessions from that same device and user. BRIEF DESCRIPTION OF THE DRAWINGS T