OGC Testbed-16: Federated Security

Figure 4 shows the architecture defined in Figure 2 cast into a data flow diagram. This diagram identifies all actors and interactions when a Federation Member authenticates to a Federation Service using OIDC.

Following the configuration shown in Figure 2, the Federation Service is shown behind the Fed Service Trust Boundary, along with the OIDC Server, Fed State, and the Fed Operator. A Member (and their browser) and a Service are shown behind their own Trust Boundaries. All dashed items are considered to be out-of-scope for the analysis documented in this ER. The Service, the Service Request and Response arrows are shown as out-of-scope since they are not involved in the authentication process. All other dashed actors and interactions are considered to be secure because they are behind the Fed Service Trust Boundary.

While this assumption may be flawed, it is based on currently established and accepted security practices, such as "securing" service endpoints by operating them on a different, internal subnet. Newer architectural approaches that do not require such assumptions are reviewed in Emerging Security Technologies.

As per the OIDC specification, the numbered arrows indicate the OIDC Authorization Grant Flow, the primary flow used by most applications to achieve authentication. (While this flow is called authorization, the first step is to establish identity, i.e., authentication.) When a Member asks to be authenticated (1), the Fed Service redirects the request (2) to the OIDC Server. The OIDC Server challenges the Member to authenticate (3) which the Member responds to (4). On success, the OIDC Server redirects back to the Fed Service (5) with a short-lived Authorization Code and a "state" value. The Fed Service uses this code to request an Access Token from the OIDC Server (6). The Access Token and ID Token are returned (7). These are JSON Web Tokens (JWTs). JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object (jwt.io). The Access Token can be used to request further information about the Member (8 and 9). Finally, the results of the authentication are returned to the Member (10).

There are two very important security aspects to this protocol. First, the Member does not divulge any secrets to the Fed Service. That is to say, the Member authenticates directly with OIDC. This could be simply by using account name and password, multi-factor authentication, biometrics, or other methods. Second, no tokens or other credentials are divulged to the Member. The Access and ID Tokens are exchanged directly between OIDC and the Fed Service. By having OIDC act as a trusted, third-party, the Member and Fed Service do not have to directly exchange any secret information.

A threat analysis of this protocol is not trivial. However, an extensive threat analysis has been performed for OAuth 2.0 [26]. Since OIDC is essentially an integration of OpenID and OAuth 2.0, this threat analysis can be applied here. Threats and mitigations identified in [26] are cited as such in the Threat Dragon report.

Threat Analysis Summary and Discussion:

The analysis described focuses solely on those actors that have externally accessible endpoints and the interactions between them. That is to say, this analysis focuses on interactions that cross trust boundaries. For the purposes of this analysis, the endpoints and interactions that are completely behind a trust boundary, i.e. within a trust zone, are considered to be secure.

Also, while some Denial of Service (DoS) attacks are considered here, DoS attacks against the communication bandwidth between a Member and any part of the Fed Service are considered out-of-scope. There is nothing federation-specific about such attacks. Such attacks can be mitigated without requiring any structural or behavioral changes to a Fed Service.

With these ground rules in mind, the threat analysis recommendations can be summarized as follows:

While very insightful, these threats and mitigations emphasize the fact that such analyses must be done by individuals that have a first-hand knowledge and understanding of how RESTful web services are built and how they work. For example, understanding the Cross Site Request Forgery vulnerability means knowing exactly how the redirection protocol works, and more importantly, how the protocol could be misused. Also, a threat analysis for any system should be done against specific implementations. Different implementations of the same standard could have different vulnerabilities. For example, under extreme malicious loading conditions, a service may commit a synchronization error that allows a response to be returned to the wrong requestor. For all these reasons, any serious analysis to identify threats and effective mitigations must be done for a specific implementation and deployment, staffed by knowledgeable persons, and properly funded.

In this scenario, a federation Member has already been authenticated to the Fed Service. As illustrated in Figure 5, Members are being considered that are FedAdmins and ResOwners as they perform administrative functions. Only the Member Browser and the Federation Service are involved with a single pair of request and response interactions. This threat analysis applies to both FedAdmins and ResOwners since the threat model is structurally the same. A FedAdmin makes requests to the FedService to manage a federation’s members, e.g., to grant or revoke authorization attributes. A ResOwner makes requests to register service endpoints and manage the associated discovery and access policies.

Threat Analysis Summary and Discussion:

This threat scenario is clearly much simpler than the authentication process. Since the members are already authenticated, the enables the FedService to associate the member with a trusted set of authorization attributes. Aside from mitigating possible DoS attacks on either the Member or the Fed Service, the key security goal is to mutually secure the communications between them, e.g., to use mTLS. While this is an entirely reasonable approach, the next question is what are the threat vulnerabilities of TLS and mTLS? This is discussed in Threat Analysis Observations.

In Figure 6, members that are general Users are considered. Again, these Users have already been authenticated to the Fed Service for a specific federation.

General members can perform two functions: (1) query the federation’s Service Catalog, and (2) invoke a Service. A federation’s Service Catalog is maintained by the Fed Service. In response to a query, the Fed Service first applies the discovery policies defined by the ResOwners. The Fed Service then replies with a set of service metadata that (a) the User is authorized to discover and invoke, and (b) meets the User’s query parameters.

The User can then invoke one of these services. In this deployment model, the Fed Service proxies the call thereby allowing the Fed Service to apply the Service’s access policy. Upon granting access, the request is sent to the Service. The Service processes the request and sends a response which is forwarded to the User.

