Federal ICAM Information Sharing Day and Vendor Expo

The Federal Identity, Credential and Access Management Subcommittee Announces the ICAM Information Sharing Day and Vendor Expo

On November 27^th, the Identity, Credential, and Access Management Subcommittee (ICAMSC) will hold the ICAM Information Sharing Day and Vendor Expo. The focus of this ICAM Information Day and Vendor Expo will be the use of PIV credentials in systems such as Physical Access Control Systems (PACS), Logical Access Control Systems (LACS), mobile devices and cloud services. The participating vendors will demonstrate their latest information assurance and security products and services related to the use of the PIV.

LOGISTICS/VENUE INFORMATION  

The ICAM Information Day and Vendor Expo will be held on November 27, 2012 in coordination with the Smart Cards in Government Conference which will be held November 28^th – 30^th at the following location:

Washington Convention Center
801 Mount Vernon Place Northwest, Washington, DC 20001

There will be no fee for federal employees and contractors with PIV attending the ICAM Information Day event.

REGISTRATION INFORMATION

Those attending ICAM Information Day and Vendor Expo should register at the following site: www.GovSmartID.com

AGENDA

Please note that the agenda is subject to change.

Timeframe	Description	Speaker
9:00 – 9:15	Welcome and Opening Remarks	Deb Gallagher (GSA) and/or Paul Grant (DoD)
9:15 – 10:00	Keynote Address: Enabling CAC/PIV in a Mobile Government Workforce	Rob Carey (DoD)
10:00 – 12:00	Opening of the Vendor Exhibits
12:00 – 12:30	Lunch break (lunch not provided)
12:30 – 1:00	Security Policy and Standards for Use of Mobile Devices on Federal Networks	Carol Bales (OMB)/ Donna Dodson (NIST)
1:00 – 1:30	Expectation of PIV use with Logical Access Systems	Bill Erwin (DoD)
1:30 – 2:00	Expectation of PIV use with Mobile Devices	Deb Gallagher (GSA)
2:00 – 2:30	Expectation of PIV use with Physical Access Systems	Will Morrison (FAA)
2:30 – 3:00	Afternoon Break (vendor exhibits will remain open)
3:00 – 3:15	FIPS 201-2 Status	Hilde Ferraiolo (NIST)
3:15 – 3:30	Update on FY FISMA Metrics for PIV Use	Glen Lee (DOE)/ Rajeev Pillai ( GSA)
3:30 – 3:45	Trust Framework Update	Anil John (GSA)
3:45 – 4:15	Open Discussion	Deb Gallagher (GSA) and/or Paul Grant (DoD)
4:15 – 4:30	Closing Remarks	Deb Gallagher (GSA) and/or Paul Grant (DoD)

Challenges in Operationalizing Privacy in Identity Federations - Part 3

Part 1 of this series discussed the data minimization principles of anonymity, unlinkability and unobservability and their relationship to identity federation. Part 2 of this series walked through a proxy architecture that provides those principles in a federated authentication system. In this blog post, I would like to expand the discussion of the proxy architecture to include user enrollment and see how the data minimization principles are affected by the need for verified attributes.

In the proxy architecture, when a user arrives for the first time at the relying party (RP) after being authenticated by the IdP/CSP, the RP knows:

1. A trusted IdP has authenticated the user, 
2. The Level of Assurance (LOA) of the credential used, and 
3. The Persistent Anonymous Identifier (PAI) associated with the credential of the authenticated user. 

Assumption: As part of the identity proofing and credential issuance process, the IdP/CSP has collected and verified information about the user (which is a requirement for LOA 2+ scenarios).

