12 Identity Items for 2012 Includes FIPS 201-2

2012 promises to continue to progress the case for and the solutions to address the need for trusted interoperable, privacy enhancing digital identities.    With global fraud on the order of $1 trillion (not a typo) no one really questions the important role identity plays.  And this in turn drives the business case for strong authentication and trusted authorization across enterprise, e-commerce and device related applications.  So expect in 2012 to see:

1.  Federal Information Processing Standard 201-2 draft comments to be released for further comment and updated.  Of particular interest will be guidance on binding identity credentials to mobile devices and establishing secure contactless communications aiding the adoption of PIV and PIV-I.
2. Mobile devices become the credential form factor of choice, with an associated disruption in the credential marketplace.  Government will push for secure methods to use the devices and industry will take advantage of it.
3. The National Strategy for Trusted Identities in Cyberspace (NSTIC) moves into an operational phase, establishing a governance infrastructure and getting on track with pilots.
4. The Canadian government making strides.  In contrast to the NSTIC, Canada has already awarded production contracts for branded credentials and credential brokering services, bringing banks, government and technology vendors together to provide solutions for governments and citizens.  This provides a basis for comparison between a government led (Canada) and an industry led (USA) approach.
5. On-line fraud, theft and other crimes become the primary focus for government and law enforcement both in terms of cybersecurity as well as cyberwarfare.
6. JSON web tokens, OAuth, OpenID Connect, SAML 2.0 and SCIM progress as standards and/or with interoperability testing.
7. Normalization of attributes becomes possible as a result of the profiles developed and the lessons from interoperability testing.  The identity conversation expands to include attribute providers as well as identity providers and their certification, level of assurance and business models.
8. Convergence is redefined as the impact of intelligent devices are felt across use cases and eliminates the distinction and separate requirements between personal and business technology and the on-line and physical world.
9. Convergence, further accelerated by cloud computing and web services, will raise the bar on software to be more robust, RESTful and to work on platforms of indeterminate configurations.
10. Solutions to protect personal data and provide individual control of personal data including adoption of User Managed Access (UMA) become mainstream.
11. A focus returns to the requirements for registration of identity and attributes in ways other than self assertion including the best practices called out in FIPS 201.
12. Identity analytics become part of the core set of enterprise services, joining administration, authentication, authorization and audit as the 5^th A.

The Differences Among PIV, PIV-I and CIV Credentials

IDmachines put together the following for the Smart Card Alliance newly renamed Access Control Council in support of one of its first deliverables.  

Homeland Security Presidential Directive 12 (HSPD-12) mandates a standard for a secure and reliable form of identification to be used by all Federal employees and contractors.  Signed by President George W. Bush in August 2004, HSPD-12 initiated the development of a set of technical standards and issuance policies (FIPS 201) that create the Federal infrastructure required to deploy and support an identity credential that can be used and trusted across all Federal agencies.

The policy, processes and technology in FIPS 201 support multiple other special publications (SPs) specifically written for FIPS 201 and build on other National Institute of Standards and Technology (NIST) standards and SPs that support best practice across information technology and security domains.  Importantly these standards also build on international and national standards such as the Internet Engineering Task Force (IETF), the International Telecommunications Union (ITU), the Institute of Electrical and Electronics Engineers (IEEE), the Security Industry Association (SIA), the International Standards Organization (ISO), the for the Advancement of Structured Information Standards (OASIS) and others.

		PIV		PIV-I	CIV
Policy
Breeder documents	Follows FIPS 201		Follows FIPS 201			Follows the organization’s policies
Background checks	National Agency Check with Investigation		None required, directly impacts level of suitability for access			None required, directly impacts level of suitability for access
Process
Application Adjudication Enrollment Issuance Activation	Follows FIPS 201, including separation of roles, strong biometric binding		Follows FIPS 201, including separation of roles, strong biometric binding			Follows the organization’s policies
Technology
Card data model	Must follow SP 800-73		Must follow SP 800-73			“Follows” SP 800-73
Current Primary Credential number	FASC-N		UUID			UUID (expected)
Object Identifiers	Federal Bridge		Federal  Bridge			Organization Internet Assigned Number Auhority (IANA)  (if exists)
Level of Assurance
Trust	High		Trusted identity and credential but not suitability of individual for access			None