Threat Analysis Summary and Discussion:

Threats to the interactions between general Users and the FedService are essentially the same as they are for FedAdmins and ResOwners. In this threat analysis, however, Services finally come into the picture. Services never ask the Fed Service for anything. Services simply respond to requests. As before, while DoS attacks are possible and can be mitigated, the key security goal is to mutually secure the communications between the Service and the Fed Service.

The previous three threat scenarios have all dealt with a single Federation Service and its interactions with Members and Services. Figure 7 presents a final scenario that illustrates the interactions between two Federation Services.

As noted, each Fed Service can make requests to the other. As before, doing this securely depends on securing the communication channel. Fed Services do not authenticate to each other in the same way that Members authenticate to a specific federation. However, there does have to be a trust relationship between them, as part of the trust relationship between the organizations involved. Once this trust relationship has been established, the Fed Service Operators can configure their respective Fed Services to accept a connection from each other.

Threat Analysis Summary and Discussion:

As part of this simple deployment model, the identity of the Fed Services involved is being established out-of-band. Aside from mitigating possible DoS attacks, as before, the key security goal is to mutually secure the communication link between the two Fed Services.

Identity proofing is the process of verifying who a subject or applicant is when first establishing them as a valid subscriber in an identity system. To be more concrete, this is when a Credential Service Provider (CSP) associates an applicant with a digital identity that is documented with one or more digital credentials.

The NIST Digital Identities Guidelines [4] defines three Identity Assurance Levels:

These Identity Assurance Levels can all be applied in federated systems.

When authenticating a user or claimant, the claimant must demonstrate that they possess and control one or more authenticators, such as a username, credential, token, etc., that are used to prove their identity. The use of a single authenticator, such as account name and password, has been common for decades. However, stronger security can be achieved by using multiple authenticators in conjunction, such as Multi-Factor Authentication (MFA).

Authenticators can be broadly categorized into:

A common MFA approach uses account name and passcode, in conjunction with an RSA fob that presents a PIN code with limited time validity, for example 60 seconds.

The NIST Digital Identities Guidelines [4] defines the following Authenticator Assurance Levels:

While all of these authentication methods and Authenticator Assurance Levels can be applied in federated environments, federation raises the additional possibility of federated identity management. Federated identity entails the ability of a user to use identity credentials issued by an Identity Provider (IdP) in one domain to access resources in another domain. Doing this, however, depends on credential management and trust. This leads to the next discussion topic.

Managing the use of credentials across identity domains, and the identity attributes that might be carried on them, i.e., released, is a significant issue in federation. To give some structure to this issue, the NIST Digital Identity Guidelines [4] define three Federation Assurance Levels. These refer to the strength of an identity assertion issued by an Identity Provider (IdP) in a federated environment when communicating that information to a Relying Party (RP):

While these assurance levels are useful, the added dimension of federation that must be emphasized is that the RP and IdP will be in different identity domains.

A key function of a federated environment is to enable an RP in one domain to trust and understand the credentials issued by an IdP in another domain. The RP must trust that the credential:

Once this trust is established, the RP must have a common understanding about what the identity attributes mean, such as how they can be used to evaluate an access policy and make a valid access decision. A fourth requirement can be added from the User’s perspective:

Item (a) above requires a credential belongs to a user. Please note, however, FAL1 is based on the concept of a bearer assertion. This is something the user or subscriber (the bearer) presents to the Relying Party as sufficient proof of identity. Bearer assertions, or bearer tokens, are vulnerable to man-in-the-middle or snooping attacks, and simple device theft. If an attacker acquires a bearer token, by any means, they attain all the rights of the legitimate user.

The need to avoid the limited security offered by bearer tokens and achieve the three trust requirements described above has motivated the development of various security architectures, such as Public Key Infrastructure (PKI) [28]. PKI utilizes a Certificate Authority that issues signed and encrypted certificates that are only valid for the intended subject. PKI is widely used with the established X.509 certificate format [29]. When a User requests service and presents a certificate, the RP can verify the certificate with the Certificate Authority. Importantly, this type of approach also addresses Items (b) and (c).

While PKI is widely used and considered quite secure, another design concept that increases security even further is to not divulge credentials directly to the user at all. PKI certificates can be directly installed on a user’s browser or device. As discussed in A Threat Analysis of Authentication to a Federation Service, OpenID Connect (OIDC) [30] avoids doing this. When a User requests service from an RP, the RP can redirect the User to authenticate directly to an OIDC Provider (OP). On successful authentication, the User is redirected back to the RP with an authorization code. The RP uses this code to get an ID Token and Access Token directly from the OP. The User never sees their ID and Access Tokens, and has no control over them.

This architectural approach for OIDC, however, was actually developed to support Federated Identity Management (FIM). On the surface, the goal of FIM is to enable a User A from Organization A to access resources at Organization B using their identity credentials from Organization A. However, the market-driven usage scenarios that motivated this, however, were quite limited in scope. One example is enabling a User’s Facebook account to access photographs on the User’s Snapchat account. This does require that Snapchat trusts the User’s IdP and having the User authenticate to approve the access by Facebook.

