Federal ICAM Information Sharing Day and Vendor Expo

The Federal ICAM Information Sharing Day and Vendor Expo will take place on Tuesday, June 18, 2013 from 8:00 a.m. to 4:00 p.m.

This event will consist of presentations, panel discussions, and breakout sessions on pressing issues facing the Federal Government’s ICAM programs today. Attendees will also benefit from a vendor exhibit, showcasing technology solutions to satisfy ICAM needs.

This free event is open to government employees, contractors, and industry representatives (e.g., vendors).

LOGISTICS/VENUE INFORMATION  

The ICAM Information Day and Vendor Expo will be held on June 18, 2013 from 8:00 a.m. to 4:00 p.m. at the following location:

GSA One Constitution Square Building
1275 First Street NE, Washington

REGISTRATION INFORMATION

Those attending ICAM Information Day and Vendor Expo should register at the following site: http://www.gsa.gov/ICAMexpo

Special Information for Vendor Registration

If you plan to participate in the Spring 2013 ICAM Day’s Vendor Expo, please complete the registration process and choose your affiliation as a "Vendor". Upon registration, you will be contacted by the conference coordinator to provide additional details for exhibit coordination. ICAM Day vendor registration is free, but limited to the first 25 vendors.

AGENDA

Please note that the agenda is subject to change.

Timeframe	Description	Speaker
8:00 – 9:00	Registration
9:00 – 9:10	Welcome and Opening Remarks	Deb Gallagher (GSA) Paul Grant (DoD)
9:10 – 9:30	FIPS 201/FICAM Testing Program Update	Chi Hickey (GSA)
9:30 – 10:30	Panel Discussion: Attribute Exchange and Information Sharing in Action Panelists will share the latest updates on technology and approaches for attribute exchange and the importance of information sharing and safeguarding to the national cybersecurity agenda.	Anil John (GSA), Moderator David Coxe (ID DataWeb, Inc.) Dieter Schuller (Radiant Logic) Nathaniel (Ted) Sobel (DHS) John F. Wandelt (GTRI) Martin Smith (PM-ISE)
10:30 – 11:30	Panel Discussion: Externalizing Authentication Panelists will provide insights into how Agencies can externalize authentication using shared services. Participants include members of the OMB MAX Authentication Team as well as members of the Federal Cloud Credential Exchange (FCCX) Team.	Anil John (GSA), Moderator FCCX Team MAX.GOV Team
11:30 – 12:30	Lunch break (lunch not provided)
12:30 – 4:00	Vendor Expo
12:30 – 1:15	Breakout Session 1  FICAM Procurement [Government Only. PIV Required for Entrance] An interactive discussion with agencies with regards to challenges and gaps in procuring PACS components/systems from the Approved Products List. Potential discussion topics include breakdown of new PACS categories, severity levels/risks, ICAM test cards, development of acquisition language that complies with policy and meets agency needs, and defining acquisition requirements for relevant ICAM systems. Driving Mobility Forward with ICAM A discussion of current trends and technology within the mobile environment. Potential discussion topics include contactless, enterprise architecture, and strategies for supporting a mobile, remote workforce. Enterprise PACS Solution Best Practices A discussion of lessons learned, solutions, and processes to support implementation of agency-wide enterprise PACS and PIV-enablement. Potential discussion topics include managing risk, designing an enterprise PACS, and migrating to strong authentication using the PIV Card. Realizing the Value of ICAM A discussion of how to plan, implement, and measure an agency ICAM program focused on efficiency, cost-savings, and value. Potential discussion topics include the strategic importance of ICAM as a mission enabler, messaging ICAM to leadership, prioritizing and securing investments, and selecting cost-effective design and solutions for implementation.
1:20 – 2:05	Breakout Session 2  FICAM Procurement [Government Only. PIV Required for Entrance] An interactive discussion with agencies with regards to challenges and gaps in procuring PACS components/systems from the Approved Products List. Potential discussion topics include breakdown of new PACS categories, severity levels/risks, ICAM test cards, development of acquisition language that complies with policy and meets agency needs, and defining acquisition requirements for relevant ICAM systems. Driving Mobility Forward with ICAM A discussion of current trends and technology within the mobile environment. Potential discussion topics include contactless, enterprise architecture, and strategies for supporting a mobile, remote workforce. Enterprise PACS Solution Best Practices A discussion of lessons learned, solutions, and processes to support implementation of agency-wide enterprise PACS and PIV-enablement. Potential discussion topics include managing risk, designing an enterprise PACS, and migrating to strong authentication using the PIV Card. Realizing the Value of ICAM A discussion of how to plan, implement, and measure an agency ICAM program focused on efficiency, cost-savings, and value. Potential discussion topics include the strategic importance of ICAM as a mission enabler, messaging ICAM to leadership, prioritizing and securing investments, and selecting cost-effective design and solutions for implementation.
2:10 – 2:35	Accelerating the implementation timeline and reducing the cost of PIV in application by using Cloud services	Xceedium Amazon Web Services
2:35 – 3:35	Panel Discussion: Tackling an Evolving Mobile Environment Panelists will discuss approaches for addressing common mobility and security-related challenges. Panel will include agency representatives at different stages of program planning and execution, as well as participants from policy and technical viewpoints.	Donna Dodson (NIST), Moderator John Hickey (DOD/DISA) Tom McCarty (DHS) Adam Zeimet (USDA)
3:35 – 3:55	OMB ICAM Update [Government Only. PIV Required for Entrance]	Carol Bales (OMB)
3:55 – 4:00	Closing Remarks	Salomeh Ghorbani (GSA)

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)