The RP starts the user enrollment process by collecting both a shared private piece of data (e.g. account #, access code, SSN etc.) that represents a claim of identity and a set of information (e.g. Name, Address, DOB etc.) that can be used to prove that claim from the user. The data elements that are collected by the RP needs to be a subset of those verified and collected by the IdP/CSP as part of the identity proofing and credential issuance process.

The RP then initiates the attribute verification process:

• The request is made via the proxy to maintain the PAI to PPID mapping and the PPID to CID mapping
• The request is for a MATCH/NOMATCH answer and NOT a "Give me all the attributes you have collected during identity proofing"
• The shared private data (e.g. Account #, Access Code, SSN etc.), which is ALREADY in the RP system, is NOT sent to the IdP/CSP

If the response that comes back from the IdP/CSP is positive, the RP:

• Uses the shared private piece of data to pull up the associated user record 
• Checks to see if the verified attributes returned match those in the user record
• If they match, the RP links the PAI to the associated user record locator a.k.a. Program Identifier (PID)

Critical points to note here are that the IdP still does not know which RP the user went to, the RP still does not know which IdP the user is coming from, but the Proxy now has visibility into the attributes flowing through it.  As such, it is critical to make sure that a security policy backed by an independent audit and verification regime is put in place to assure that the proxy does not collect, store or log the attribute values flowing through it.

We would be interested to hear about how this architecture can be improved or modified to enhance its privacy characteristics.

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Challenges in Operationalizing Privacy in Identity Federations
• Challenges in Operationalizing Privacy in Identity Federations - Part 2
• How To Implement the Technical Aspects of an Identity Oracle
• Nat Sakimura: Privacy Enhancement for Open Federated Identity/Access Management Platforms (PEOFIAMP) R&D Project

:- by Anil John

What are FICAM Technical Profiles and Identity Schemes?

A critical technology underpinning of the FICAM Trust Framework Solutions process is the need to enable the ability of the federal government to utilize industry standards. This blog post provides an overview of the FICAM protocol profiling work that enables the federal government to utilize industry standards in a secure and interoperable manner.

As anyone who has been involved in technical protocol standards development will know, a finalized standard is often a compromise. In particular there is a great tension around the need to provide flexibility and extensibility, security and privacy, and interoperability in the standards development process. The result often ends up being a standards document that provides multiple ways of accomplishing the same thing, all of which are "compliant" to the standard but often may not be interoperable.

For the federal government to utilize industry standards, they need to be widely deployed by multiple vendors, interoperable, and meet the security and privacy policy requirements articulated by authoritative federal government bodies such as OMB, NIST, CIO Council etc.

This requires the standard to undergo a "Profiling" process that:

• DOES NOT change the standard in any way
• DOES take into consideration security requirements of the federal government
• DOES take into consideration privacy requirements of the federal government
• Locks down the MUSTs, SHOULDs, SHOULD NOTs etc. in the specification language so that there is assured interoperability between profile implementations
• Results in a "Test-able" product

When this process was initially envisioned, we were very much focused on authentication.  As such, the end result of the profiling process was the development of "portable identity schemes" which enabled the use of identity federation protocols to convey information for the purpose of authentication.

The "FICAM Profile of SAML 2.0 for Web SSO (PDF)" and the "FICAM OpenID 2.0 Profile (PDF)" are clear examples of portable identity schemes that incorporate standards profiling. We will continue to utilize identity schemes as an item that an identity provider needs to implement in order to interoperate securely with a federal government relying party (service provider).

As our requirements have grown, we have found it necessary to expand beyond authentication to areas such as attribute exchange, authorization and more. Profiles such as the "SAML 2.0 Identifier and Protocol Profiles for BAE v2.0 (PDF)" and "SAML 2.0 Metadata Profile for BAE v2.0" stand on their own and are not authentication related.

We expect this to continue and expand in the future.

As an example, the currently underway work on the "FICAM Profile of OAUTH 2" is not an identity scheme, given that OAUTH 2 requires an additional authentication layer to convey identity information. Once the OAUTH 2 profiling is complete, we will be working to identify and profile the pieces that make up that additional identity layer. The combination may result in a FICAM approved portable identity scheme that utilizes OAUTH 2.

In short, going forward we expect to continue our work to profile protocol standards such that they are usable by themselves, as well as use profiles as building blocks to enable portable identity schemes.

RELATED INFORMATION

• FICAM Technical Profiles and Identity Schemes

:- by Anil John

How To Implement the Technical Aspects of an Identity Oracle

In the age of attributes, personal data, and data brokers, the concept of Identity Oracles and how they can help to mediate between diverse entities is something worthwhile to consider.  This blog post provides a short introduction to the Identity Oracle concept and discusses the work FICAM is starting in order to address the technical intersection of Identity Oracles and Attribute Providers via a new Backend Attribute Exchange (BAE) Protocol Profile.

The original definition of an "Identity Oracle" which was coined back in 2006 by Bob Blakley, the current NSTIC IDESG Plenary Chair, is:

• An organization which derives all of its profit from collection & use of your private information…
• And therefore treats your information as an asset…
• And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information…
• Thus keeping both the Relying Party and you happy, while making money.

While that applies to commercial entities pretty well, let me tweak that a bit for the Government sector:

• An organization which is the authoritative source of some of your private information…
• And is constrained by law and policy to safeguard your information…
• And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information, with your consent and without disclosing your information…
• Thus keeping both You and the Relying Party happy, while enabling you to conduct safe, secure and privacy preserving online transactions

A potential technical interaction between the three entities could be:

1. Person establishes a relationship with the Identity Oracle. The Identity Oracle provides the person with token(s) that allow the person to vouch for his relationship with the Identity Oracle in different contexts
2. When the Person needs to conduct a transaction with a Relying Party, he presents the appropriate token, which establishes his relationship to the Identity Oracle
3. The Relying Party asks the Identity Oracle “Am I allowed to offer service X to the Person with a token Y from You under condition Z?”. The Identity Oracle answers “Yes or No”

Conceptually, this type of question is something you would want to ask an Attribute Provider, but current protocols for attribute query and response are really not set up to enable this type of capability.  So putting aside the business and policy aspects, which are huge, a technical piece that needs to happen is to define how the interaction in step (3) above can happen using widely deployed protocols.

Based on multiple information sharing use cases that have come up, and an internal review of need and value, we have decided to address this requirement within FICAM by working to define a "XACML 3.0 Attribute Verification Profile for BAE 2.0":



The intent of this effort will be to profile XACML 3.0 messages on the wire, not for authorization, but to enable the construction of a verification request and corresponding response, while keeping the message level and transport level security mechanisms consistent between this new profile and the original SAML 2.0 Identifier & Protocol Profile for BAE 2.0.

RELATED POSTS

• Attributes Anytime, Anywhere. Extending BAE to Support New Protocols
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Challenges in Operationalizing Privacy in Identity Federations - Part 2

Federation implementations enabling privacy enhancing characteristics such as anonymity, unlinkability and unobservability are something that we are very interested in for Government service delivery. This blog post describes one such approach using a proxy mechanism between the identity provider and the relying party and articulates some of the trade-off's inherent in such an approach.

The typical identity federation scenario with an externalized Identity/Credential Provider and a Relying Party looks something like this:

• User's credential identifier (CID) is not released to RP. FICAM Identity Schemes require a Pairwise Pseudonymous Identifier (PPID) to limit the loss of anonymity and unlinkability; IdP keeps track of that mapping internally
• The Program Identifier (PID) is a user record identifier that only the RP know about, and the RP establishes the one-time PPID to PID mapping via the user enrollment process
• The IdP knows about the RP the user is interacting with so there is no mitigation for the loss of unobservability

If implementing this using SAML 2.0, this would be the classic SAML Web SSO Sequence Diagram with a persistent identifier for NameID:



One approach that would bring additional privacy enhancing characteristics into this mix is the implementation of a Proxy between the Identity Provider and the Relying Party:

• CID to PPID mapping is the same as before. Limits loss of anonymity and unlinkability
• When a PPID comes into the proxy, it generates an associated Persistent Anonymous Identifier (PAI) which is then released to the RP. The proxy manages the persistent PPID to PAI mapping. 
• Limits loss of unobservability, since IdP has no visibility into which RP the user has gone to or the identifier that they are using at that RP 
• RP know that a trusted IdP authenticated the user and the associated LOA level but nothing more
• RP manages the PAI to PID mapping
• The proxy knows of the IdP and the RP but knows nothing other than the PPID and the PAI
• Forensics requires coordination across IdP, Proxy and RP

As an aside, I would like to acknowledge our colleagues at TBS Canada for how they defined PAI and PID (PDF); I saw no value in coming up another term to describe the same items, so decided to simply leverage their definitions.

If implementing this in SAML 2.0, the sequence diagram with the proxy taking on both IdP and RP roles as needed would look like:



This architecture works brilliantly as a privacy enhanced credential mediation service and it can very easily be implemented using current technical protocols. But it does require the responsibility for identity proofing (before enrollment) to rest with the RP. So some questions that need to be explored are:

• How can the RP gain access to the attributes collected during the identity proofing stages by the IdP/CSP?
• Can all or most of the privacy characteristics still survive when attribute movement comes into play for user enrollment?

Any insights and lessons learned on working with this type of architecture would be appreciated.

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Challenges in Operationalizing Privacy in Identity Federations
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Challenges in Operationalizing Privacy in Identity Federations

A critical part of the job of an identity/information management professional is to operationalize privacy in the systems they architect, build and deploy. Unfortunately, it is easier to make that statement than to come up with a rigorous and repeatable process to do it. It is hard because privacy is contextual in nature, and data often moves across organizational and system boundaries where shared context may not exist. This blog post is an attempt to articulate some definitions and considerations regarding operationalizing privacy within the narrow realm of identity federation.

NIST, in its DRAFT SP 800-130 "A Framework for Designing Cryptographic Key Management Systems" (PDF) articulates the three privacy characteristics (Section 4.7) of Anonymity, Unlinkability and Unobservability:

An information management and security policy may state that users of the secure information processing system can be assured of anonymity, unlinkability, and unobservability, if these protections are required. Anonymity assures that public data cannot be related to the owner. Unlinkability assures that two or more related events in an information processing system cannot be related to each other. Finally, unobservability assures that an observer is unable to identify or infer the identities of the parties involved in a transaction.

In his write-up of the NIST CKMS Workshop, Dr. Francisco Corella had this to say as it relates to identity federation:

"[...] One way of reducing the number of passwords to be remembered is to rely on a third-party identity provider (IdP), so that one password (presented to the IdP) can be used to authenticate to any number of relying parties. The Federal Government allows citizens to access government web sites through redirection to several Approved Identity Providers.

But third party login has privacy drawbacks. In usual implementations, anonymity is lost because the relying party learns the user’s identity at the IdP, unlinkability is lost by the use of that identity at multiple relying parties, and unobservability is lost because the IdP is informed of the user’s logins. Profiles of third-party login protocols approved for citizen login to government sites mitigate some of these drawbacks by asking the identity provider to provide different identities for the same user to different relying parties. This mitigates the loss of anonymity, and the loss of unlinkability to a certain extent. (Relying parties by themselves cannot track the user, but they can track the user in collusion with the IdP.) But the loss of unobservability is not mitigated, because the IdP is still informed of the user’s activities.

I believe that the Government should work to develop and promote authentication methods that eliminate passwords while preserving anonymity, unlinkability and unobservability."

Agreed.

The Fair Information Practice Principles (FIPPs) are a core part of the NSTIC vision for the Identity Eco-System, and more concretely, a critical part of the Federal Government's implementation of that vision (FICAM). The FICAM Identity Schemes (i.e. Protocol Profiles for Authentication) require the use of pair-wise pseudonymous identifiers to mitigate the loss of anonymity and loss of unlinkability. The loss of unobservability is still very much a concern, which is why as we move out on our FCCX initiative, we are specifically calling out the issue of "panopticality" as something that is critical for us to address.

We are investing both attention and resources to this area, but have little desire to build a closed eco-system of proprietary technologies with limited interoperability that becomes expensive technology road-kill due to lack of support in the marketplace.

We need the help of standards bodies, technology vendors and other stakeholders in making sure the ability to support these privacy characteristics are baked into the current and future generation of identity protocols and standards. Even more so, we need support for these privacy enhancing characteristics to be adopted and used in the implementations of the same protocols and technologies by the identity thought leaders in this space so that Government can leverage and utilize them as part of delivering Citizen facing services.

RELATED POSTS

• Challenges in Operationalizing Privacy in Identity Federations - Part 2
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

How To Collect and Deliver Attributes to a Relying Party for User Enrollment

In order for user enrollment to work at a Relying Party (RP) it needs a shared private piece of data that represents a claim of identity (e.g. SSN, Drivers License #) and a set of information that can be used to prove the claim. The manner in which the RP obtains the latter depends to a great degree on the identity verification model that is used. This blog post describes the steps and considerations regarding attribute movement for the purpose of user enrollment.

The steps in this process, from the perspective of the RP, are:

1. Determine the minimal set of attributes (attribute bundle) needed to uniquely identify a person, map them into an existing record at the RP or create a new record if it does not exist
2. If the attributes are Personally Identifiable Information (PII), implement the necessary protections (both policy and technology) needed to safeguard them during collection, transit, and at rest
3. Determine who will collect, verify and bind the attributes to an identifier, and if the assurance level of that binding is acceptable
4. Determine the secure mechanism needed to move the attributes from the entity that collected them to the Relying Party

1. Determine the minimal set of attributes

• What is the minimum set of attributes needed to uniquely identify a person within a system?
• Can we standardize this "attribute bundle" across multiple systems? e.g. Does the combination of Social Security Number, Date of Birth, State of Residence serve to uniquely identify  a person? More? Less?

2. Implement PII Protection on collected attributes 

• Has a Privacy Impact Assessment been done that includes clear identification of the data needed and collected?
• Do you have the authority to collect this information? How will you track and verify user consent?
• Have you implemented technical and policy protections on PII information as required?

3. Who will collect and verify the attributes?

• Will the attributes be collected and verified by an Identity/Credential Provider or a Registration/Identification Service?
• Will the attributes be collected by the Relying Party and be verified directly or by leveraging a third party service?
• Is the verification of attributes and the binding to an identity comply with NIST 800-63-1(PDF) identity proofing requirements?
• If the verified attributes provided by the IdP/CSP/AP are not sufficient, do you need to implement the ability to request the data directly from the citizen or implement an attribute request/verification capability with a third party service? 

4. How will you securely move the attributes?

• How will you move the verified attributes from an IdP/CSP/AP to the RP?
• Will the attributes be sent every time by the IdP/CSP/AP to the RP? Is there a mechanism to provide a hint regarding first time enrollment?
• Does support for using an out-of-band attribute call to the IdP/CSP/AP exist with all entities in the flow? If needed, what will you use as the identifier?
• Does the ability to capture and pass consent regarding attribute release exist?

One other attribute movement mechanism that is often used by Enterprise as an IdP, is to out of band provision an RP via some sort of an Identity Bridge mechanism. That particular use case comes into play when you are connecting the Enterprise to a SaaS Provider. That use case is out of scope.

Feedback on how you are implementing these types of capabilities in your Enterprise would be appreciated. Are there additional or different approaches or considerations?

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Assurance Level Escalation and Government Relying Parties
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John