Network Working Group P. Rodrigues Internet-Draft 10 July 2023 Intended status: Informational Expires: 11 January 2024 draft-prodrigues-extar-01 draft-prodrigues-extar-01 Abstract The shift to multi-cloud environments brought data leakage prevention challenges for organisations. The current Cross-Tenant Access Restriction (XTAR) mechanisms do not cover critical scenarios where users can connect to multiple tenants (organisational and personal), facilitating data exfiltration. The goal, similar to previously proposed, reviewed and accepted protocols that have been published as RFC standards and are now widely adopted, is to help organisations keep their data under control when using one or more Cloud Service Providers (CSPs). This can be done by incentivising CSPs to adopt the proposed protocol, Extended-Cross-Tenant Access Restriction (E-XTAR), consisting of a globally readable header specifying the allowed combinations allowed by the home organisation. The work gathers scenarios contributing to the importance of a cloud-agnostic, universally embraced protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Rodrigues Expires 11 January 2024 [Page 1] Internet-Draft extar July 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Proposed protocol . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Single CSP organisation with no controls . . . . . . . . 6 3.2. Single-cloud organisation, network restrictions applied . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Single-cloud organisation, CSP XTAR & network restrictions applied . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Single-cloud organisation, CSP XTAR . . . . . . . . . . . 8 3.5. Multi-cloud organisation, CSP XTAR & network restrictions applied . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Edge Case: Multi-cloud organisation, identity federation, CSP XTAR & network restrictions applied . . . . . . . . . 9 3.7. Multi-cloud organisation, E-XTAR . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.1. Identity federation . . . . . . . . . . . . . . . . . . . 12 4.2. Proposed protocol adoption . . . . . . . . . . . . . . . 12 4.3. BYOD policies and authentication traffic . . . . . . . . 13 4.4. Verifying E-XTAR implementation . . . . . . . . . . . . . 13 4.5. Alternative attack vector: Upload portals . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Informative References . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Organisations' dynamic has evolved into a hybrid, multi-cloud setting (1). A subset of those will have granted their colleagues company- owned devices, the assumption often being, to access cloud tenants associated with their work in the said company (2). Segregation of business and personal environments, being a direct consequence of this, improves the level of Data Leakage Prevention (DLP) policies. Additionally, the dynamics within a single organisation, or even inter-organisations, have contributed to the adoption of multi-cloud environments, that is, organisations instantiating organisational Rodrigues Expires 11 January 2024 [Page 2] Internet-Draft extar July 2023 tenants in multiple Cloud Service Providers (CSPs) (3). The keyword there is "tenant". Employees/colleagues can, rightfully, instantiate their tenants in those CSPs. An approach that can be taken (and it indeed works in specific scenarios) is inserting a header in the authentication-related network traffic originating from the company-owned devices (2). The device itself, or a network proxy, injects custom CSP-specific headers either directly containing a list of allowed, uniquely identified, tenants or providing an indirect mechanism (look-up) to get such a list. The CSP, capable of interpreting its custom header, decides whether to emit or not, a valid authentication token. Looks at which tenant the user is trying to access and only issues a valid token if such a tenant is present in the list of allowed tenants. The catch: This is not something that all CSPs have adopted. In fact, to my knowledge, only a couple have such mechanisms, and, it, itself, has scope for improvement. This Internet-Draft exposes the need for the standardisation of a cross-tenant access restriction protocol and consequent adoption by CSPs. Take the widely adopted Sender Policy Framework (SPF - [rfc7208]), Domain-Keys Identified Mail (DKIM - [rfc6376]) and Domain-based Message Authentication Reporting & Conformance (DMARC - [rfc7489]) protocols that, together with the Domain Name Server (DNS (https://rfcs.io/dns)) protocol, help ensure the authenticity and integrity of electronic mail - related to yet another RFC-defined protocol: SMTP - [rfc5321]. A noteworthy characteristic of these, and other, protocols defined in standards is: They are optional. There is no central body enforcing the adoption of the standards. What has happened, and still is, is that the community itself is pressured to adopt certain standards to guarantee reliable Internet communication between services. We can follow a similar strategy for data protection, to secure organisational (potentially sensitive) data from exfiltration, this document suggests a cloud-agnostic protocol that consists of having a single header, interpretable by any CSP's Identity Provider, to verify if the authentication request is coming from a company-owned device and, if it is, only to emit an authentication token if the tenant being reached in that CSP is allowed by the home organisation, owner of the company-owned device. Rodrigues Expires 11 January 2024 [Page 3] Internet-Draft extar July 2023 Because we cannot guarantee every existing and new CSP will implement this sort of mechanism, the standardisation process incentivises it, and, if adopted by the CSPs and organisations, it restricts the attack vector where colleagues, intentionally or not, exfiltrate data from an organisational tenant into an external tenant (personal or B2B). 2. Background Organisations deal with sensitive data and therefore follow strict data governance rules. Many introduce data leakage prevention policies, which are eased or not fully effective on organisationally- owned devices (work devices), as these are usually within a corporate network and are trusted. As we will see from the Section 3, a multi-cloud organisation cannot block access to a whole CSP. And even in a single cloud environment, except for specific CSPs that allow/understand an XTAR mechanism to restrict access to specific tenants within that CSP, there is no widely adopted protocol to restrict access to specific tenants across CSPs. This appears to be essential when organisations are looking to have clear isolation between organisational and personal tenants. 2.1. Proposed protocol In Section 3, the Section 3.7 protocol accommodates scenarios of single- and multi-cloud organisations with the need to restrict access to organisational tenants within them. These organisations are assumed to have provided their colleagues with a corporate device that should only access organisational tenants. This approach is an extension of the approach taken by one specific CSP, which includes allowing an organisation to inject an optional header ("allowed-tenants-list") in the authentication-related network traffic destined for that CSP, which will then be read and interpreted by the CSP itself. This header will contain a list of organisationally allowed tenants (within that CSP). Once the traffic reaches the CSP's Identity Provider (the service granting the authentication token), the token will only be emitted if the tenant being accessed is present in the "allowed-tenants-list" network header. Limitations of this "legacy" protocol: * Adopted by a single CSP, hence not apt for multi-cloud environments; Rodrigues Expires 11 January 2024 [Page 4] Internet-Draft extar July 2023 * Allow list of tenants must be fully declared on the header, rendering management and configuration difficulties. The proposed protocol (E-XTAR) extends the legacy protocol as follows: * Instead of having a vendor-specific header, readable only by that specific CSP, introduce a new vendor-agnostic header "global- allowed-tenants-list"; * The new header can either (1) explicitly list all allowed pairs (similar to the legacy protocol's header) or (2) specify an endpoint for the target CSP to retrieve the allowed list of pairs; * The effectiveness of this proposed protocol is dependent on the wide adoption by CSPs; * This header would still be optional both for the organisation injecting it and for the CSPs that interpret it (organisational choice whether to fully restrict access to CSPs that do not implement the proposed E-XTAR verification based on the "global- allowed-tenants-list" header). * Taking the organisational choice to fully restrict access to CSPs that do not implement the proposed E-XTAR verification, diminishes the need to implement network restrictions. 3. Use Cases For the following use cases, letters are used to identify organisations and colleagues, numbers are used to identify CSPs and a combination of specified the tenant owned by the letter entity in the numbered CSP. Across the use cases, assume the base scenario: * The organisation has fully or partially migrated data and processes to the cloud (to a CSP); * The organisation has a Mobile Device Management (MDM) program to manage the company-owned devices given to each employee; * Due to data sensitivity, colleagues are restricted to access some of these data and processes through their company-owned devices. Rodrigues Expires 11 January 2024 [Page 5] Internet-Draft extar July 2023 3.1. Single CSP organisation with no controls Perhaps the most common, in this scenario the organisation's (lack of) controls allow an employee to connect from the work device both to the organisational tenant (using work credentials) and to personal tenants. * Organisation A has a single cloud environment on CSP 1, with tenant A1; * Employee B has personal tenants B1, also hosted in CSP 1, and B2, hosted in an alternative CSP, CSP 2; * Employee B can access tenant A1 with its organisational account; * Organisation A has no cross-tenant restriction (XTAR) mechanism in place. Because organisation A has no XTARs, employee B can access the organisational tenant A1 from the work device (expected) but it can also access both personal tenants B1 and B2 (malicious). Employee B can effectively download data into its work device from organisational tenant A1 and subsequently upload it to personal tenants B1 (hosted in the same CSP as the organisational tenant A1) and B2 (hosted in a different CSP). *Consequences*: 1. Colleagues have personal tenants in CSP 1 and CSP 2 and conduct data exfiltration to both. 3.2. Single-cloud organisation, network restrictions applied Following the previous use case, now consider that, because organisation A has a single cloud environment within CSP 1, it implements a network restriction that aids with XTAR: * Organisation A blocks any traffic going to CSPs other than CSP 1. In this scenario, employee B can still access tenant A1 from CSP 1, using its work device. Employee B will not be able to access its tenant B2 from CSP 2, as network traffic is blocked when trying to access CSP 2. However, employee B is still able to connect to personal tenant B1 (hosted in the same CSP as the organisational tenant A1). Rodrigues Expires 11 January 2024 [Page 6] Internet-Draft extar July 2023 The organisation cannot fully restrict network access to CSPs itself uses. So, if organisation A is using CSP 1, traffic to it will have to be allowed, at a network level. *Consequences*: 1. Colleagues cannot access personal tenants blocked by network traffic restrictions (these exclude organisational tenants' CSPs); 2. Governance and configuration effort to keep the network access restrictions up to date is required; 3. Colleagues that have personal tenants in the same CSP used by the organisation, can conduct data exfiltration to it. 3.3. Single-cloud organisation, CSP XTAR & network restrictions applied Further building on top of the second use case, consider that CSP 1 (used by organisation A and employee B), allows the organisation to insert metadata in the network traffic, specifying the list of allowed tenants within such CSP 1. * Organisation A blocks any traffic going to CSPs other than CSP 1; * Organisation A now inserts a header into the network traffic with destination to CSP 1, specifying the allowed tenant - tenant A1. Employee B can still access tenant A1 from CSP 1, using its work device. Employee B will not be able to access either personal tenants, B1 (XTAR implemented by injecting the network header) or B2 (network traffic is still blocked when trying to access CSP 2). Shortcomings of this approach include: * XTAR mechanism of including a list of allowed tenants is not widely adopted and can be improved according to the proposed protocol (in fact, only a single CSP seems to have such a mechanism, and the header is vendor-specific - as in, it is only understandable by that vendor); * Organisation A will not be able to collaborate or have a multi- cloud environment, or, if it does, it will not be able to introduce the same XTAR mechanism as CSP 1. *Consequences*: Rodrigues Expires 11 January 2024 [Page 7] Internet-Draft extar July 2023 1. Colleagues cannot access personal tenants blocked by network restrictions (these exclude the organisational tenant's CSP); 2. Governance and configuration effort to keep the network access restrictions up to date is required; 3. Colleagues cannot access personal tenants in CSPs where XTARs are applied; 4. Governance and configuration effort to keep these XTARs up to date is required; 5. Organisation A is not multi-cloud ready. 3.4. Single-cloud organisation, CSP XTAR Consider the scenario where organisation A is still single-cloud and decides to drop the network traffic to other CSPs restrictions, but implements its tenant's CSP's XTARs. This results in less strict access than the previous one but does reduce the Governance required. *Consequences*: 1. Colleagues can access any personal tenants hosted outside the organisation's own tenant's CSP; 2. Colleagues cannot access personal tenants where XTARs are being applied (organisation's own tenant's CSP); 3. Governance and configuration effort to keep these XTARs up to date is required; 4. Organisation A is not multi-cloud ready. 3.5. Multi-cloud organisation, CSP XTAR & network restrictions applied Changing the scenario to illustrate one of the shortcomings of the third use case: * Organisation A has a multi-cloud environment, using both CSP 1 and CSP 2, with tenants A1 and A2, respectively; * Organisation A blocks any traffic going to CSPs other than CSP 1 or CSP 2; * Only CSP 1 understands the XTAR mechanism where organisation A inserts a header into the network traffic with destination to CSP 1, specifying the allowed tenant - tenant A1. Rodrigues Expires 11 January 2024 [Page 8] Internet-Draft extar July 2023 Employee B can still access tenant A1 from CSP 1, using its work device. Employee B will not be able to access personal tenant B1 (XTAR implemented by injecting the network header). But because there is no XTAR mechanism understood by CSP 2 and organisation A cannot block network traffic to it (since it hosts an organisational tenant A2 in CSP 2). Employee B will be able to access organisational tenants A1 and A2, but it will also be able to exfiltrate data through its tenant B2, hosted in CSP 2. Even if CSP 2 had yet another vendor-specific XTAR mechanism, which is a plausible scenario in the current times, this would add to the governance and implementation effort. *Consequences*: 1. Colleagues cannot access personal tenants blocked by network restrictions (these exclude organisational tenants' CSPs); 2. Governance and configuration effort to keep the network access restrictions up to date is required; 3. Colleagues cannot access personal tenants in CSPs where XTARs are applied; 4. Governance and configuration effort to keep these XTARs up to date is required; 5. Being multi-cloud, and unable to apply XTARs to all the CSPs presents gaps: Employee B can access and exfiltrate data to any personal tenant that is both not network traffic restricted and has no XTARs applied; 6. Even if we can configure XTARs in all CSPs we use, there is an edge case emerging from identity federation. 3.6. Edge Case: Multi-cloud organisation, identity federation, CSP XTAR & network restrictions applied It's worth defining the below edge case to highlight a potential misperception of the tenant restriction's scope: Tenant restrictions are applied on the IdP' side. * Organisation A has a multi-cloud environment, using both CSP 1 and CSP 2, with tenants A1 and A2, respectively; * CSP 1 understands the XTAR mechanism XTAR 1 where organisation A inserts a header into the network traffic with destination to CSP 1, specifying the allowed tenant - tenant A1. Rodrigues Expires 11 January 2024 [Page 9] Internet-Draft extar July 2023 * Organisation A has configured identity federation, nominating CSP 1, tenant A1, to be the Identity Provider (IdP). To access both CSP 1 and CSP 2, the IdP is CSP 1, tenant A1. * Organisation A has only configured XTAR mechanism XTAR 1 (understood by the IdP tenant A1). Employee B can still access tenant A1 from CSP 1, using its work device. Employee B will not be able to access personal tenant B1 (XTAR implemented by injecting the network header). But we shall consider, which Identity Provider is employee B using for its own tenant? Consider the following cases following the scenario described above: 1. Employee B could have CSP 1 tenant B1 as its central IdP to manage access to tenant B2 on CSP 2; 2. Employee B could have CSP 1 tenant B1 as its IdP to manage access to tenant B1 on CSP 1 and CSP 2 tenant B2 as its IdP to manage access to tenant B2 on CSP 2; 3. Employee B could have IAM Service Provider 3 as its central IdP to manage access to tenants B1 and B2. Case 1, assuming Organisation A has configured mechanism XTAR 1 (understood by the IdP tenant A1), when employee B tries to authenticate to its tenant B2, using CSP 1 as the central IdP, the authentication flow will not go through and the token won't be issued (this is the expected, correct, behaviour). Case 2, assuming Organisation A has configured mechanism XTAR 1 (understood by the IdP tenant A1), when employee B tries to authenticate to its tenant B1, using CSP 1 as the IdP, the authentication flow will not go through and the token won't be issued. Issuance of the authentication token by CSP2 to employee B when accessing tenant B2, using CSP 2 as the IdP, depends if CSP 2, itself, supports a mechanism equivalent to CSP 1's XTAR 1. If not, B authenticating to personal tenant B2 goes through. Case 3, regardless of Organisation A having configured any kind of XTAR mechanism (understood by the CSPs 1 or CSP 2), when employee B tries to authenticate to its personal tenants, using any external IAM Service Provider 3, the authentication flow will go through and the token will be issued. B authenticating to any personal tenant using an external IdP that is out of the CSP's tenant restrictions' scope is successful. Rodrigues Expires 11 January 2024 [Page 10] Internet-Draft extar July 2023 This amplifies the need for a mechanism that is widely adopted, as the restrictions should be applied closer to the system performing the authentication and issuing the token. 3.7. Multi-cloud organisation, E-XTAR Now consider the implementation of the proposed Section 2.1, extended-XTAR (E-XTAR), following the scenario: * Organisation A has a multi-cloud environment on CSP 1 and CSP 2, with tenants A1 and A2, respectively; * Organisation A blocks any traffic going to CSPs that do not implement an E-XTAR verification based on the "global-allowed- tenants-list" header; * The "global-allowed-tenants-list" contains either (a) the explicit list of pairs that are allowed by the organisation or (b) the endpoint that should allow the destiny CSP to retrieve the (centrally managed) allowed tenant list. Employee B can access tenants any tenants, as long as these are specified either on (a) the "global-allowed-tenants-list" header explicitly or (b) on the allowed tenants list returned by the endpoint specified in the header. *Consequences*: 1. Network restrictions not required ("traffic only to CSPs that implement the E-XTAR mechanism, allowing header-based validation"); 2. Governance and configuration effort associated not required; 3. Colleagues cannot access tenants not allowed in the E-XTARs configuration; 4. Governance and configuration level of effort to keep E-XTARs valid is low-medium: Having to either (1) keep the "global- allowed-tenants-list" updated or (2) specify an endpoint that allows the target CSP to retrieve the allowed list of pairs; 5. Organisation is multi-cloud ready. Rodrigues Expires 11 January 2024 [Page 11] Internet-Draft extar July 2023 4. Security Considerations The proposed mechanism aims to prevent data exfiltration via the attack vectors specified. Current implementations (and non- implementations) of XTAR are exploitable. E-XTAR aims to make it harder to exploit but requires us to consider factors, such as identity federation, E-XTAR adoption, Bring Your Own Device (BYOD) policies, authentication mechanisms and alternative attack vectors. 4.1. Identity federation The restriction must be applied at the identity provider (IdP) level. Whichever vendor/CSP is being accessed, the authentication can happen against a range of external identity providers that include other CSPs and identity platforms' IAM products. When applying a tenant restriction mechanism, it shall be applied close to the IdP, where the authentication is happening and the token is being issued. An example of this scenario is depicted in Section 3.6. 4.2. Proposed protocol adoption A CSP/CSP-like service might not adopt the protocol here proposed. To make sure E-XTARs configurations are validated, the organisation can: * Deny traffic to CSPs that do not implement the proposed protocol (via network restrictions); * Or (preferably) have a verification step in the protocol. As the authentication request into a CSP is made with the proposed, globally readable optional header, the complete authentication process is only completed if we know for sure that the target CSP has adopted the protocol. Elaborating on the latter the organisation would have a choice of only allowing traffic to CSPs that have adopted E-XTAR. This could be done by (i) having a central authority maintaining a list of CSPs that adopt the proposed protocol (verification process and management overhead needed) or (ii) implementing a mechanism that verifies if the CSP is adopting and implementing E-XTAR, independent of a central authority. Rodrigues Expires 11 January 2024 [Page 12] Internet-Draft extar July 2023 4.3. BYOD policies and authentication traffic All mechanisms presented here mostly rely on intercepting devices' modern authentication traffic, in some cases, even accessing the device's admin configuration itself. They, therefore, cannot be applied to personal devices, most of the time. 4.4. Verifying E-XTAR implementation To achieve a mechanism that thoroughly verifies if the CSP is adopting and implementing E-XTAR, without relying on a central authority, perhaps a challenge-response mechanism, through which the target CSP can prove that it is implementing the proposed protocol, is worth considering. 4.5. Alternative attack vector: Upload portals One can consider an actor to create an internet-accessible upload portal (not recognised by typical website classification tools), where it can upload data from its corporate device into it, effectively exfiltrating data from an organisation. This is an attack vector achievable now and not covered by the protocol. To tackle this, we always rely on Data Leakage Prevention mechanisms. Alternatively, would need a per-website allow-list, which may be hard to achieve in very dynamic organisations. Plus it includes management overhead. 5. IANA Considerations This document has no IANA actions. 6. Informative References [rfc5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [rfc6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [rfc7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . Rodrigues Expires 11 January 2024 [Page 13] Internet-Draft extar July 2023 [rfc7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . Acknowledgements Thanks to the people who helped in the learning and exploring of tenant restrictions. Author's Address Patricia Rodrigues Email: patriciarodrigues@protonmail.com Rodrigues Expires 11 January 2024 [Page 14]