New FICAM Guidance on using PIV and PIV-I Cards in Agency PACS

Incorporating stronger authentication technologies in an Agency Physical Access Control System (PACS), such as PIV and PIV-I cards, is a critical aspect of mitigating the risk of physical security breaches. FICAM recently published the "Personal Identity Verification (PIV) in Enterprise Physical Access Control Systems (E-PACS)" (PDF) document which provides detailed technical and security guidance for leveraging PIV and PIV-I authentication mechanisms in a federal agency PACS.

This is a comprehensive document that covers:

• The current PACS landscape
• The current standards and guidance that directly or indirectly affect PACS
• Enterprise PACS security functions, which describe specific and measurable security controls that impact the successful operation of PACS as a security countermeasure
• A comprehensive list of common authentication patterns that illustrate both proper and improper use of PIV and PIV-I authentication 

The Enterprise PACS security functions are broken down into:

• Technical Controls
• Identification and Authentication
• Access Control
• Audit and Accountability
• System and Communications Protection
• Operational Controls
• Configuration Management
• Contingency Planning
• Physical and Environmental Protection
• System and Information Integrity
• Awareness and Training
• Management Controls
• Security Assessment and Authorization
• Planning
• Risk Assessment

The authentication patterns, which include both good and not-so-good patterns, are one of the more informative parts of this document. They in turn align with the NIST SP 800-116 (PDF) authentication mechanisms as they pertain to gaining access to security areas.

The patterns themselves are provided using a standard format:

• Use Case Diagram
• Description
• Unmitigated Threats
• Pros, Cons, Issues
• Considerations

This document, which was produced by the FICAM Architecture Working Group, was a significant undertaking and reflects the many perspectives that go into deploying an effective PACS. The newly established FICAM Modernized Physical Access Working Group (MPAWG) will manage updates and changes to this document.

RELATED INFORMATION

• Personal Identity Verification (PIV) in Enterprise Physical Access Control Systems (E-PACS) v2.0.2 DRAFT (PDF) @ IDManagement.gov 

:- by Anil John

FIPS 201 Evaluation Program Industry Session Followup

The industry feedback day was very well attended, and we thank everyone for the constructive feedback you provided. Below is a recap of the main points that were touched upon during the session:

• Interoperability: GSA will be re-orienting the program to focus on the intent of HSPD-12; which includes both security and interoperability considerations for federal agency identity management implementations. This may require that existing categories be refined or deleted and new categories created to make them more understandable and relevant. New system/subsystem categorizations may also be required in order to form the basis for interoperability testing requirements.
  
  
• Standards & Specifications: With concurrence from both NIST and OMB, a Requirements Traceability Matrix that includes interoperability will use FIPS 201 as a starting point for conformance, but will also leverage the FICAM Roadmap and Implementation Guidance as well as additional relevant material to develop the interoperability requirements.
  
  While it will take some time to fully implement; we’re going to start identifying the minimum appropriate infrastructure subsystems and boundaries to support both PACS and LACS implementations, since a single PIV Card must work across both environments. The identification of subsystem-to-subsystem interfaces going forward can form the basis for developing the specification for each interface which in turn should drive standardization and interoperability.
  
  