While there is certainly a mass-market use of federated identities, it is far from a general federation capability. First, it assumes that a User knows about and can invoke any service that is available on the Internet. There is no notion of a Service Owner being able to manage the discovery of their services through policy. The Service Owner must determine where the User is coming from, and who is the User’s IdP. The Service Owner must then determine if they know and trust the IdP. Usually this means that Service Owner must maintain a list of IdPs that they trust. When making a service request, the User must select an IdP from the Service Provider’s approved list — which hopefully includes the User’s IdP. Even when this is done, there is no guarantee that the User’s IdP can provide the attributes necessary for the Service Owner to make an access decision. This may be because the IdP does not know or understand what type of attributes are being requested, or because the IdP does not wish to release those attributes for some organizational reasons. For all of these reasons, simple FIM is insufficient for managing general federations.

The NIST CFRA addresses all these issues by enabling "purpose built" federations to be defined and instantiated. By considering a federation to be a virtual administrative domain, it is possible to manage membership in a federation, along with the roles, attributes and policies necessary to manage its operation. That is to say, defining the "rules of the road" for members and establishing an expectation of what it means to be a member in good standing is possible. There is no question about what the roles and attributes mean, or how they are used by the federation’s service owners. What the NIST CFRA does is provide a scoping mechanism whereby existing authentication and authorization tools can be leveraged to instantiate any number of federation instances. These instances can be independently managed according to their own governance requirements.

The issue of attribute release — Item (d) above — has already been mentioned several times. This is a significant issue for many existing federation systems and is examined here in more depth.

While thinking of a credential as documenting everything there is to know about a User is easy, an RP may only need one or two attributes to make a decision. Aside from not sending extraneous information, there may be attributes that a User (or their organization’s IdP) may not want to divulge to an RP that does not need to know. In a single domain, attribute release is less of a problem since information is "all within the family", i.e., the same trust domain. In a federated environment, however, attribute release becomes more of an issue and must be explicitly managed.

When an organization is must managing their own environment, the attributes used and how they are encoded into credentials is typically not an issue. However, if such an organization — or some subset of their users — later wishes to federate with another organization for any purpose, their IT security architecture was probably not designed with this use case in mind. From an organizational governance perspective, they may have been unprepared to share identity attributes with other organizations, of rather, undecided about how to do so. Organizational IdP administrators may be faced with competing requirements concerning how to expose attributes to external RPs. The only tractable solution for many administrators will be to release nothing.

The NIST CFRA avoids this problem by defining a virtual administrative domain where attribute release is simply not a problem. The goals and purpose of a federation are well-defined. Hence, the attributes and how they are used are well-defined. The necessary attributes to make discovery and access decisions are well-defined. This means their release can also be well-defined.

There are, however, other ways of addressing the attribute release issue that could also be used in federated environments. The approach taken by W3C Verifiable Credentials [13] enables the user to directly control their credentials and how attributes are released. This design approach is illustrated in Figure 8.

While Issuers (IdPs) continue to issue credentials to Holders (Users), the Holder maintains all of their credentials in a repository that can be called a wallet (not illustrated). Credentials are only valid for a specific subject, which may the Holder but could be another entity associated with the Holder. When requesting service from a Verifier (Relying Party), the Holder creates a custom credential presentation built from any of the credentials in their wallet. Hence, the Holder has complete control over their attribute release when interacting with Service Providers. The credentials and presentations are constructed and signed such that they can be verified through a Verifiable Data Registry. Hence, Verifiable Credentials are not bearer tokens, even though they can be used as bearer tokens by leaving the subject field in a credential presentation empty.

Verifiable Credentials (VCs) handle credentials in a way that is very different from third-party IdPs. VCs were deliberately patterned to work the same way as physical credentials. A typical person will have a wallet with physical credentials, such as a Driver’s License, credit cards, auto club card and so forth that can be presented for identification and receive services. Of course, all this depends on a set of public Issuers that can be consulted to verify credentials. Hence, VCs are a close parallel to how humans go about their business right now. For this simple reason, VCs might gain market adoption in the coming years.

However, this design approach also makes it difficult for controlling how a user may use their credentials in subsequent presentations. For many application domains, after granting a credential, the Credential Issuer may wish to stipulate that the User may only use the credential in presentations to entities on an approved "white list", and must never use them in presentations to entities on a "black list". Such requirements are not known to be handled at this time.

The VC approach to credential management is actually quite compatible with the NIST CFRA approach to federations. A fundamental tenet of the CFRA model is that a federation is a virtual administrative domain whose governance should be defined and agreed upon by the potential members prior to instantiation. That is to say, the policies used to manage resource discovery and access are defined over a set of common, well-known attributes. In the VC case, these attributes can be provided by public issuers. The members simply need to agree on the Issuers and attributes to be used. A Federation Service, however, will still need to maintain a service catalog for each federation whereby discovery policies can be enforced. Likewise, some form of Policy Decision Points and Policy Enforcement Points would have to be used whereby access policies can be enforced.

These architectural concerns for managing identity, credentials, and the attributes they carry, are certainly important. However, these mechanisms must be deployed in conjunction with trust and understanding, i.e., semantic interoperability.

Trust can be broadly categorized in a hierarchy [32]:

The bottom two layers in this hierarchy can be termed computational trust. For most systems, establishing computational trust means that a set of requirements have been satisfied. Depending on the use case scenario and the stakeholders' risk tolerance, that necessary set of requirements will vary. In any case, trust can be said to be a binary, yes/no decision. (While reputation systems have been devised to manage varying degrees of trust, these are out of scope for this engineering report.) This ER chapter explores what trust requirements may be for federated systems and how they can be realized.

