Publication Date: 2021-01-13
Approval Date: 2020-12-15
Submission Date: 2020-11-19
Reference number of this document: OGC 20-027
Reference URL for this document: http://www.opengis.net/doc/PER/t16-D019
Category: OGC Public Engineering Report
Editor: Craig A. Lee
Title: OGC Testbed-16: Federated Security
COPYRIGHT
Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Subject
- 2. Executive Summary
- 3. References
- 4. Terms and Definitions
- 5. Overview
- 6. Introduction
- 7. A Quick Review of Security and Trust
- 8. Federation Security and Trust Requirements: A Threat Analysis
- 9. Emerging Security Technologies
- 10. Possible Development and Adoption Strategies
- 11. Final Comments
- Appendix A: Threat Dragon Report
- Appendix B: Revision History
- Appendix C: Bibliography
1. Subject
This OGC Testbed 16 Engineering Report (ER) examines all aspects of security and trust in federated computing environments as defined in the NIST Cloud Federation Reference Architecture [1]. The security and trust requirements are identified. Then possible approaches for achieving security and trust are examined. These approaches range from traditional methods for securing just the basic communications among federated entities to the use of emerging security technologies including federated roots of trust, trust frameworks, blockchain, data-centric security, and zero trust architectures.
2. Executive Summary
A federation is a set of organizations that wish to collaborate at a level beyond simply using document sharing web sites. A federation enables stakeholders to identify which services and resources are to be shared, who can access them, and the joint policies governing their use. A federation can be considered a virtual administrative domain that can span multiple physical organizations.
As defined in the NIST Cloud Federation Reference Model (CFRA) [1], federated systems can be deployed using one or more Federation Managers. For consistency with the current work of the IEEE P2302 WG [2], this ER uses the term Federation Hosting Services (FHS) as a synonym to Federation Manager. For brevity, Federation Hosting Service will be shortened to just Federation Service.
These Federation Services can host multiple federation instances, i.e., virtual administrative domains. To accomplish this, these FHSs must exchange resource information, user credentials, and enable access decisions to be made across the stakeholder organizations. Hence, if a FHS was compromised in a security breech, the security of resources across multiple federations could be put in jeopardy. The business value of this Engineering Report is to identify the vulnerabilities of possible federation implementations, suggest mitigations, and examine emerging security approaches that can be integrated to achieve the highest possible levels of trust and security.
After a brief review of basic security and trust terminology, a threat analysis is done for a specific CFRA-based federation deployment. As noted in the CFRA, many deployment and governance models are possible. Hence, this analysis is against one specific deployment that is expected to be widely used. This deployment model uses OpenID Connect (OIDC) as the identity providers. The threat analysis is done using Threat Dragon, an open source threat analysis tool wherein the major system components are defined in a graphical format, trust boundaries are identified, and interactions catalogued. Threat Dragon does not identify specific threats nor does it recommend remedies. However, Threat Dragon provides a framework for reasoning about possible threats, where to look for them, and how they could be mitigated. Four interaction scenarios were examined and the following number of threats and mitigations were identified:
Number of Identified Threats | Interaction Scenario |
---|---|
29 |
Authentication to a Federation |
10 |
FedAdmin/ResOwner Interactions |
16 |
User Interactions |
18 |
FS-FS Interactions |
The ER notes that many of these identified threats were multiple instances of the same kind of threat. For example, all communication links were vulnerable to man-in-the-middle attacks that are mitigated by the use of TLS.
The take-away message from this threat analysis is that the vulnerabilities of a federation are derived from the vulnerabilities of the tools they are built on. In addition to using TLS on every communication link, federations built on OIDC inherit the vulnerabilities of OIDC. In turn, OIDC vulnerabilities arise from the specific implementation approach used. For example, OIDC uses two HTTP redirections during the authentication process. To prevent various attacks, the redirection URIs must be full with no parameters and registered with the OIDC server. These URIs must checked on every redirection to prevent Cross-Site Request Forgery attacks. Hence, any federation threat analysis must do a threat analysis of every tool used in a specific implementation. What is different about federations are the possible impacts of a compromise. If a compromise does occur, then federation tooling must be designed to contain and limit any adverse impacts.
The need for enhanced security is certainly not specific to federations. There are many emerging security technologies that could be integrated and utilized in federation systems Many emerging technologies are reviewed in this ER.The Executive Summary only reviews the technologies that are recommended for further investigation and investment. These emerging security technologies can be broadly categorized as follows:
-
Identity and Credential Management:
Not only is OpenID Connect (OIDC) gaining in popularity, the OpenID Foundation is also building out support for federations. Specifically the OIDC Federation Specification enables OIDC installations to establish trust and secure communications. This is done using a protocol to find common trust anchors and subsequently exchange JSON Web Key Sets whereby all communication can be encrypted and signed. Work is also being done on shared signaling between OIDCs. These tools can be directly used in CFRA-based Federation Hosting Services. -
Trust and Zero Trust:
All federation tooling will directly depend on establishing shared data that is trusted. Hence, blockchain could be employed to establish trust for service catalogs, roles and attributes, policies, etc. This would entail evaluating different consensus algorithms, block sizes, and scalability in federated environments. As an alternative approach, the Zero Trust Architecture (ZTA) concept is based on defining zones of implicit trust that are protected by Policy Enforcement Points. These zones of implicit trust are also made as small as possible. The ZTA concept has strong parallels with the CFRA-based federation approach which can use Web Service API Gateways that provide Policy Enforcement Points at the RESTful service level. Hence, the ZTA concept can be directly extended to that of Zero Trust Federations. -
Data Security Methods:
When sharing data, data leakage is always a concern. After data is shared with a partner, how can the partner be prevented from sharing the data with a third-party that should not have the data? The Next Generation Access Control (NGAC) paradigm supports dynamic policy management. As an example, this means that if User X is given permission to read Data Q, User X can no longer write Data Q, i.e., copy it to any third-party. The Data-Centric Security (DCS) model being pursued in Testbed-16 is based on using a DCS Service and a separate Key Management Service (KMS). The DCS only serves encrypted data. Any data recipient must also contact the KMS to retrieve the necessary decryption keys. These services can be managed in a federation — as any other kind of services. This dovetails with the ZTA and ZTF concepts of encrypting all data between trust zones. The Trusted Data Format (TDF) approach takes this a step farther. A Trusted Data Object actually incorporates a Policy Enforcement Point that can contact a remote authorization service to authorize a user’s access. Finally, Trusted Execution Environments (TEEs) actually provide hardware support whereby data is only decrypted when it is copied into special memory regions that can only be accessed by authorized processes. TEE use cases include cloud computing where a remote cloud user can ensure their data is encrypted until it gets installed in the TEE, and that no one else can see it — not even the hypervisor or host OS. While more investigation needs to be done, it might be possible to utilize TEEs are part of federated environments.
All of these topics are organized in a simple, three-phase, roadmap.
-
Phase 1 consists of near-term tasks.
-
Phase 2 consists of subsequent tasks that build on Phase 1.
-
Phase 3 consists of tasks that will have a longer development cycle.
Specifically, Phase 3 includes a review of the NIST SP 800-53 catalog of security controls to identify controls directly relevant to federations, and to identify any possible federation-specific controls that should be added. (This could ultimately be part of any FedRAMP process granting federated systems Authorization to Operate.) A formal method for defining federations is also a longer-term project. Formal definitions for federation requirements and semantics would enable more aspects of federation management to be automated. This could include compliance assessment for security purposes in Federation Trustmark Frameworks.
A final take-home message is that the governance of a CFRA-based federation is purpose-defined. It does not federate existing environments that were not intended nor designed with federation in mind. These could be called purpose-built federations. This approach makes the actual federation governance much easier. However, requiring organizations to agree on how to run their joint federations may force them to face and resolve significant organizational differences.
Since federation is inherently cross-organizational, some type of umbrella organization could greatly facilitate the development and adoption of federations, and the resolution of cross-organizational issues. By analogy with the Internet, in the 1970s the Advanced Research Projects Agency (ARPA) created ARPANET. ARPANET was essentially an umbrella environment whereby many universities, corporations and government agencies could bring their resources to the table and work together in the nascent field of computer networking. We argue that a similar type of umbrella organization would greatly benefit all stakeholders in the development of federation.
2.1. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
Name | Organization | Role |
---|---|---|
Craig A. Lee |
Federation Partners LLC |
Editor |
2.2. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
3. References
The following normative documents are referenced in this document.
-
IETF: RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format.
-
OpenID Foundation: OpenID Connect Federation 1.0 - draft 12.
-
OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview.
-
DNI: XML Data Encoding Specification for Trust Data Format, Version 3.
-
IETF: RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3.
-
IETF: RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
-
OASIS: eXtensible Access Control Markup Language (XACML) Version 3.0.
4. Terms and Definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.
4.1. Abbreviated Terms
-
ABAC: Attribute-Based Access Control
-
ABE: Attribute-Based Encryption
-
CA: Certificate Authority
-
CFRA: Cloud Federation Reference Architecture
-
CSP: Credential Service Provider
-
DCS: Data-Centric Security
-
DoS: Denial of Service
-
DFD: Data Flow Diagram
-
DDoS: Distributed Denial of Service
-
FHS: Federation Hosting Service
-
FS: Federation Service
-
IdAM: Identity and Access Management
-
IdP: Identity Provider
-
JWKS: JSON Web Key Set
-
JWT: JSON Web Token
-
KMS: Key Management Service
-
NIST: National Institute of Standards and Technology
-
OIDC: OpenID Connect
-
OP: OIDC Provider
-
MFA: Multi-Factor Authentication
-
mTLS: Mutual Transport Layer Security
-
ODNI: Office of the Director of National Intelligence
-
OWASP: Open Web Application Security Project
-
P2P: Peer-to-Peer
-
PAP: Policy Administration Point
-
PDP: Policy Decision Point
-
PEP: Policy Enforcement Point
-
PKI: Public Key Infrastructure
-
QKD: Quantum Key Distribution
-
RBAC: Role-Based Access Control
-
REST: REpresentational State Transfer
-
RP: Relying Party
-
RP: Resource Provider
-
SAML: Security Assertion Markup Language
-
SEAL: Simple Encrypted Arithmetic Library
-
SP: Service Provider
-
STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
-
TDF: Trusted Data Format
-
TDO: Trusted Data Object
-
TEE: Trusted Execution Environment
-
TLS: Transport Layer Security
-
TPM: Trusted Platform Module
-
XACML: eXtensible Access Control Markup Language
-
ZTA: Zero Trust Architecture
-
ZTF: Zero Trust Federation
4.2. Definitions
- ● API Gateway
-
A centralized point for exposing APIs to backend resources while abstracting the architectural details from the client. An API Gateway maintains a consistent interface to the requesting clients. It may also support middleware functionality such as security, governance, and monitoring.
- ● Data-Centric Security | DCS
-
Data-centric security is an approach that underlines the security of the data itself rather than the security of communication infrastructure such as networks, servers, or applications. See Data Centric Security Engineering Report, OGC 20-021, [3].
- ● Federation Administrator | FedAdmin
-
The entity that has the authorization to configure and operate a Federation Instance. This entity may be distributed depending on the governance model. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Federated Identity Management
-
The process of asserting an identity across different systems or organizations. This is a key enabler of Single Sign On and managing IdAM in cloud computing. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Federation
-
An organization of self-governing entities that have common policies, administrative controls, and enforcement abilities governing the use of shared resources among members. A virtual administrative domain wherein multiple participating organizations/sites can define, agree upon and enforce resource discovery, access and usage policies for the sharing of a subset of their resources. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Federation Hosting Service|Federation Service
-
The entity that provides the essential federation management functions described in the CFRA for potentially multiple federations over their lifespans. In the CFRA, this entity is called the Federation Manager. For consistency with the current IEEE P2302 WG, this engineering report uses the term Federation Hosting Service as a synonym for Federation Manager. Federation Service is used as a short form of Federation Hosting Service. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Federation Operator
-
The entity that deploys, configures and maintains one or more Federation Hosting Services. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Federation Service
-
See Federation Hosting Service.
- ● Gateway
-
See API Gateway.
- ● Identity Proofing
-
The process by which a CSP collects, validates, and verifies information about a person. See NIST Digital Identity Guidelines [4].
- ● IEEE P2302 WG
-
The Standard for Intercloud Interoperability and Federation (SIIF) Working Group [2].
- ● InCommon
-
A federation-based collaboration system [5] that is run as part of Internet2 [6].
- ● Microservice
-
An application functional component that is implemented in its own container. A set of microservice containers can work together to compose an application. See NIST Application Container Security Guide [7].
- ● Microservice Mesh Architecture
-
An architectural approach where multiple microservices are managed by a control plane. The control plane can associated sidecars with each microservice to enable fine-grained control. The control plane also controls all ingress/egress to and from the mesh of microservices.
- ● P2302 WG
-
See IEEE P2302 WG.
- ● Resource Owner | ResOwner
-
The entity that is accountable and authorizes use and governance of a resource. See NIST Cloud Federation Reference Architecture, Appendix A citey:[CFRA2020].
- ● Root of Trust
-
Roots of trust are highly reliable hardware, firmware, and software components that perform specific, critical security functions. Because roots of trust are inherently trusted, they must be secure by design. As such, many roots of trust are implemented in hardware so that malware cannot tamper with the functions they provide. Roots of trust provide a firm foundation from which to build security and trust [8].
- ● Threat Dragon
- ● Trust Anchor
-
An authoritative entity for which trust is assumed. In a PKI, a trust anchor is a certification authority, which is represented by a certificate that is used to verify the signature on a certificate issued by that trust-anchor. The security of the validation process depends upon the authenticity and integrity of the trust anchor’s certificate. Trust anchor certificates are often distributed as self-signed certificates. See Recommendation for Key Management [10].
- ● Trust Boundary
-
See Trust Domain.
- ● Trust Domain
-
The context in which trust has been established. This context can be established by enterprise boundaries. These boundaries can be hardware-defined or software-defined, i.e., virtual. See NIST Cloud Federation Reference Architecture, Appendix A [1].
- ● Trust Framework
-
The “rules” underpinning federated identity management, typically consisting of: system, legal, conformance, and recognition. See Developing Trust Frameworks to Support Identity Federations [11].
- ● Trusted Platform Module
-
A hardware root of trust as defined by the Trusted Computing Group. See Trusted Platform Module [12].
- ● Trustmark
-
A cryptographically signed document that signifies compliance to a desired requirement or property. Trustmarks can be linked to a root of trust, such as a PKI Certificate Authority. See Developing Trust Frameworks to Support Identity Federations [11].
- ● Verifiable Credentials
-
A credential management system from W3C that allows users to directly manage their own identity credentials. See Verifiable Credentials Data Model 1.0 [13].
- ● X.509
-
The X.509 public-key certificate or the X.509 attribute certificate, as defined by the ISO/ITU-T X.509 standard. An X.509 certificate refers to the X.509 public-key certificate. See Recommendation for Key Management [10].
- ● Zero Trust Architecture
-
An architectural approach where there is no implicit trust granted to systems based on their physical or network location (i.e., local area networks v. the Internet). The ZTA design philosophy is to make trust zones as small as possible, i.e., to make protection as fine-grained as possible. This design philosophy is embodied in a set of ZTA design tenets [14].
- ● Zero Trust Federation
-
Federation deployments that satisfy the tenets of Zero Trust Architecture design.
5. Overview
Section 6 provides an introduction to the topic of security and trust in federated computing environments as defined by the NIST Cloud Federation Reference Architecture (CFRA) [1].
Section 7 provides a quick overview of the main security and trust concepts. This is a quick "level set" on the terminology that is used throughout this ER.
Section 8 reviews the NIST CFRA to establish the necessary security and trust requirements. The CFRA is composed of a number of conceptual actors that have various interactions. By considering these actors and interactions, and how they may be mapped into concrete implementations, the security and trust requirements can be identified.
Once the requirements are established, Section 9 examines a number of approaches for satisfying those requirements. These range from common methods for securing the communication among federated entities, to the use of Zero Trust Architectures.
While a number of security and trust approaches exist for federations, actually realizing them will require socialization and the investment of organizational resource. Hence, Section 10 discusses a number of development and adoption strategies.
Section 11 provides final comments concerning the field of federation security and trust.
6. Introduction
A federation is a set of organizations that wish to collaborate through their IT systems. The desired level of collaboration, however, goes beyond simply making web sites available to each other, or sharing documents on a third-party, such as Google Docs. In a federation, the stakeholders can identify which services or resources are to be shared, who from the organizations can access them, and what the policies are for the resource’s joint use. A federation can be thought of as a virtual administrative domain that can span multiple physical organizations. In the cloud computing era, processors, storage, networks, and many other resource types have all been virtualized. Virtualizing the administrative domains for sets of these resources is being recognized as the natural next step in this progression.
To this point, NIST published the NIST Cloud Federation Reference Architecture [1] in February 2020. As a reference architecture, the CFRA is inherently conceptual as it organizes the entire federation design space, yet it also presents several implementation approaches. Federation can be explained in a nutshell by Figure 1 from the CFRA.
Modern administrative domains are all based on the notion of having an independent Identity Provider (IdP) that issue identity credentials to Users. When requesting service from a Service Provider (SP), the SP validates the User’s credentials with the issuing IdP. Different Identity and Access Management (IdAM) systems may have a slightly different sequence of operations, and may involve HTTP redirections, but having an independent, third-party IdP is fundamental.
Now consider two organizations, A and B, that are each in their own "identity silo". A federated environment will enable a User A to able to discover (find) a SP B at another site, and enable SP B to make a proper access decision based on User A’s credentials. The are many implementation approaches that can realize these fundamental operations.
Any implementation approach, however, has serious security responsibilities. Since a federation system is necessarily spanning organizational trust boundaries, and is managing identity credentials and resource access, any compromise could have serious consequences. If a Federation Hosting Service was compromised, resources at multiple sites could be jeopardized. Hence, the purpose of this Engineering Report is to examine the threats and vulnerabilities of federation systems, and how emerging security approaches can be integrated to achieve the highest level of trust and security possible.
7. A Quick Review of Security and Trust
Security and trust are broad terms that cover a number of constituent concepts. These concepts are briefly reviewed here to provide a "level set" for their meanings.
7.1. Authentication
Authentication: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.(1)
Informally, authentication is the process of verifying that a person or entity is who they say they are. In IT systems, this means validating a user’s identity credentials with the Identity Provider (IdP) that issued them. Identity credentials can be represented in many different formats and the protocols for verifying them can also vary. Nonetheless, identity credentials will carry a number of identity attributes about the credential holder. These can be simple items, such as first and last name or more organization-specific items, such as one’s role or position in an organization chart.
7.2. Authorization
Authorization: The process of verifying that a requested action or service is approved for a specific entity.(1)
Once a person or non-person entity has been authenticated, and their identity credentials have been validated, any requests that are being made to access resources can be validated as well, i.e., they can be authorized to access the resource. This is typically done by evaluating a person’s identity attributes against the resource’s access policy and making an access decision.
Note that authorization does not have to be a yes/no binary decision. Authorization can involve how a service or resource can be used and also the context in which the resource is being used. For example, some users may get access to high-resolution imagery, while others may only get low-resolution imagery. Similarly, a user may have full access while at work in the office, but the same user may be denied access after-hours when using a Starbuck’s Wi-Fi.
7.3. Privacy
Privacy: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.(1)
Privacy entails both making proper access decisions as well as preventing unwanted and unintended disclosure while data is at rest or in-transit. This can mean preventing cyberattacks that compromise a system, and also encrypting data when in transmission. These data do not have to be just personal or proprietary, but could be any information that an organization wishes to control the dissemination of.
Privacy is often equated with confidentiality but a distinction can be drawn between the two terms. Privacy typically means controlling the disclosure of any information. Confidentiality can mean the willingness to disclose information to a second party with the expectation that the information will not be disclosed to a third party. A typical example is a client disclosing information to an attorney. In both cases the goal is to control the disclosure of information.
7.4. Integrity
Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.(1)
In some cases, an organization may not care who sees a particular data set. At the same time knowing that the data is correct and that the data has not be corrupted, changed or tampered with in any way is critical. Data could be corrupted due to non-malicious events, such as a software or hardware failure. Data can also be corrupted due to malicious events, such as a cyberattack. In operational environments, integrity can mean preventing any corruption from happening for any reason. This could also mean simply mean being able to detect that data has been corrupted.
A simple example of data that is public but requires integrity is government-produced weather data. Such data is often produced for the personal use of citizens, but is also produced to promote the economic activity of organizations. Therefore, "monkey-wrenching" weather data could have serious impact on organizations that use the weather data to make business decisions.
7.5. Non-repudiation
Non-repudiation: Protection against an individual falsely denying having performed a particular action. Provides the capability to determine whether a given individual took a particular action such as creating information, sending a message, approving information, and receiving a message.(1)
Non-repudiation may be less familiar to many people as a security term, but is actually quite commonplace. Non-repudiation means that two parties to a transaction of some sort (e.g., exchanging information) cannot later deny that it took place. A simple example is that of going to a grocery store and getting a receipt. If you meant to buy a can of baked beans but bought refried beans my mistake, the grocery store will probably want to see the receipt before allowing an exchange. The receipt makes disputing the transaction difficult. In IT systems, enforcing non-repudiation is somewhat more complicated, but can nonetheless be critical.
7.6. Trust
Trust: The willingness to take actions expecting beneficial outcomes, based on assertions by other parties.(1)
The definitions provided in this section of the ER are intended to be as concise and to-the-point as much as possible. While the above definition captures the essence of what trust is, it nonetheless has immense implications for what trust means in the context of IT systems. The first step in establishing any trust relationship is establishing the identity of the entity with whom you are communicating. The second step could simply be ensuring that the communication between the two entities is secure. While these aspects of trust are necessary, they are by no means sufficient. Even after identity and communication integrity have been established, trust will also depend on some type of assurances that the other entity will act in a trustworthy manner.
Many tools and security controls to achieve these requirements are already cataloged in NIST Security and Privacy Controls for Federal Information Systems and Organizations [15]. In the following pages, additional methods to achieve these properties in federated environments will be discussed. This suggests that the security controls in [15] should ultimately be reviewed and revised to include any federation-specific controls that are needed.
8. Federation Security and Trust Requirements: A Threat Analysis
With a basic understanding of security and trust concepts, understanding how they are needed in federated environments and how they can be addressed is the next step. At the conceptual level, CFRA-based federations will be hosted by one or more Federation Managers that interact with Users and other Federation Managers. At the implementation level, a Federation Manager will be implemented as a Federation Service. A Federation Service (FS) will be functionally similar to any web server. A web server can host multiple web sites and serve all manner of web content. A FS will be able to host multiple federations and serve all manner of federation content.
By standing up a FS that is listening on one or more ports, a commensurate number of attack surfaces will be opened up. The attack surface of a software environment is the sum of the different points where an unauthorized user can try to enter data to or extract data from an environment (Wikipedia). These federation attack surfaces will share many vulnerabilities present in other types of servers, but will also present new, federation-specific vulnerabilities.
To hopefully identify these shared and new vulnerabilities, this section will develop a federation threat model on which a threat analysis will be done. The large body of work has been researched and published in threat modeling and analysis is leveraged in the following discussion. A number of threat modeling tools exist that provide a modeling structure in which to do an analysis. These tools and evaluation paradigms are briefly reviewed here.
Note that any threat analysis is only as good as the threat model on which it is based. That is to say, threat models should be based — as much as possible — on a specific, concrete implementation. The less specific or concrete that a model is, the harder it becomes for a threat analysis to identify specific or concrete threats.
This makes doing "a" federation threat analysis problematic. There are clearly multiple ways a CFRA-based Federation Service could be implemented. The CFRA also identifies a range of deployment and governance models that could be used. To do any analyses, a number of implementation assumptions and deployment scenarios have to be made. As such, an exhaustive analysis is not be possible. Furthermore, an authoritative threat analysis can be a sizeable effort. This leads us to a note of caution:
This threat analysis should not be considered complete, definitive, nor authoritative. This analysis is just an initial threat model and analysis that can point the way to more thorough efforts that are properly funded and resourced.
Given this caution, available modeling tools are now discussed.
8.1. Threat Modeling Methods, Tools, and Mitigations
Each threat modeling tool is based on some threat modeling method. A useful review of twelve methods is presented in Threat Modeling: A Summary of Available Methods [18]. The authors emphasize that no one method is inherently better than the others. Some methods focus on risk and privacy concerns, while others focus on people issues. Some methods operate on high-level abstractions, while others strive for finer granularity. For the threat analysis in this engineering report, the STRIDE model [19] will be used. STRIDE was developed over twenty years ago and has been adopted by Microsoft. STRIDE is an acronym based on the following threat categories:
Category | Description |
---|---|
Spoofing |
The deliberate deceiving of a user and tricking them into disclosing sensitive information, such as username and password(s), that is then used the user’s knowledge or consent. Spoofing can be done through using bogus email addresses, websites, or even IP addresses. |
Tampering |
The malicious modification of data, either when at-rest, such as in a database, or in-transit over a network. |
Repudiation |
When a party that observed an event or engaged in a transaction later denies that the event or transaction took place. What is desired is non-repudiation: no one can deny that the event or transaction took place. |
Information Disclosure |
The exposure of information to individuals who are not supposed to have access to it, either when at-rest (e.g., reading a file) or when in-transit (e.g., snooping on the network). |
Denial of Service |
Denial of Service (DoS) attacks deny service to valid users by overloading the service with unnecessary requests for service. Distributed Denial of Service (DDoS) attacks can be especially difficult to deal with. |
Elevation of Privilege |
An unprivileged user gains privileged access and thereby has sufficient access to compromise the entire system. |
STRIDE and other threat modeling methods have been built into a variety of threat modeling tools [20]. These tools likewise have different scopes, ranging from security requirements management to identifying risk patterns throughout the software development lifecycle. Three identified tools are based on STRIDE:
The threat analysis in this engineering report will use OWASP Threat Dragon. Threat Dragon is an open source tool based on STRIDE. Threat Dragon can be downloaded as a stand-alone, desktop application, or run through an on-line application that is integrated with GitHub. This integration with GitHub means that Threat Dragon can be used to do threat analyses on code as it is being built in a GitHub repository. Since a CFRA-based Federation Service is not actually being built (yet), the desktop version of Threat Dragon (version 1.2.0) will be used.
Mitigations for the STRIDE threats [25] can be categorized as follows:
Category | Description |
---|---|
Auditing and Logging |
Who did what and when? Application logging of security-related events enables subsequent auditing to possibly identify malicious events. |
Authentication |
Who are you? Unequivocally establishing the identity of an entity is critical for establishing who did what when. |
Authorization |
What can you do? Authorization is determined by evaluating identity credentials against the discovery and access policies for specific resources. |
Communication Security |
The privacy and integrity of data as it is in-transit must be ensured. |
Configuration Management |
All systems are composed of multiple components that must be deployed and managed as a whole. Properly managing the configuration of these components is central to reducing threat vulnerabilities, such as making sure software versions are current, ensuring that credentials are properly handled, ensuring that components only communicate with other authorized components, and so forth. |
Cryptography |
Cryptographic methods to encrypt/decrypt and sign data are commonly used to provide confidentiality and integrity. Is cryptography being properly used in the system under review? |
Exception Management |
When something in a system fails, and an exception is raised, is the failure handled properly? First, does the system fail gracefully? Second, does the exception capture essential information about the failure? Third, is the information passed back to the user both useful but at the same time restricted to a need-to-know? |
Input Validation |
Validating input data when it is received by a system component can prevent many security issues. Is the data from a trusted source? Has the data been corrupted or modified in-transit? Is the data in the right format and within expected bounds? Does the input data contain any extraneous information? |
Sensitive Data |
Systems may have data that is considered to be more sensitive and must be appropriately protected. This includes when data is in memory, at-rest in a data store, or in-transit over a network. |
Session Management |
A session refers to a series of related interactions between a user and an application. Sessions are often used to establish a security environment that is used for the duration of the session. This can provide performance benefits, yet must be properly managed to avoid security vulnerabilities. |
These STRIDE categories and mitigation approaches will be used in a threat analysis of a CFRA-based Federation Service using Threat Dragon. Threat Dragon works by providing a palette on which Data Flow Diagrams (DFDs) can be built describing how a system works. These DFDs are based on Processes, Stores (Storage), Actors, Data Flows and Trust Boundaries. For each of the elements, threats can be identified and added to the overall model. Threat Dragon also provides a rule engine that can auto-generate basic threats for each element.
What the Threat Dragon tool actually provides is a way to (a) describe how a system is built and how it works, and (b) catalog possible threats. As such, Threat Dragon does not tell the user exactly what the specific system vulnerabilities are, nor how to mitigate them. Rather it gives the knowledgeable system builder a systematic organization and structure in which to do such an analysis.
8.2. A Federation Service Threat Model and Analyses
With an understanding of threat modeling and analysis, a likely Federation Service implementation, deployment and governance model are chosen to analyze. As stated above, specific threats and mitigations can only be identified for specific system implementations. Given the range of possible implementations, and the range of deployment and governance models, it is simply not be possible to exhaustively analyze all of them in this document. Hence, a few strategic examples that are considered to be attractive and likely are chosen for analysis.
This approach requires that a number of specific architectural assumptions be made. First the case of a single Federation Service being used in a Third-Party deployment is considered. As only one Federation Service is involved, this is the simplest deployment identified in the NIST CFRA. Based on established software engineering practices, we will assume that the FS implementation will be:
-
Based on RESTful services,
-
Integrated with Open ID Connect, and
-
Based on a Web Service API Gateway approach.
This overall implementation is illustrated in Figure 2. Several other very important architectural features are identified. RESTful tools are often built with multiple endpoints that serve different purposes. This Federation Service has two endpoints: the FS Endp and the FSO Endp.
The FSO Endp is used exclusively by the Federation Service (FS) Operator. The FS Operator is the entity that "spins-up" the Federation Service — just like any other service. The FS Operator is primarily concerned with the general health and status of the server’s operation, and does not get involved with the operation of any federation instances that the server is hosting. As such, the FSO Endp can be assigned to an internal subnet that is not accessible to the "outside world". This is an important security feature that eliminates many security threats.
The FS Endp is the endpoint exposed to all federation Members that wish to use a federation being hosted on this server. This includes all types of Members that have different roles, such as FedAdmin, ResOwner, ordinary Users, or any other federation-specific roles or authorizations that may be defined. With regards to this threat analysis, however, it must be assumed that this endpoint is accessible by malicious actors.
Likewise, as defined by the OIDC standard, the OIDC service has three endpoints. These endpoints are used in different ways, according to several different defined flows that are defined. This analysis is done using the Authorization Code Grant Flow, which is the typical and most secure way that OIDC can be used. In this flow, when a Member makes a request to the FS, the Member must first be authenticated. This is done by a redirect to the AuthZ Endp on the OIDC Service. Since this endpoint must be accessible to any federation members, it must also be assumed that this endpoint is accessible by malicious actors.
The OIDC service also uses the Token Endp and the UserInfo Endp. These endpoints, however, are only used by the FS API Server. For this reason, these endpoints could also be assigned to an internal subnet where they are not accessible by the outside world.
The Federation Service has two other critical components that need to be mentioned. The Federation Database contains the state for all federations that currently being hosted. For each federation, this includes:
-
Who is a member,
-
What roles and authorization attributes have been defined,
-
The assignment of these roles and attributes to members,
-
Which services have been registered for use, along with their metadata, discovery policies, and access policies.
This database function for a Fed Service could be provided by an Oracle database or a simple MongoDB server. In any case, this database function could be on an internal subnet such that it is only accessible by the FS API Server.
Auditing and Accounting is another very important function. This is primarily implemented as a logging service. Multiple commercial logging tools are available that manage log formats, timestamping, and the disk space used by log files. Such a service can likewise be on an internal subnet.
Finally, we note that this Federation Service incorporates the basic OASIS eXtensible Access Control Markup Language (XACML) security architecture through the use of a Policy Administration Point (PAP), Policy Decision Point (PDP), and one or more Policy Enforcement Points (PEP). After authenticated, when a Member makes a service request, the FS API Server forwards the request to a PEP, which asks the PDP to make an access decision based on the access policy for that service. If allowed, the request is finally forwarded to the service. Clearly the PAP/PDP/PEP machinery can be internal to the Federation Service. However, when a PEP forwards a request to an arbitrary federation service, it must be assumed that the request can be threatened by malicious actors.
While a single Federation Service is completely sufficient for running multiple federations, larger scale federations will require multiple Federation Services that are peers. This will be necessary not only for scalability reasons, but also due to possible desirable deployment models. It is anticipated that many organizations will want to deploy their own Federation Service that "peers" to the Federation Services in other organizations. This is illustrated in Figure 3.
The only addition to this model are the FS-FS Endpoints on the two Federation Services, and the link connecting them. As discussed in the CFRA, when two or more Federation Services peer, a major design decision is how this link is used: Which federation information is replicated among the Federation Services, which information is partitioned, and what queries must be passed among them. For the analysis described in this ER, this issue is out of scope. What data flow over this link would change what impacts a compromise might have, but the potential threat methods are the same.
These static architectural concerns must be considered in conjunction with the dynamic lifecycle of a federation and how those architectural components are used. To this end, the following interaction scenarios are examined:
-
Authentication to a Federation Service
-
FedAdmin/ResOwner Interactions
-
User Interactions, and
-
FS-FS Interactions.
All federation members must first authenticate to a Federation Service. This scenario exercises the entire OIDC Authorization Code Flow. As defined in the NIST CFRA, there are three fundamental, pre-defined roles that any federation member may have: FedAdmin, ResOwner, and User. The FedAdmin can administer a federation, i.e., grant/revoke membership, roles, or attributes. A ResOwner can register services to be available in a federation, along with defining their discovery and access policies. For the purposes of this analysis, the FedAdmin and ResOwner threat analyses are combined since the threat models are structurally the same. Finally, a User is something of a default role that is able to invoke services, but not to administer the federation or register services. Hence, each of these fundamental roles exercises different functional capabilities in a Federation Service.
Based on the object model given in Figure 2 and Figure 3, separate Threat Dragon analyses can be performed for the four scenarios identified above. These four analyses that can be performed are part of one ThreatDragon analysis project. After completing an analysis, ThreatDragon can write the entire project results to a pdf report file. That final report file is given in Appendix A: Threat Dragon Report. A summary and discussion of each scenario analysis is presented here.
8.2.1. A Threat Analysis of Authentication to a Federation Service
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:
-
All redirection URIs should be completely defined with no parameters and registered with the OIDC Server.
-
Registered URIs should be checked to avoid Cross-Site Request Forgery (CSRF). CSRF is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
-
Use stronger authentication methods, such as multi-factor authentication (MFA), random questions, CAPTCHAs etc.
-
Only browsers that support the X-FRAME_OPTION should be allowed such that click-jacking using transparent iFrames can be avoided.
-
The binding of an entity’s externally accessible API endpoint to the entity’s domain name should be validated, such as the Fed Service.
-
Use TLS on all communication links.
-
Rate-limit requests to avoid DoS attacks to the Fed Service or OIDC Server.
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.
8.2.2. A Threat Analysis of FedAdmin and ResOwner Interactions
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.
8.2.3. A Threat Analysis of User Interactions
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.
8.2.4. A Threat Analysis of FS-FS Interactions
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.
8.3. Threat Analysis Observations
This structural approach to threat analysis emphasizes several points:
-
Authentication is critical. Once a trusted identity has been established, the identity can be associated with authorization attributes that determine what an entity can do. In many ways "Who you are" is "What you can do".
-
Communications must be protected at all times. Whenever communication must cross a trust boundary, it must transit a zone of implicit distrust. The common security practice today is to secure the communication channel as it crosses that zone of distrust. However, to assume that everything within a trust boundary is, in fact, secure carries its own risk. This is the central motivation for developing Zero Trust Architectures.
-
Many security threats are "idiosyncratic" to specific implementations. That is to say, many exploits exploit an implementation flaw or oversight, such as failing to check a registered redirection URL. A structural threat model for a specific system deployment can identify which tools are being relied upon. Once that is done, the threat analyst must look for threats against those specific tool implementations. The actual tool implementers are in the best position for doing such analyses.
Threats can also arise from how a standard is defined. TLS was cited repeatedly as a mitigation strategy for communication threats. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack [27] is considered to be fault of the protocol. When a client initiates a TLS handshake, it sends a list of supported SSL/TSL versions. A Man-in-the-Middle attacker could impersonate the server and try to get the client to agree to downgrade to SSL 3.0. SSL 3.0 has a vulnerability in the Cipher Block Chaining mode. Cipher blocks can have padding to reach a fixed length that an attacker can manipulate. By watching the server responses to this padding, the attacker can eventually determine how to decode the encrypted block. Since the POODLE attack was considered to be inherent in the protocol, the recommended mitigation was to simply disable the use of SSL 3.0.
This one threat analysis made definite assumptions about the deployment structure, and specifically where the trust boundaries were. This clearly affects what vulnerabilities might exist. In OIDC, impersonation attacks are possible if the ID Tokens are not validated. (ID Tokens are used in OIDC, but are not part of the OAuth standard.) When OIDC is within a trust boundary, there is no problem. However, if outside the trust boundary, then the client (i.e., the Fed Service) must validate that the ID Tokens are properly signed by the OIDC Issuer. Hence, mitigations must always be in place concerning trust boundaries.
The above comments serve to emphasize the threat analysis presented here should not be considered complete, definitive nor authoritative. This analysis does, however, point to many places where "recursive" threat analyses could be done on all tools and standards used in a federation deployment. The limitations of these threat analyses to identify and mitigate vulnerabilities are also motivating the development of new architectural approaches that will simply eliminate some vulnerabilities, while making others more manageable. This is the topic of the next chapter.
9. Emerging Security Technologies
The previous chapter examined the security threats and mitigations of a specific deployment of a CFRA-based federated environment using established security approaches and tools. That approach was essentially based on (a) establishing identity, and (b) securing communications channels, specifically when trust boundaries had to be crossed. The need to establish a trusted identity was critical since identity was associated with authorizations. Securing communications channels at the network level is the established thing to do because it is the obvious thing to do. This is a manageable, infrastructure-based, security approach. However, are there other ways of establishing identity and secure communications that are less dependent on a particular infrastructure and generally more secure — especially in distributed, federated environments? To this end, other approaches to managing identity and trust are examined.
9.1. Identity and Credential Management
All security architectures share some fundamental requirements. Federated environments inherent all of these, while introducing additional considerations. These fundamental requirements are nicely organized in the NIST Digital Identities Guidelines, SP 800-63-3 [4]. These are briefly reviewed here prior to discussing federation-specific concerns.
9.1.1. Identity Proofing
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:
-
IAL1: "There is no requirement to link the applicant to a specific real-life identity." That is to say, the applicant can self-identify and self-assert any attributes about themselves. This is a common approach for many on-line services, such as chat rooms.
-
IAL2: "Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity." This requires some type of independent verification of the applicant’s identity claims.
-
IAL3: "Physical presence is required for identity proofing." The applicant must appear in person and have their identity claims independently verified by an authorized and trained representative of the CSP.
These Identity Assurance Levels can all be applied in federated systems.
9.1.2. Authentication
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:
-
Something you know: This could be an account name and password, an RSA passcode, or some other type of digital challenge.
-
Something you have: This can be an ID badge, a Common Access Card, an RSA SecurID Hardware Token, a cryptographic key, or even a mobile device for presentation of a challenge.
-
Something you are: This can be a fingerprint, retina scan, facial recognition, or some other biometric data.
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:
-
AAL1: "AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol."
-
AAL2: "AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above."
-
AAL3: "AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required."
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.
9.1.3. Federated Credential Management
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):
-
FAL1: "Allows for the subscriber to enable the RP to receive a bearer assertion. The assertion is signed by the IdP using approved cryptography."
-
FAL2: "Adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it."
-
FAL3: "Requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion is signed by the IdP and encrypted to the RP using approved cryptography."
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:
-
Legitimately "belongs" to the subject,
-
Has integrity — it has not been maliciously modified, and
-
If privacy is desired, cannot be snooped to determine the identity attributes being released from the IdP to the RP.
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:
-
Only the minimal identity attributes are released to enable the RP to make a valid access decision.
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.
9.1.4. Attribute Release and Verifiable Credentials
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.
9.2. Trust
Trust is an immense subject [31, 32]. As a concept, trust is relevant across many fields of human endeavor, such as sociology, psychology, economics, game theory, business, philosophy, international relations, and jurisprudence, just to name a few. For this reason, trust is examined in a little more depth than in the top-level Trust definition.
9.2.1. Defining Trust
-
Cognitive Trust: Trust derived from the mental processes of an intelligent entity.
-
Social Trust: Trust derived from a human social network built on pair-wise relationships.
-
Information Trust: Trust that information shared over an information network is trustworthy; i.e., meets some definition of objectivity, reliability, integrity, accuracy, fairness, etc.
-
Communication Trust: Trust that a system of nodes and links will demonstrate a set of quantifiable metrics, such as connectivity, capacity, latency, fault tolerance, etc.
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:
-
Pair-wise Trust is based exclusively on bilateral business agreements. While fundamental, pair-wise trust has limited scalability.
-
Brokered Trust relies on active intermediaries that can construct a path of trust relationships from one entity to another. While certainly more scalable, brokered trust implies that all parties must agree to a set of rules governing the use of transitive trust relationships.
-
Community Trust is based on a shared membership in a community. This implies a common, well-known set of rules whereby trust can be said to be established. In essence, establishing community trust implies, that an all-to-all set of pair-wise trust relationships has been established among the community members.
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.
9.2.2. Trust Frameworks
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:
-
Federation Administrators (aka, IdPs or Credential Providers),
-
Relying Parties (aka Resource Providers), and
-
Users (aka, Members).
A Trust Framework encompasses a set of rules governing how:
-
Identity management responsibilities are conducted,
-
Identity information is shared,
-
Shared identity information is used,
-
Identity information is secured and protected,
-
Specific roles in the federation are performed, and
-
Legal and liability issues are managed.
To accomplish this, a Trust Framework is comprised of four components:
-
System Rules (above) which govern members,
-
A Legal Structure which identifies the rights, responsibilities, and liabilities of membership and participation in a federation;
-
A way of Establishing Conformance of individual members; and
-
A way of Recognizing that Conformance and communicating the fact of conformance among the federation members.
In [11], these components are discussed specifically for identity federations. Their implications for general federations are now considered.
9.2.2.1. System Rules
System Rule includes issues of member registration, identity proofing and credential management. These have already been extensively discussed. The issue of privacy is clearly related to the issue of attribute release, which was discussed concerning credential management. Aside from mechanisms for managing the exposure of member’s attributes to resource providers, different federations may have different privacy concerns and requirements. As noted in [11], a federation should have a clearly defined privacy policy concerning how member attributes are handled. This emphasizes the importance of CFRA-based general federations being able to define their own set of attributes. These do not have to include any personal information about a member and may only have meaning within the federation. Of course, a link from a member’s federation identity to their "home" or "personal" identity would always have to be maintained.
Temoshok and Abruzzi raise the issue of federation members being tracked, allowing a Credential Service Provider to "build a narrative" about a user that the user did not consent to. Note that this is another potential benefit of Verifiable Credentials. A credential Holder may use a credential, such as presenting the credential to a Verifier, without the Issuer necessarily knowing about the credential usage. While Verifiers could track their customers, a Credential Issuer would not be able to track Holders across multiple Verifier interactions. With CFRA-based federations, we note that even if a credential system such as OIDC is being used, the Credential Issuer should only be able to track the federation member within a given federation. From a technical perspective, it would be possible for a single CFRA-based Federation Service to track a member’s behavior across multiple federations if those federations were being hosted on the same Fed Service. This is a distinct policy issue concerning CFRA-based implementation that should be addressed. Outside of a federation, for a Federation Service to track a member’s behavior would certainly not be possible.
Security and Data Handling requirements for identity federations are how discussed. General federation clearly inherits these requirements. The mechanisms to achieve communication security are extensively discussed in the Threat Dragon analyses. In addition to handling identity data, general federation need to securely manage and minimize the volume of service data is exchanged, such as service endpoints, metadata, discovery and access policies.
The final System Rules topic is Technical Specifications. Having a "common set of technical protocols and standards" is beneficial and even necessary for all distributed systems. Developing and establishing standards for CFRA-based federations is the goal of the IEEE P2302 WG [2]. While this is still work-in-progress, P2302 has defined a core API single, Third-Party CFRA deployments, and simple peer-to-peer deployments.
Beyond the API and protocol work, P2302 is also working on the notion of a formal definition methodology for federations. A formal federation definition would include information such as the "Rules of the Road" for participation: What the purpose and goals of the federation are, what types of services and data are to be shared, what type of attributes will be needed and available to manage discovery and access policies, how the federation will be governed, who will be the FedAdmins, and so forth. This would be similar to an Acceptable Use Policy that defines the roles and responsibilities of federation membership. While this is also work-in-progress, candidate approaches could be Fed-ML or an OWL-Fed. These could all be part of the System Rules for a general federation Trust Framework.
9.2.2.2. Legal Structure
Small-scale federations can be quite informal requiring nothing more than verbal agreements among friends. This is true for both identity federations and general federations. However, as federations become larger and involve more significant amounts of resources, the participants may feel that legal agreements are a necessary part of the federation trust framework. When a federation represents a significant investment of time, money and people, then the rights and obligations of federation members must become legally binding. These rights and obligations could include an Acceptable Use Policy, as discussed above, but could involve much more.
All federations must be in regulatory compliance. Federations operate within governmental jurisdictions that may define legally binding compliance requirements. Examples include the Child Online Privacy Protection Act, the Financial Services Modernization Act, and the Health Insurance Portability and Accountability (HIPPA) Act, which all govern how data must be protected and how it can be used. Such compliance requirements must be reflected and observed as part of a federation’s legally binding System Rules.
Something that is explicit in a general federation, and not in an identity federation, is the potential financial cost of the deployment and use of a service with a federation. If the cost of operating a federated service is not covered "by other means", then the service owner may wish to establish a pricing model whereby costs can be recouped, or even a profit made. Any such pricing models must be part of the System Rules in a Trust Framework. This must be done in conjunction with an accounting mechanism. Such a mechanism must log and collate all the necessary transaction events, such that an itemized bill can be presented at the end of a billing period. While identity federations may enable services to be used, costing and billing is simply out of scope for them.
Legal agreements typically address the issue of risk and liability allocation: Who is responsible if something goes wrong. In an identity federation, if an identity credential is mishandled or identity attributes are erroneously associated with the wrong credential, then an erroneous access decision could be made. Access could be granted when it should not have, or a legitimate access request could be denied. In either case, one party or another could feel they have suffered a loss. This loss could be financial or exposure of private, sensitive information.
This is certainly an issue in general federation, as well. In addition, though, a general federation is managing service endpoints, metadata, and discovery/access policies. If these are mishandled, these could also result in an erroneous discovery or access decision, and some party could feel they have suffered a loss. While every precaution to be taken to ensure that a Federation Service does not "make mistakes", a Federation Trust Framework should clearly identify what happens when one does.
The final legal topic is Multilateral Agreements. One of the fundamental tenets of a federation is that rather than having a set of differing, potentially conflicting, bilateral trust agreements, there is a single, multi-party agreement that all participants agree to. When agreeing to such a contract, all parties have a consistent understanding of the "Rules of the Road" for participating in a federation. In a general federation, the scope of such agreements is expanded beyond that of just an identity federation. Beyond the handling of identities, a legal, multilateral agreement for a general federation can include the types of services to be shared, their metadata, and roles and attributes governing how the services can be used.
9.2.2.3. Establishing Conformance
While defining a trust framework that members must agree to is essential, some federation scenarios will demand that actual compliance to those System Rules must be established through a concrete assessment process. The need for such assessments is the same for both identity and general federations, although the scope of such assessments will be greater for general federations. Temoshok and Abruzzi identify three aspects of assessing conformance:
-
Self-Assessment: Self-assessment is the first step beyond simply having a signed membership agreement. As an internal process, this can require the least overhead.
-
Third-Party Assessment: Third-party assessment raises the level of confidence in the assessment results. A third-party assessor should be independent of the organization being assessed and the federation itself, such that the assessor has no motivation to bias any results one way or the other. While such independence is valuable, it does require a greater investment of resources.
-
Formal Audit: A formal audit is a standardized compliance evaluation method. While a federation’s System Rules may define the trust criteria, a formal audit defines how compliance will actually be assessed. A Trust Framework that requires formal audits could also define when and how often audits are done, and with how much notice.
While assessing compliance is certainly important, any assessment method must be driven by specific criteria. Hence, a formal method of defining all aspects of a federation needs to be developed whereby a formal method of assessing conformance can also be defined.
9.2.2.4. Recognizing Conformance
Once compliance has been assessed, there must be a trusted mechanism whereby the results of that assessment can be communicated to, and thereby recognized by, other stakeholders in the federation. General federations use the same mechanisms as just identity federations. Temoshok and Abruzzi identify the following:
-
Registries and Listing Services: This can be as simple as maintaining a web site where assessment results are reported. Reported results should also identify the assessment methodology and whether it was a self-assessment or third-party assessment.
-
Compliance Marks: A compliance mark is a visually recognizable image or icon that denotes the satisfaction of a specific set of compliance requirements under a known methodology. The use of a compliance mark is strictly controlled because of the achievement it is meant to represent.
-
Electronically Verifiable Marks: Beyond simply a visual icon, an electronically verifiable mark can have an embedded URL that links to a registry or the organization that issued the compliance mark.
-
Cryptographically Signed Compliance Marks: Called Digital Certificates or Trustmarks by Temoshok and Abruzzi, these compliance marks are cryptographically signed and can be linked to a root of trust, such as a PKI Certificate Authority. While offering the highest level of trustworthy recognition, such compliance marks have the highest overhead in terms of the necessary infrastructure that must be operated.
An important distinction in these recognition methods is whether they are done at the human organization level, or whether they are automated somehow as part of the IT infrastructure. Identity federations enable a Relying Party to trust credentials from different IdPs. While both the RPs and IdPs may want to know that all entities are in compliance with a set of requirements that denote trust, identity federations do not have an integral mechanism verifying signed compliance marks. On the other hand, a set of CFRA-based Federation Services supporting general federations could also be used to manage sets of signed compliance marks that could be requested and inspected on-demand. Federation Services could also be used to help automate the assessment process, but this raises the issue of how much independent, third-party humans should be "in the loop".
9.2.2.5. Examples of Federation Trust Frameworks
One direct benefit of Temoshok and Abruzzi’s work identifying and organizing the components of trust frameworks is that this organization can be used to evaluate existing trust frameworks that have been developed. These trust frameworks have been developed in an ad hoc manner to serve their user communities. Nonetheless, they represent pioneering work in this area.
-
Interoperable Global Trust Federation (IGTF): IGTF [34] started as the International Grid Trust Federation in 2004, during the heyday of grid computing. The goal of grid computing was to enable international science projects to share data and resources. Trust among the participants was established by self-audit and peer review. Once a participant demonstrated that their PKI Certificate Authorities were configured and operated according to IGTF guidelines, other participants would trust certificates signed by their CA.
-
Federal Bridge Certificate Authority (FBCA): The FBCA [35] developed some years later, provides a very similar capability. The FBCA provides a way to link or bridge CAs in the Federal PKI (FPKI) network that may operate under different certificate policies. FBCA can map certificate policies thereby enabling them to be validated with the Federal Common Policy Certificate Authority (FCPCA) root certificate. CAs with certificates signed by the FBCA 2016 are said to be cross-certified and have a trust relationship established with the FPKI. This relationship is audited annually for conformance to the certificate policies.
-
InCommon: Starting around the same time as IGTF, InCommon [5] is a federation-based collaboration systems that is run as part of Internet2 [6]. Beyond just enabling trust among PKI certificate authorities, InCommon maintains a federation metadata file. This is an XML file of identity providers and service providers from different universities and organizations, enabling these organizations to collaborate. InCommon operates a Registration Authority that vets IdP and SP information before adding it to the metadata. InCommon also has a resolution process whereby disputes between participants can be addressed.
Other trust framework examples are possible. However, the above sampling serves to illustrate some differences. Each has a different scope for what they are providing, and have a different level of automation, albeit scant, for dealing with their System Rules and Conformance processes. IGTF is more of a loose federation with self-audit and peer review. FBCA actually operates a root CA that serves as the trust anchor for the entire trust federation. InCommon goes beyond this by maintaining a flat file of IdPs and SPs from which different federated environments can be built, but without any inherent mechanisms for keeping those environments separate and private.
Such differences underscore the need to develop general federations whose governance and trust frameworks are based on standards and automation as much as possible. Furthermore, it must be possible to tailor such deployments to various federation profiles that meet the different collaboration requirements of the participants. Further discussion about these systems and issues can be found in [1, 36, 37].
9.2.3. Trust Framework Approaches
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.
9.2.3.1. Trustmarks
Trustmarks were originally developed for e-commerce, such as BBBOnline [38], VeriSign [39], and TRUSTe [40]. Since these were targeted for e-commerce, they have a specific, fixed scope. The BBBOnline trustmark denotes compliance for advertising standards. To combat fraudulent use, the trustmark is clickable and links to a registry where the company’s trustmark issuance is documented. VeriSign offers a similar clickable trustmark, but issuance denotes the recipient is authentic and that VeriSign does daily malware scanning. TRUSTe also provides clickable trustmarks, but for a variety of different purposes, such as the U.S. Health Insurance Portability and Accountability Act (HIPAA), the EU General Data Protection Regulation (GDPR), and the Asia-Pacific Economic Cooperation (APEC) Privacy Framework.
While these efforts are commendable, how do trustmarks relate to federations? Trustmarks are intended to denote confidence bestowed by a trusted third-party, but how can they be used in federations that can have a wide variety of requirements for very different application domains? Besides meeting technical requirements of operation, can they be used to manage legal requirements? These were the goals of the Trustmarks project [41] at the Georgia Tech Research Institute (GTRI).
In the GTRI approach,
"A trustmark is a machine-readable, cryptographically signed digital artifact representing that a specific named entity conforms to a well-scoped set of requirements, as attested by a trusted, third-party assessor."
Such trustmarks enable the "componentization of trust characteristics and requirements at an arbitrary level of granularity". That is to say, with this approach, trustmarks can be defined for any aspect of a federation where compliance needs to be maintained. Since trustmarks are machine-readable, this enables automated reasoning about their requirements and conformance criteria. This means that trustmarks can be created, managed and validated in a trustmark framework. This includes trustmark policies that are managed in a trustmark legal framework. GTRI even envisioned a trustmark marketplace where trustmarks could be cataloged with metadata, and reused in a wide array of application domains.
Figure 9 illustrates the GTRI Trustmark Framework. (This is Figure 1 from [41] redrawn.) A Trustmark Defining Organization that represents a Stakeholder Community defines various Trustmark Definitions. A Trustmark Provider can issue various trustmarks based on those definitions to Trustmark Recipients that satisfy the trustmark requirements. A recipient can assemble these issued trustmarks into a Trust Interop Profile. When a recipient wishes to interact with a Trustmark Relying Party, such as various end-users or organizations, the trustmark profile must be presented. The Relying Party will verify that the trustmarks are signed by a Trustmark Provider that is trusted.
This arrangement of trusted Trustmark Providers that issue cryptographically signed trustmarks that are relied upon by end-users and organizations is clearly patterned after Public Key Infrastructure (PKI). Trustmark Providers are analogous to Certificate Authorities, while trustmarks are analogous to X.509 certificates. Relying Parties can validate these trustmarks/certificates with a trusted Trustmark Provider, in the same way that X.509 certificates can be validated with Certificate Authority.