FCCX Requires Technology Innovation to

Implement Policy Requirements

by Jonathan Hare and Matt Woodhill, Resilient Network Systems

The Federal Cloud Credential Exchange (FCCX) needs to be architected to assure that NSIT SP 800-53 auditability requirements are incorporated in its offering while, at the same time, meeting FCCX mandatory requirements for anonymity, unlinkability and unobservability. Specifically, FCCX must be designed so that it provides the capability for Federal Agencies to rely upon FICAM-compliant identity providers and for these Agencies to audit for potential breaches and misuse.

The Details
The Federal Cloud Credential Exchange is being designed as a complementary implementation of White House’s National Strategy for Trusted Identities in Cyberspace (NSTIC) for Federal government agencies. The plan is that the FCCX will provide a common platform for agencies to interact with 3rd party credentials.

The US Postal Service will host the FCCX, and is defining the requirements for resolving the privacy and security concerns for a successful deployment of the FCCX service.

Specifically, the FCCX service must provide the following capabilities:
  • Anonymity assures that public data cannot be related to the owner.
  • Unlinkability assures that two or more related events from a relying party cannot be linked to events at a third party provider and vice versa.
  • Unobservability assures that an observer is unable to identify or infer the identities of the parties involved in a transaction.

As a result, the FCCX must be able to transmit credential information securely, without knowing the identities of the credential holders, and limit the ability of third party providers and relying parties to correlate the transaction activities of the credential holders. This traditional conflict over security versus privacy is likely to once again be a challenge. However, FCCX, if designed correctly, can be both scalable and sustainable, as long as it doesn’t rely on the limitations of traditional identity management models.

The Challenges of the Traditional Identity Exchange Model (see also, Federated Identity)
A valuable illustration of this conflict is described in a three part series of excellent blog posts by Anil John, Digital Security Expert at the GSA, which appeared on http://info.idmanagement.gov/ in October, 2012. These posts include a discussion of the privacy benefits of preserving anonymity, unlinkability and unobservability, as well as some possible technical approaches for authentication by identity providers (IdP) in a federated model.

In his second blog post, he describes a possible privacy protection mechanism wherein a proxy is placed between the IdP and the relying party,
and each communicates using distinct aliases (PPID and PAI) via the proxy, such that there is no way to directly link a specific granted credential to a specific relying party transaction:
  • Pairwise Pseudonymous Identifier (PPID) for the IdP
  • Persistent Anonymous Identifiers (PAI) for the relying party

While this proxy approach does indeed preserve anonymity, unlinkability and unobservability for user authentication, it doesn't offer similar privacy-preserving benefits for identity proofing or authorization management. Moreover, it becomes impossible for such a system to create effective audit controls  and  surveillance mechanisms, so that unauthorized access or inappropriate use can be detected and stopped. Thus, improved privacy comes at the expense of weakened security, as usual.

Anil points out a number of such unresolved issues, as follows:

1.    The proposed proxy architecture "…does require the responsibility for identity proofing (before enrollment) to rest with the RP (Relying Party)."

This is a very important limitation. Identity proofing to a high level of assurance has traditionally been expensive to attempt and very difficult to do well consistently. No one organization has come up with a cost-effective way to achieve high assurance identity proofing on a national scale. Also, the current means for identity proofing inevitably require users to reveal sensitive, personally identifiable information (PII) about themselves, which undermines their privacy, while increasing risk of breach and redundancy.

2.    "How can the Relying Party gain access to the attributes collected during the identity proofing stages by the IdP?" and "Can all or most of the privacy characteristics still survive when attribute movement comes into play for user enrollment?"

Here, Anil raises a couple of problems with a simple proxy architecture without suggesting how to solve them. These are key issues, because attribute verification is indispensable to authorization management, except for the most trivial consumer scenarios. Only certain, low-value scenarios function when authorization does not depend on identity/attribute verification. For limited use-cases, such as consumer online services where users are limited to accessing data they personally entered while logged into accounts they created, the online service does not need to verify the actual identity of the user to authorize them. However, even these consumer services may be ignoring regulatory requirements such as Children's Online Privacy Protection Act (COPPA), if they do not have proper privacy controls in place.