The hierarchy above can be further refined into the concept of trust models [33]. Linn, et al., define the notions of Business Anchor and Trust Anchor. A business anchor "represents an entity with which its holder has a direct business relationship." That is to say, some type of business agreement has already been established between two human organizations. A trust anchor "represents an entity and key that the anchor’s holder has determined to trust directly for cryptographic authentication purposes." This allows two organizations "connected" by a business agreement to establish trusted electronic communications based on cryptographic methods. Human organizations can maintain Business Anchor Lists and Trust Anchor Lists whereby sets of trust relationships can be managed. Based on these concepts, trust models can be categorized as follows:

In practical scenarios, these trust models need to be managed in the context of a trust framework. This is especially true for brokered/transitive trust and community trust where establishing paths of trust chains or community trust requirements must be managed.

To this end, Temoshok and Abruzzi present a guide for developing trust frameworks for identity federations [11]. While focusing on identity federations, this guide is directly relevant to general federations, as defined by the NIST CFRA. As the basis of authentication, this work takes the approach of OIDC (as illustrated in the Threat Dragon models). When a User requests service from a Relying Party, a pair of redirections is used whereby the User authenticates to the IdP, and the IdP provides the authentication status directly to the RP. The NIST CFRA augments such identity federation by integrating it with resource federation. That is to say, the resources in a federation are managed according to discovery and access policies based on the identity roles and attributes that are well-known within a federation. Hence, this ER section extends the trust framework approach presented in [11] to general, CFRA-based federations.

NIST Trust Frameworks govern the interactions among three main actors:

A Trust Framework encompasses a set of rules governing how:

To accomplish this, a Trust Framework is comprised of four components:

In [11], these components are discussed specifically for identity federations. Their implications for general federations are now considered.

Trust is an immense subject. Trust frameworks and their approaches are an equally immense subject. There are, however, several tools and efforts being developed. These directly support the formal definition of general federations, their legal structure, and the establishment and evaluation of conformance. Such tools are necessary for creating secure and trustworthy federations.

An example of how OIDC could be integrated into an API Gateway as a candidate implementation approach for the NIST CFRA was given in Appendix B.2 of the CFRA [1]. This model was also used for the CFRA threat analysis presented in A Federation Service Threat Model and Analyses which was, in a large part, a threat analysis of OIDC. This development was motivated by the increased use and market adoption of OIDC. In recognition of the increased importance of federation, the OpenID Foundation has also developed the OIDC Federation Specification, v1 [47].

The OIDC Federation Specification enables two OIDC Providers (OPs) to establish a trust relationship. This is done by enabling the two OPs to determine that they have a common Trust Anchor, which is simply a trusted third-party. This determination is made by resolving a Trust Chain.

Since the OIDC Federation Specification is an additional capability that can be added to existing OIDC Providers, it perfectly dovetails with the API Gateway/OIDC example of a Federation Service (Federation Manager) as presented in [1]. Figure 12 illustrates how the OIDC Federation Specification can be used to support NIST CFRA-based federations.

Here we see that the OIDC Fed Spec adds two new endpoints to the OIDC protocol: The federation API endpoint and the federation registration endpoint. In this example, Site B wishes to federate with Site A. OP A’s federation API endpoint is initially discovered using the site’s well-known OIDC URI. Site B uses the federation API endpoint to fetch an entity statement containing metadata about Site A. This statement will contain a list of intermediate entities. At this point, Site A and Site B may negotiate trust. This simply means that Site A (the OP) may tell Site B (the RP) what operations, scopes and claims the Site B would be allowed use if a specific Trust Anchor was used.

Site B will make a sequence of such calls to intermediate federation API endpoints until a Common Trust Anchor is found, all possible intermediates have been examined, or a maximum path length of intermediates has been hit. This is illustrated by the sequence of (1), (2), and (3) arrows. At each step of this process, JSON Web Key Sets (JWKSs) are exchanged whereby the entities in the trust chain can be validated. If no Common Trust Anchor has been found, trust has not been established. If more than one Common Trust Anchor has been found, then Site B must choose one to use.

Once this is done, the Trust Anchor can be used to exchange JWKSs allowing each side to encrypt and sign messages. Upon receipt of a message, the recipient has the proper keys to verify the identity of the sender and decrypt the message. One of the first such interactions is for Site B to register with the Site A OP as a client using the federation registration endpoint. This will enable Site B to verify the credentials of a Site A federation member when that member is requesting access to a Site B resource.

As extensively described in the NIST CFRA, Federation Managers (Federation Services) must exchange information through their CFRA FM endpoints. This is to ensure a consistent presentation and operation of hosted federations to the members regardless of which Federation Managers the member is using to access the federation. The OIDC community has recognized a very similar need for OPs to exchange information for a variety of reasons. Developing a standard capability for this is the charter of the OIDC Shared Signals and Events (SSE) Working Group [48]. This kind of signaling capability could be directly adopted in Federation Service implementations.

The SSE WG is developing an Event Stream Management API [49] whereby an Event Receiver can control how an Event Transmitter generates events. This is a straight-forward API enabling a Receiver to:

This basic API was developed to support several specific requirements:

These are all capabilities that could be used in CFRA-based implementations. Moreover, as mentioned above, the Federation Services must exchange information on all the hosted federations to ensure their proper and consistent operation. Hence, such a signaling capability could be used to:

Other uses could be possible, depending on how the FSs are implemented and how the federation semantics must be managed. While this Event Stream Management API was developed to support identity operations in an OIDC Provider, it clearly had broader applicability. An outstanding issue then is to determine how such a signaling capability could be properly integrated to support both the OIDC Provider and the Federation Service requirements as a unified whole.

While the Common Trust Anchors in the OIDC Federation Specification are implemented as software services, the same concept of a root of trust can be implemented in hardware. As defined by the Trusted Computing Group [12], the Trusted Platform Module (TPM) has an Endorsement Key (EK) which is burned into the hardware by the manufacturer. This Endorsement Key consists of a public and private key pair. There can also be an EK certificate that is issued for the EK public key. Either the EK public key or the EK certificate is used to establish trust with a Certificate Authority.

TPMs have multiple functions, such as performing cryptographic operations, computing hash functions, key management, but also integrity measurement and attestation. At load-time, the TPM can use a hash function to uniquely identify a binary executable, and even its input data. That is to say, the TPM can establish code identity.

This capability can be used to build Attestation Architectures. In an Attestation Architecture, a remote relying party wishes to verify that a target system is intact, i.e., it has not been modified from a known, trusted state, and hence, is trustworthy. Upon an attestation request, the target system TPM will generate a certificate identifying the state of the software that is currently running. If this is not identical to the load-time certificate, a change has occurred.

Such attestation architectures can be used in virtualized, cloud environments. A cloud will have multiple virtual machines running on one physical machine. While there is only one hardware TPM on the physical machine, each virtual machine can be supplied with a virtual TPM (vTPM) [50]. As far as the VM is concerned, the vTPM behaves exactly like a hardware TPM. Hence, it is possible to make an attestation request for just the VM. However, it is also possible to do a deep attestation that assesses the state of the VM, its hypervisor, and the host OS — all the way down to the hardware TPM.

Attestation can also be done for containers. The TapCon system [51] is an attesting container manager built on Docker. This solution can provide source-based attestations of the containers it launches. TapCon can also provide attestations of container provenance back to a trusted container repository.

TapCon supports layered attestation in cloud environments from containerized services, to virtual machines, to hypervisors, etc. Technically speaking, TapCon can use a TPM hardware root of trust, but can also root trust in a software-based cloud provider or a code repository.

The fact that such attestation architectures are based on a relying party that is remote from the target system has prompted the development of a Remote Attestation Procedures Architecture (RATS) [52].

The RATS conceptual architecture is shown in Figure 13. Here, an Attester provides evidence to a Verifier. The Verifier can also take endorsements from an Endorser. In practice, such endorsements could simply be the manufacturer vouching for the device’s signing capability. The Verifier Owner defines the appraisal policy for the evidence, on which the Verifier bases the attestation results. Such appraisal policies might include recognizing the manufacturer’s endorsement of the device and verifying the format of the evidence received, but ultimately results is a decision of compliance or non-compliance. Finally, the Relying Party Owner defines the appraisal policy whereby the Relying Party can evaluate the attestation results. While this appraisal policy might be simply based on the code’s compliance status, it might also involve more detailed information about the Attester and the attestation environment, such as who the manufacturer is.

This high-level architecture is further developed for different target environments and attestation environments, along with different topological models. In the Passport Model, the Verifier provides the attestation results to the Attester, which the Attester can present to the Relying Party, i.e., as a "passport". In the Background-Check Model, the Attester provides all evidence to the Relying Party, who then passes the evidence to the Verifier. The Verifier does a "background-check" and returns the attestation results to the Relying Party. The format for all message exchanged in an attestation can include JWTs, CWTs, X.509 certificates. The root of trust for these tokens/certificates can be software or hardware-based, i.e., TPM.

Hardware Roots of Trust enable a specific version of software to be given a unique identifier, i.e., an identity. Attestation is the process of verifying that identity. This is not unlike that of establishing a user’s identity in order to make an access decision.

Figure 14 illustrates how attestation evidence might be collected in a federated environment. Here, a Service A is running on some physical server with a TPM. Service A could be running in a VM (as illustrated here with a Host OS and Hypervisor), but could also be in a container. Service A has been registered in the Service Catalog of Federation K by Service A’s owner. Service A’s owner also has a Service A Attester running on the same physical machine that is also registered in the Service Catalog.

In this example, the Verifier is a member of Federation K that has the authorization to make attestation requests of Federation K services. That is to say, the Verifier can discover all attestation services in the Federation K Service Catalog and invoke each one to verify the service’s code identity. Such an attestation is illustrated by the red line in Figure 14.

Note that the Service A Attester could attest for any other services hosted in that VM. Also, a Verifier could have the authorization to request attestations at any site in the federation. Furthermore, there could be multiple Federation K members that have the authorization to do attestations.

Once the Verifier has collected the evidence, there are other entities and steps involved. In the RATS model, the Verifier might receive Endorsements, typically from the manufacturers. The Evidence Appraisal Policy might be defined for the entire federation or might be Attester-specific. This is another governance issue that could be decided on a federation-by-federation basis. The Relying Parties could possibly be any other federation member that wishes to verify the integrity of a service before using it, including a Fed_Admin. The Relying Party Owners could certainly define their own Appraisal Policies for the attestation results.

Trust is the final issue that must be addressed. In the typical attestation architecture, the Verifier trusts the attestation evidence because it is signed by a TPM whose key is certified by a trusted PKI Certificate Authority. In this example, when the Service A Attester is registered in the Service Catalog, the OIDC Provider could also issue an ID Token for the Attester and the TPM the Attester uses. When an attestation is done, the Verifier validates the TPM ID token with the issuing OIDC.