• Industry/Lab(s) Interaction Process: Industry would like more visibility into the evaluation process, and to speed the certification process wherever possible. Vendors would like better definition of when product re-testing is required, especially when new standards are introduced (e.g., upcoming FIPS 201-2). The industry seemed to be open to new Lab involvement and even a mix (LACS, PACS, and Interoperability) going forward if it will speed up the process and reduce contracting complexity.
  
  GSA will also consider if and where vendor self-attestation might fit within the program evaluation process.

While we address the above in the medium to long term, there was concurrence that while the GSA APL continues to be a great starting point, improved categorization and additional information about product compatibility would enhance its utility for our Agency Customers in the near term. We will be looking to see how to make this possible.

Our next step is to hold an Agency Session on Tuesday, June 19 (9 a.m - 12 p.m. EST) at GSA OCS, 1275 First Street NE, DC (NY Ave Exit - DC Metro Red Line) to gather feedback from our Agency Customers. An invitation has already been extended to Agencies through their representatives to the ICAMSC and FPKI Working Groups. If you are an Agency representative interested in attending this session, please contact me [chi.hickey (at) gsa (dot) gov] for details.

:- by Chi Hickey

How to Verify Citizen Identity Easily and Effectively

Identity verification of citizens is critical to delivering high value government services online. Differing approaches to identity verification include front-end identification, which fits well with existing Government trust models, and back-end identification, based on widely deployed commercial practices. This blog post describes these two common models and the approach and trade-offs associated with each.

One of the reasons for trying to articulate this is that I have found myself recently in multiple settings discussing protocol flows and privacy preserving crypto.  But at the end of the discussion, I often feel as though we have not asked ourselves some foundational questions regarding choices made in identity proofing and credential issuance.  This in turn has resulted in a lack of clarity around the downstream impact of those choices on privacy, security and flexibility. So here goes...

 

The Front-End Identification is the same as the E-Authentication model that is found in NIST SP-800-63-1 (PDF). It follows the sequence of:

1. Person Registration/Identification
2. Binding of Identity and Token
3. Credential Registration/Issuance
4. Person Enrollment at Relying Party

Approach

Trade-Offs

Identity proofing is done up front by a credential provider with registration function or using a separate registration authority Credential incorporates assurances of identity User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]

Ability to leverage results of identity proofing across multiple relying parties RPs limited to approved credentials that meet assurance criteria May be harder to utilize a higher LOA credential in transactions that support anonymity and pseudonymity without "beautiful math" or other proxy mechanisms

 

The Back-End Identification is the E-Authentication model that is found widely deployed in the commercial space. It follows the sequence of:

1. Credential Registration/Issuance
2. Person Registration/Identification
3. Binding of Identity and Token at Relying Party
4. Person Enrollment at Relying Party

Approach

Trade-Offs

Credential is often little more than a token (i.e. shared secret) and may have little to no assurances of identity Identity proofing done directly by the RP or by using a separate proofing capability to the level required by policy User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]

Any token and/or combination of tokens can be used depending on the “technical strength” needed Proofing process can be as stringent as need be, so the information in credential can be as anonymous or revealing as need be Inability to leverage identity proofing across multiple RPs

 

Have I accurately captured the two major approaches in play right now? Are there trade-offs that you can think of that should be added to the lists above? 

 

UPDATED: 12/1/2012 with clarifying text and pictures re: where the token-identity binding takes place

 

RELATED POSTS

• Assurance Level Escalation and Government Relying Parties
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• How To Collect and Deliver Attributes to a Relying Party for User Enrollment

:- by Anil John

What is Certificate Path Discovery and Validation (PDVal)?

It came up recently in a meeting we were in that some folks are not sure of what is meant by PDVal, so thought I would provide an explanation. First some terminology:

The term "Certificate Path" is used to refer to a series of certificates issued by certificate authorities (CAs) to other CAs or users, e.g. Alice’s CA issues a Certificate to Bob’s CA, who issues a certificate to Bob, creating a certificate path from Alice’s CA to Bob.

Certificate Path Validation consists of two phases:

1. Trust Path Discovery
2. Trust Path Validation

