Internet DRAFT - draft-prodrigues-extar
draft-prodrigues-extar
Network Working Group P. Rodrigues
Internet-Draft 6 November 2022
Intended status: Informational
Expires: 10 May 2023
draft-prodrigues-extar-00
draft-prodrigues-extar-00
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 <CSP, tenantID> combinations allowed by the home
organisation.
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 10 May 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rodrigues Expires 10 May 2023 [Page 1]
Internet-Draft extar November 2022
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 . . . . . . . . 5
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. Multi-cloud organisation, E-XTAR . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.1. Proposed protocol adoption . . . . . . . . . . . . . . . 10
4.1.1. Verifying E-XTAR implementation . . . . . . . . . . . 11
4.2. Alternative attack vector: Upload portals . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Several organisations have been shifting their data and processes to
cloud environments (1). A subset of those will have granted their
colleagues work-specific devices, that they should only use to access
cloud tenants associated with their work in the said organisation
(2). One of the benefits of this is an enriched level of Data
Leakage Prevention policies, as there is a clear separation between
work and non-work environments. Additionally, the dynamics within a
single organisation, or even inter-organisation, have contributed to
the adoption of multi-cloud environments, that is, organisations
instantiating organisational tenants in multiple Cloud Service
Providers (CSPs) (3). The keyword there is "tenant". Employees/
colleagues can, rightfully, instantiate their tenants in those CSPs.
Rodrigues Expires 10 May 2023 [Page 2]
Internet-Draft extar November 2022
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 organisation-only devices (2).
This is done through a network proxy or firewall. This header
contains a list of allowed tenants/tenant IDs which is then used by
the Identity Provider on the CSP's side to emit, or not, a valid
authentication token.
The catch: This is not something that all CSPs have adopted. In
fact, to my knowledge, only one has a mechanism like such, 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 vendor-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 restricted
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 restricted device.
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 exfiltrate data from the
organisational tenant into a personal tenant.
Rodrigues Expires 10 May 2023 [Page 3]
Internet-Draft extar November 2022
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.6 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;
* 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:
Rodrigues Expires 10 May 2023 [Page 4]
Internet-Draft extar November 2022
* 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 <CSP,
tenantID> pairs (similar to the legacy protocol's header) or (2)
specify an endpoint for the target CSP to retrieve the allowed
list of <CSP, tenantID> 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 <letter, number> 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 work devices given to each employee;
* Due to data sensitivity, colleagues are restricted to access some
of these data and processes through their work devices.
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.
Rodrigues Expires 10 May 2023 [Page 5]
Internet-Draft extar November 2022
* 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).
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*:
Rodrigues Expires 10 May 2023 [Page 6]
Internet-Draft extar November 2022
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*:
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;
Rodrigues Expires 10 May 2023 [Page 7]
Internet-Draft extar November 2022
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
itself, 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 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
Rodrigues Expires 10 May 2023 [Page 8]
Internet-Draft extar November 2022
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, 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.
3.6. 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 <CSP, tenantID> 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.
Rodrigues Expires 10 May 2023 [Page 9]
Internet-Draft extar November 2022
*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 <CSP,
tenantID> pairs;
5. Organisation is multi-cloud ready.
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 E-XTAR
adoption and alternative attack vectors.
4.1. 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 these CSPs (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.
Rodrigues Expires 10 May 2023 [Page 10]
Internet-Draft extar November 2022
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.
4.1.1. 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.2. 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 would 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,
<https://www.rfc-editor.org/info/rfc5321>.
[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,
<https://www.rfc-editor.org/info/rfc6376>.
[rfc7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
Rodrigues Expires 10 May 2023 [Page 11]
Internet-Draft extar November 2022
[rfc7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
Acknowledgements
I am very grateful for the people around me that, knowingly or not,
incentivised me to learn and explore the subject and, eventually, to
work on this piece.
Author's Address
Patricia Rodrigues
Email: ytimyno@proton.me
Rodrigues Expires 10 May 2023 [Page 12]