Yet this limited scenario does not reflect the vast majority of federal government applications, which involve enabling access by individuals who are the subjects of records (or by other authorized agents) to information about these individuals held in government systems – e.g. IRS and Social Security records, or protected health information derived from medical claims.

3.    'Forensics requires coordination across IdP, Proxy and RP.'

This third issue is particularly worth emphasizing. By 'forensics' Anil is talking about access control audit trails and the like, which are indispensable to robust security models. What he didn't explicitly say is that a simplistic implementation of the proxy mechanisms would make it impossible to create audit trails necessary to detect and mitigate security breaches. This is not something that Federal agencies and the FCCX can ignore, because they need to enable citizens (and other authorized users) to access information about them managed by these government systems.

Also, all of these agencies rely upon processes that involve sharing information among users, not simply enabling access by the subject of the records. The proxy mechanism is designed to make sure the IdP and RP cannot coordinate or understand the full context of the transaction, which would be necessary for a proper audit trail. Similarly, enabling single-sign-on across services requires verifying that both accounts are linked to the same person – without needing to know who that person really is.

This is not adequate for the vast majority of Federal government applications to maintain regulatory compliance, such as pursuant to NIST Special Publication 800-53.

  • Control Requirement AU-2 of that publication requires that a list of auditable events be defined, based on the security risks relevant to the context. Given that identity proofing, attribute verification and authentication mechanisms are never perfect, any robust security model requires a way to audit user attempts to enroll in a system and to access information. Such audit records must record enough context to support detecting fraudulent access by unauthorized users and inappropriate behavior by authorized users. The less robust your authentication and proofing mechanisms, and the more sensitive the information or functionality made available, the more important such audit and escalation capabilities are.
  • Control Requirement AU-3 specifies the content that must be included in an audit record, as follows: "The information system produces audit records that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event."

In other words, the relying party (which is responsible for maintaining audit records about its transactions) is required to include the identity of the user and the subject of the record in the audit record, and to implement a way of detecting potential breaches, as well as escalating to some means of mitigating such breaches. In practice, that means logging an audit record of how the user was authenticated, verified and proofed.

The FCCX service, then, must provide the capability to assure that the NSIT SP 800-53 requirements are incorporated in its offering.

Traditional Proxy and PPID/PAI models do not provide a means to detect and mitigate possible security breaches, since the relying parties have no access or link to the necessary data. A simplistic approach will not satisfy Federal regulatory requirements for audit trails while at the same time meeting the FCCX mandatory requirements for ensuring anonymity, unlinkability and unobservability.

The implications of this conflict are magnified by the FCCX intention to allow any Federal relying party to rely upon any FICAM-compliant identity provider. If FCCX is not architected correctly, then participating agencies will not be able to know what identity providers they are relying upon, and will have no way of auditing for potential breaches and misuse.

New Way Forward
The authors of this white paper are active members of the Identity Ecosystem Steering Group (IDESG) created to implement the National Strategy for Trusted Identities in Cyberspace (NSTIC) and are leading one of the five pilot programs funded by NSTIC through the Department of Commerce’s National Institute of Standards and Technology (NIST). As a result of these efforts, an Identity Ecosystem has been architected which makes it possible to eliminate this inherent conflict between enforcing privacy while enabling robust audit trails, by means of neutral network services for proxies, zero knowledge encryption/tokenization, and policy enforcement. Additionally, this architecture would support methods for usage tracking and charge-back, so the US Postal Service can bill clients and relying parties, and pay their IdPs. These capabilities are critically important to assure the scalability and sustainability of the Federal Cloud Credential Exchange (FCCX).


Part 1. http://info.idmanagement.gov/2012/09/challenges-in-operationalizing-privacy.html
Part 2. http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html
Part 3. http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy_29.html

              ©2013 Resilient Network Systems- Proprietary and Confidential