The policy, process and technology applied to each of these credentials results in a level of assurance and interoperability and ultimately the extent to which you can trust and use it externally.  As shown in the chart the policy and process around PIV and PIV-I ultimately provide the interoperability and trust of the credential.  Identity and credential infrastructure requires an additional investment in order to adhere to and maintain these policies and processes.  In return users and organization can access ubiquitous identity and credential services with the benefit of high assurance in their federated transactions. 

PIV, PIV-I, PIV-C, CIV-C, IDm (It Don't matta)

The Smart Cards in Government conference last month brought together a very good group of users, solution providers and trade associations’ members to engage on the state of the practice on trusted identities and the use of secure elements.  IDmachines contributed to a pre-conference workshop on PIV-I physical access control and an e-Gov overview for the Kantara Identity Summit.    And despite budget challenges there remains work to be done with standards and programs (acronyms) such as NSTIC, ICAM, OpenID, OAuth, PIV and PIV-I.  

One set of acronyms that were described at the conference were PIV-I, PIV-C and CIV.  So to (quickly) go through how we got here...  First there was PIV (FIPS 201) that begat PIV-I that due to cost begat PIV-C.  When PIV-C became known as PIV compatible it was bad.  Compatibility was too close to interoperability in some minds so a new acronym was requested.  That this lead to the Commercial Identity Verification Credential and CIV, which has nothing to do with identity verification, is another topic for discussion, but onward with PIV-C.

Yes PIV-C as PIV compatible was bad, but PIV Counterfeit is exactly what it is and for this reason PIV-C is a useful way to look at it.  Further the reason it’s a counterfeit can be from the policy and procedures followed in issuing it as well as using un-trusted keys, certificates or other web tokens.  The government should have realized it’s the use case that it doesn’t like not the acronym, ergo PIV-C PIV counterfeit.  CIV should have never come to pass and it’s really not that good an idea to be out there.

Standards for identity proofing and agreement on the authoritative sources of attributes and privileges are one of the current gaps in the identity ecosystem.  PIV-C basically allows ad hoc enrollment and self assertion.  Technically you have a number keys, certificates, interfaces, and at present one or a small number of applets.  Easy to implement as physical access enterprise credential where there is no federation, but a web credential needs to be interoperable.  Is the National Strategy for Trusted Identities in Cyberspace developing un-trusted identities?  I am sure not.  Other part(s) of government’s paranoia over counterfeit credentials has wagged the dog and resulted in a classification that really didn’t need to exist.  There are already, albeit limited, enterprise multipurpose PKI credentials.  Really we should keep people focused on PIV-I and we should keep to a minimum PIV-C and CIV-C, etc.

Ironically, all during the conference it was easy to make this point.  I used a counterfeit credential.  Yes it was wrong and says so on the back, I didn’t do it with the intent of documenting it, and it was an immediate way to demonstrate to the members of the steering committees for the United States Federal government physical security and ICAM initiatives going in with me.  It helps to document security theatre.  I used my demo FRAC credential to get into the Reagan building. (My Federal colleague took a photo).  Test credentials are useful and very real looking.  Mine had a nice shiny chip, security lamination and 4 certificates of course all issued by a rouge certificate authority.  These hardly mattered since it was as a flash pass that I put it to work.  It doesn’t matter what acronym you give it, it’s a counterfeit flash pass.

This gets to the real point.  Rather than focus on acronyms focus on strong authentication.  This does not mean vague requirements but rather electronic verification including trust of the issuer.  

Counterfeits exist; ask any teenager, the way to beat them is not to rename them it’s to make sure you do a real job of checking them.  The security theatre of the flash pass at government buildings and for that matter at airports (ultraviolet pens?) has to cease. 

And it’s about more than authentication.  

1. Make sure you have established identities to the assurance level needed for individuals’ roles.
2. Make sure there is a separation of roles among the people enforcing the process
3. Make sure the identity is bound properly to the credential
4. Perform cryptographic challenge of the credential and validation of issuer along with checks against other access control (black and/or white) lists.
5. Don’t truncate the identifier (which is different than hashing them and yes, you will need to upgrade infrastructure to accomplish this).
6. Match the level of authentication to the assets being protected.
7. Protect secrets, personally identifiable information and the cryptographic processing.
8. Use standards based technology and policy.
9. Only procure systems that can do this.
10. Only procure systems from vendors and integrators that have demonstrated they can do this at a system level.  (The weakest link is the strength of the chain).
11. Implement and automate the controls that audit and alert to the above.

Guidance can and will need to provide more details including curriculum, security controls, specific approvals (products and certifications) that support the above.  This takes times (it’s been going on for decades).  Offer a glass of water (or age and situation appropriate beverage) not a fire hose.  While this may not be simple it can be simply said.  And it can start in a way that not an acronym need be found.

The Registration Authority : Why an Authoritative Identity Store Needs to be the First Investment in the Enterprise Identity Infrastructure

Best Practice Lessons from FIPS 201

Federal Information Processing Standard 201 titled Personal Identity Verification (PIV) (and the Draft FIPS 201-2) often gets thought of a standard defining the technology associated with strong authentication, digital signing and encryption using digital certificates and public key infrastructure (PKI).  While the standard and the underlying special publications do define the credential technology components an equally important part of the specification addresses best practices for establishing and identity and employment (enrollment) suitability. 

The first phase in the FIPS 201 process of establishing an identity that can provide high assurance and interoperability is a crucial aspect of the standard where PIV and PIV-I Interoperability (PIV-I) establish best practice and warrant focus by identity professionals.  This identity creation process needs to be a template for any trusted identity.  Much of what is written about PIV and PIV-I gets caught up in why PKI, when just as much, if not more, attention needs to be paid to why you need to create an enterprise identity service and the architecture to support this.  And fundamentally why there needs to be a single authoritative source for identity data also known as a registration authority.  This needs to be the case even if organizations have opted for identity as a service and outsourced their PKI.

One of the best results from the Federal Identity, Credential and Access Management (ICAM) initiative is the separation of the lifecycle management of each of the ICAM components.  In order to progress in the ICAM maturity model organizations must start with an enterprise service to support the identity creation function and as a result support the creation of a registration authority.  A registration authority can serve as a powerful focal point to implement policy for the creation of a range of credentials.  This can range anywhere from high assurance multi-step, multi-role, multi-person registration to doing self assertion via a simple web registration portal.

One of the important things that come from starting with the creation of a registration authority is the ability to create an identity vault that properly safeguards data.  The other significant benefit is that it invokes an architecture that properly restricts the frequency of access to data that by its very nature is long lived and does not need to be updated.  In fact the ICAM process has an underlying logic that comes from the inverse relationship to the frequency with which data needs to be accessed and its life-cycle.  Identity data is long lived and seldom needs to be accessed (but still needs to have a chain of trust maintained) while certification related attributes have shorter life-cycles and are more frequently accessed.  The following inverted triangle can be used to represent these relationships.

 

The enterprise registration authority and the associated identity vault sits at the bottom of the triangle.  It is the building block on top of which enterprises will implement ICAM.  It provides the foundation for enterprise governance, risk management and compliance by providing a common identity footing across these regimes and activity.  ICAM needs to be done in order; identity then credentials, then access, then management of other attributes and certifications.  In order to take the first step in getting the “I” in place a registration authority needs to be put in place and organizations need to look to PIV and PIV-I and the process they define.  When doing this organizations need to make sure they put in place a process that meets the highest level of assurance they will need to meet.  Supporting lower levels of identities is easy to do from a high assurance identity infrastructure.  Supporting higher levels of identity is extremely difficult if not impossible with a low level of assurance identity infrastructure.  The need to get things right at the start and to support the full range of use cases  is all the more reason to adopt PIV and PIV-I as enterprise policy for identity creation and to establish this as policy and a requirement for the enterprise registration authority.

There is a long standing lesson from manufacturing that building quality in to a process is much more cost effective than trying to add it on after the fact.  In building 21^st century identities quality (high assurance) needs to be built in at the beginning.  Getting identity (as opposed to simple identifiers) right necessarily needs to have a registration authority and the associated roles and policy that can meet the requirements as laid out in FIPS 201 and supported by the PIV and PIV-I frameworks.  In doing so organizations not only maximize the use cases they can support but also maximize the return on their identity infrastructure investment.