This conceptual architecture indicates that attestation could be done in federated environments. The next question is how federation could leverage the significant adoption that Trusted Computing has had in the marketplace. Major chip manufacturers, such as Intel and AMD, include TPM hardware. Microsoft Trusted Computing includes TPM support in Windows 10, Windows Server 2016 and Windows Server 2019. Microsoft’s IOT Hub Device Provisioning Service supports TPM-based attestation. Google Compute Engine can provide Shielded VMs that have an attached vTPM. All of this implies that if general, standards-based federation tools were adopted, then existing hardware-based attestation mechanisms could be brought to bear within federations.

The definition of non-repudiation essentially says two parties to a transaction cannot later deny that the transaction took place. In IT systems, such transactions are always the exchange of information. Federations are clearly dependent on the exchange of information that is understood to be shared and trusted.

Blockchain is a technology whereby such trusted information can be established with non-repudiation. Rather than rely on securing the channels and sessions between partners, the Blockchain approach creates an unforgeable record of the data and the data exchange transactions among users. A Blockchain [53] is a replicated ledger that uses cryptographic techniques and consensus algorithms to build trustworthy systems in an otherwise trustless world.

Figure 15 illustrates the Blockchain concept. A Blockchain is simply a chain of blocks, or data structures. Each block contains a cryptographic link to the previous block. The beginning block is the root block. Each block consists of a header and content. The header contains a link to the previous block, a time stamp, and a Merkle hash value. This Merkle hash value is the value of the Merkle hash tree. This is a tree of one or more application messages. The Merkle hash value is cryptographically linked to the entire contents of the tree. The upshot is that by cryptographically replicating the ledger among participants, fraudulent information and transactions can be identified and rejected.

The Blockchain "magic" happens in how new blocks are added to the chains; i.e., how a consensus algorithm is used to establish agreement among participants for adding a new block. Proof of Work is the most common consensus mechanism used in Blockchain implementations. This proof of work in early Blockchain implementations required Blockchain miners to experimentally determine which cryptographic nonce makes the hash of its current header fit the current target. Proof of Stake gives advantage to those miners that have a larger stake in the Blockchain ecosystem. The Practical Byzantine Fault Tolerance (PBFT) algorithm provides a lower latency mechanism where arriving messages are signed, and if enough identical messages are received, then consensus is achieved. As such, these consensus algorithms as well as others have very different performance characteristics.

So how can a Blockchain be used in federations, and specifically CFRA-based federations? The answer to this question depends on the federation deployment model used. The deployment model that is expected to be commonly used entails P2P Federation Services where the Service Catalog, service discovery policies, and authorization attributes are replicated among the FSs. Service Owners have the authority to make a resource available in a federation. This includes all metadata concerning the resource, e.g., the URL, structure of the request/response data, and resource discovery policies. Authorization attributes can be defined by the Fed Admin(s). All of this information must be replicated and trusted among the Federation Services. This could be accomplished by posting any changes to the Service Catalog or attributes to a Blockchain. The Federation Services could even run their own private Blockchains for this purpose. Federation Services could even offer private Blockchain services to the federation instances they are hosting, to be used by the federation members to establish trusted information within any given federation. Hence, the use of Blockchains in federation is a very interesting possibility, but does entail the resolution of many issues, including consensus algorithms, performance, and block data size.

The ZTA approach is to enable a "protection boundary" to be placed around any set of enterprise resources, large or small. Any such set of resources is called a zone of implicit trust. Everything between such implicit trust zones is considered to be untrusted, including the network, regardless of whether it is the local, enterprise network or the Internet. The ZTA design philosophy is to make these trust zones as small as possible, i.e., to make protection as fine-grained as possible.

These concepts are embodied in a set of ZTA design tenets in [14]. Each of these tenets has distinct implications for the implementation, deployment and use of ZTAs. Hence, we follow each of these tenets with an Interpretation and discussion of Implications (I&I):

I&I 1: This enables system designers to identify any number of system components or groups of components and protect them individually. How big or small these groups are depends on the system designer’s decision as to what needs protection and the overall risk tolerance.

I&I 2: All data must be encrypted when it exits a trust zone. Since all communication outside a trust zone is assumed to be untrusted, the assumption is that anybody can see the data. However, only legitimate recipients can decrypt the data and validate the identity of the sender. From an implementation perspective, this implies that any recipient must have the proper keys to decrypt the data and validate the signature. This implies that there must be a method for secure key distribution.

I&I 3: This implies that access decisions need to be made. Making access decisions also implies that there are access policies for each resource, and a mechanism for evaluating these policies. Rose, et al., use the common term Policy Enforcement Point (PEP) to denote this mechanism.

The credentials/tokens and policies must have semantic interoperability. That is to say, the attributes in the credentials/tokens must be understandable and have a well-known meaning when applied to a policy to make an access decision.

Access decisions can be made either by: (a) Submitting a credential or token with each request, or (b) Using the credential or token to authenticate a session between the requestor and the resource. If a session is established, there must be some way for the user to terminate the session when it is no longer needed. Sessions must also have a limited period of validity after which they expire, but with the possibility of re-validation. Resources or IdPs must be able to revoke a session at any time.

I&I 4: This implies that policies may also include contextual or environmental information. For example, access may be declined if a user on a mobile device using a coffee shop Wi-Fi at 10 PM. This implies that there must be a way to determine the user’s device and physical location when requests are being made.