Trust Path Discovery is the process of discovering the chain of cross-certificates and CA certificates running from the relying party's trust anchor to the end-entity's certificate. A trust path may be discovered dynamically each time as needed or it may be constructed once and cached.

Trust Path Validation is the process of examining each certificate that comprises the trust path, and consulting the issuing CA's CRL or OCSP responder to determine each certificate's validity status at that moment, as well as a number of checks such as policy mapping and signature validation.

Validating the policy mapping is needed since a particular CA may be able to issue certificates that map to different policy levels e.g. PIV, PIV-I, Medium Hardware etc. This is important because the processes used in order to identity proof someone (or other factors that are used in order to make a determination as to the "trust-ability" of a credential) may be different for the different types of PKI credentials that a CA is capable of issuing. e.g. Both PIV and PIV-I have the same identify proofing requirements, but PIV (which can only be issued by a Government Agency to its Employees and Contractors) also requires that the Applicant undergo a background check for suitability for Government employment.

PDVal standards fall under IETF PKIX and there is a comprehensive test suite developed by NIST called the Public Key Interoperability Suite (PKITS). The PKITS path discovery and validation test suite ensures that vendor products and/or services have been implemented according to RFC 3280 and work in a PKI Bridge environment.

This is a big deal in the US Federal Government as the Federal PKI Bridge is the Interoperability Trust Anchor for the US Government, and the ability to carry out certificate path validation is critical when the PKI credentials issued by one Agency's CA need to be validated by another Agency. In addition, Federal Information Processing Standard (FIPS) 201 requires agencies to validate that certificates comply with FPKI Common Policy when accepting PIV cards (Smart Cards issued by an Agency to its Employees and Contractors). PDVal is the only way to really do that.

As such, having products that can do PDVal as part of validating a certificate or having the ability to "outsource" that validation to a dedicated capability is something that we are very interested in. While vendors can use the PKITS to self-test, please note that the Federal PKI Management Authority does have a testing program that uses the NIST PKITS to independently verify PDVal capability.

[A quick note of thanks to Chris Louden @ PGS (who supports the FICAM Program) who has been a tireless, and often frustrated, proponent of PDVal for explaining some of the intricacies of PDVal to me]

:- by Anil John

PIV (Smart Cards), Active Directory and Authentication Events

One of the FICAM priorities for this year is to continue to drive the adoption of FICAM Approved Credentials, which include PIV Cards (HSPD-12 Credentials) for Government to Government usage.

Microsoft recently published an update to their PKI/AD document set that provides a :

[...] follow-up document to the original HSPD-12 Logical Access Authentication and Active Directory Domains document [...] The follow-up document demonstrates the increased flexibility of FIPS 201 PIV-II compliant smart cards with Windows Server® 2008 R2 Active Directory, Windows 7 and Office 2010. Included within this document are detailed steps to configure Windows Server 2008 R2 Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS), Windows® 7, and Microsoft® Office 2010 to perform traditional UPN based smart card logon, explicit smart card logon (client authentication certificate mapped to multiple accounts), explicit cross-forest smart card logon and NIST SP800-78-3 compliant S/MIME email exchanges

Both the original and the updated document can be found at the Microsoft Download site @ http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9427

Once enabled for PIV login, it is important to track the usage of PIV Cards in the Enterprise for reporting usage metrics. To that end, a starting point may be to take a look at the following piece of data found in Windows Auditing (Thanks to Alik and J.D. for this pointer):

"... use Windows Auditing events to track which logons are using username/password vs smart cards. Windows logs an event 672 (4768 in W2K8/R2) when an user logs on using Kerberos (i.e., gets a TGT), and in the Pre-Authentication Type part of the event you can see if the user was authenticated using a smart card (i.e., using PKINIT)"

More information regarding the above can be found at the Microsoft blog post on "Determining Whether a User Logged on Using A Smart Card"

What mechanisms (Open Source Tools, Scripts, COTS Solutions, etc.) are folks putting into place that would enable the automated monitoring and generation of usage metrics around Smart Card usage? Willing to share lessons learned?

UPDATE (6/18/12)

• Microsoft Technet: Find out if a Smart Card was used for logon using two ways to gather data
• Centralized data collection
• Client-side approach
• Powershell Script that reads UserTile information to provide logon Method of the currently logged on user

:- by Anil John