I&I 5: Ideally this implies that there is a formal definition of what the "secure state" is and also an audit mechanism that can automatically evaluate compliance to that secure system state. If there is any deviation from the desired secure state, an alarm can be raised and actions taken to rectify the deviation. If the deviation is associated with an actual compromise, then actions should be taken to mitigate and contain any negative impact.

I&I 6: If not authenticating on each call, a user must be periodically re-authenticated. Any authentication session must have a finite period of validity, but with the possibility of being refreshed. There must also be a way of revoking authentication and authorization at any time.

I&I 7: One could argue that this tenet is not specific to ZTAs, and could be applied in all architectural philosophies. However, since the ZTA tenets imply the use of fine-grained PEPs, this gives ZTAs a place to monitor and harvest as much network and communication information as possible. This information could be used by a range of cybersecurity tools to improve the security posture. Such tools could include Artificial Intelligence and Deep Learning-based approaches.

While all of the tenets are important in the overall ZTA concept, Tenet 3 is the one that clearly points to the need for some type of Policy Enforcement Point. This is clearly called out by Rose, et al., [14] and Kerman, et al., [54] as illustrated in Figure 16.

This high-level architecture is partitioned into a Control Plane and a Data Plane. The Policy Enforcement Point (PEP) resides in the Data plane and is used to control access from the external (untrusted) world to a protected Enterprise Resource in a Zone of Implicit Trust. The PEP is controlled by a Policy Administrator that uses a Rule Engine to make access decisions. The rule set evaluated by the Rule Engine is informed by a host of supporting components, such as Data Access Policy and Threat Intelligence.

This is a straight-forward repurposing of the terms first used in the OASIS eXtensible Access Control Markup Language (XACML) standard [55]. XACML defines far more than just a protocol for exchanging access control assertions. It defines a general security architecture based on Policy Enforcement Points (PEPs), Policy Decision Points (PDPs) and Policy Administration Points (PAPs). In Figure 16, the Policy Administrator is serving the function of the PDP.

While the ZTA approach is sound, this presentation glosses over critical interactions needed to make the architecture work. First, while it is implicitly there, Figure 16 does not explicitly identify the entity that manages the Access Policies being enforced by the Rule Engine and its Rule Set. Second, while both PKI and Identity Management are called out, how identity credentials containing authorization attributes are granted and revoked for Users and Devices is a critical function. While this is certainly manageable in a local Identity Silo, how is a ZTA managed over a large, distributed environment with multiple organizations and stakeholders? Also note that while PKI will certainly be of interest to many stakeholders, other credential systems exist. While the User-managed wallet approach of W3C Verifiable Credentials is very different from the third-party PKI Certificate Authorities, the OIDC approach shares this design element.

Figure 17 illustrates the interactions that must take place to enable a PEP to do its job. It is clear that this PEP-based approach is tantamount to Software-Defined Boundaries and has strong similarities to the NIST CFRA model.

While Kerman, et al., [54] is silent about Microservice Mesh Architectures, this is the initial approach that NIST is taking to ZTA implementations. This is well-documented by the presentations at the NIST Identity Management & Access Control in Multiclouds Workshop and Conference [56].

The Microservice Mesh Architecture concept is illustrated in Figure 18 (after Chandramouli and Butcher [57]).

This is also partitioned into a Control Plane and Data Plane. The Control Plane manages many microservices that are running in the Data Plane. Every microservice, however, is paired with a Sidecar. These Sidecars give the Control Plane a uniform way to manage all microservices. Besides managing all "east-west" communication among microservices, Sidecars can be used to implement PEPs that are controlled from the Control Plane. The Control Plane can also provide monitoring, accounting and auditing services for the entire set of microservices. Finally, the Control Plane manages all ingress and egress of data and requests, i.e., all "north-south" communication, from Admins, Service Owners and common Users.

The specific ZTA implementation approach that NIST is taking is to integrate the Istio microservice mesh system with Next Generation Access Control (NGAC) previously developed at NIST. Istio [58] is an open-source project. Tetrate [59] is the main Istio contributor that is working with NIST. NGAC was started at NIST as the Policy Machine [60] in 2003 and evolved into a set of INCITS standards under the NGAC name.

The Istio tool suite includes Envoy, a Sidecar implementation. Istiod comprises the Istio control plane, which includes:

As an access control mechanism, NGAC has fundamental differences from other established, rule-based access control systems, such as XACML. Based on the comparisons made by Ferraiolo, et al. [61], the main NGAC differences are:

Implementing a ZTA at the microservice level is a very fine-grained approach. Doing so will raise performance concerns. In recognition of this, Istio can utilize very simple, lightweight checks that do not use multiple rules with multiple predicates. While this will have a smaller performance impact, it limits the expressiveness of policies that can be defined and enforced.

While the microservice mesh approach does enable very fine-grained protection of zones of implicit trust, this is not the only possible approach. The PEP function illustrated in Figure 16 and Figure 17 are directly supported in API Gateways. The use of PEPs, and specifically the XACML model, in a Federation Manager is explicitly described in the CFRA, Appendix B.2 [1]. The integration of the OIDC Federation Specification into a Gateway-based Federation Service illustrated in Figure 12 was derived from this example. While an "ordinary" implementation of a ZTA may be in an Identity Silo, the NIST CFRA model specifically manages the semantic interoperability of credentials, resources, and policies across distributed, multi-organizational environments, i.e., federations.

So what would a Zero Trust Federation actually look like? We review how the NIST CFRA relates to and can address the ZTA design tenets:

ZTF Approach: This is already an integral part of the CFRA, albeit at the service endpoint level for arbitrary, application-level services that can be handled in an API Gateway.

ZTF Approach: The ZTA approach is to encrypt data when in-transit between any two trust zones. ZTFs can take the same approach. However, this approach must be done between Users, Services, and the Federation Services. This could be done using mTLS or adding an endpoint for retrieving JWKSs.

ZTF Approach: Access control on a per-request or per-session basis is already an integral part of the NIST CFRA.

ZTF Approach: This is already an integral part of the NIST CFRA.

ZTF Approach: While not explicitly addressed in the NIST CFRA, the notion of monitoring compliance to a desired system state or set of operating principles is, in fact, addressed by the Trustmark concept. Clearly, though, practical tooling to automatically monitor for compliance will require extensive development. Please note, however, that API Gateways already provide local logging and monitoring services. The challenge for Gateway-based Federation Services is how to do this across a distributed federation.

ZTF Approach: This is already an integral part of the NIST CFRA.

ZTF Approach: This tenet is strongly related to Tenet 5 in that it requires monitoring, interpretation, and improvement. The logging and monitoring done by API Gateways could be used for this purpose.

From this quick review, it is evident that gateway-based federations are quite compatible with the ZTA approach. Tenets 1, 3, 4 and 6 are already central to the NIST CFRA. To show how the NIST CFRA can address the other Tenets, we can further develop the concepts of (a) the encryption of all data in-transit to address Tenet 2, and (b) an effective, distributed monitoring and analysis capability to address Tenets 5 and 7.

Without loss of generality, we can say that the implicit zones of trust in a federation are (a) the Users, (b) the Services, and (c) the Federation Services. This is illustrated in Figure 19 where each organization operates its own Gateway-based Federation Service in a peer-to-peer deployment mode. All of the communication between these entities is encrypted. While the Gateway-to-Gateway communication could be encrypted using mTLS, piggy-backing on the secure signaling between OIDC Providers would be even more secure. This is due to the fact that the OIDC Federation Specification requires the identification of a Common Trust Anchor. This Trust Anchor facilitates the exchange of JWKSs whereby messages can be encrypted and signed.

When on-boarding a new User, or perhaps the first User from a new Organization, the User and the Gateway Federation Service must be able to establish each other’s identity. Depending on the federation’s security requirements, this could be done simply using mTLS. However, ZTFs requiring stronger identity proofing could require the use of an independent third-party — much like a Trust Anchor — to establish mutual trust prior to establishing the encrypted communication.

Services are always registered in a Gateway Federation Service by a User that has the Service_Owner authorization. When registering a service, the Service_Owner essentially acts as the trusted third-party introducing the Service to the Gateway Federation Service. Once this introduction is made, the encrypted communication can be established.

While Figure 19 illustrates a basic ZTF, Figure 20 illustrates several, possible invocation paths to be considered. If only the dark green connections are available in a Zero Trust configuration, then for any User that invokes a Service, the Gateway Fed Services must proxy that invocation. This is Path 1. That is to say, User A invokes the Service through their local Gateway Fed Service, which routes the invocation through a peer network of Gateways, which ultimately invokes Service B itself. As per the ZTA tenets, the Gateway Fed Service (presumably closest to the Service) will validate User A’s credentials to make an access decision prior to forwarding the request to Service B.

While this invocation path is certainly possible, it does mean that all request traffic is being proxied over the Gateway Fed Service peering network. First, this could represent many "hops" and layers of software that will introduce significant latency to response times. Furthermore, if the Gateway peering network is not capable of supporting that traffic, then the peering network would become a performance bottleneck. This can be avoided if alternate routes are considered.

Path 2 avoids the Gateway Fed Service peering network by establishing another encrypted connection between User A’s Gateway and the remote Service B. However, this requires that User A’s local Gateway makes the access decision. That is at odds with the common deployment approach of each organization deploying and operating their own Gateway Fed Service, thereby retaining control of the Gateway Fed Service that is making final access decisions to their resources. Path 2 would require that Organization B trust all other organizations running Gateways when making an access decision for a service in Organization B.

This brings us to Path 3. Here a different encrypted connection is established between User A and Service B’s Gateway Fed Service. This avoids the Gateway peering network, yet allows Organization B to retain control of the final access decision process for their services. Path 3 does increase the number of encrypted connections but will significantly reduce response latencies while avoiding potential network bottlenecks.

Note that Path 4 is possible where a direct connection is established between a User and a Service, after being authorized through the Gateways. This would avoid the Gateways altogether, along with their overhead. If this direct connection is handled as a session that has a time-to-live and can refreshed, terminated or revoked, then such an invocation path technically satisfies ZTA Tenet 3.

With regards to these different path options, while these paths may be logically distinct at Layer 7 in the OSI network model, they may, in fact, be mapped to the same physical network links at Layers 2 and 3. That is to say, all four paths may put the same bandwidth demand on the physical links that are used for routing traffic between Organizations A and B. However the routing is configured, it is always the case that the available bandwidth between organizations should be adequately provisioned to meet demand. Also note that organizational security policy may prohibit the use of some path options, e.g., anything other than Path 1. This ER must identify and acknowledge all such issues, however, resolving them is unfortunately beyond this ER’s scope.