Draft FIPS 201-2 Top 10 changes
27 April, 2011
category:
By Salvatore D’Agostino, CSCIP, IDmachines LLC
IDmachines and other colleagues attended a workshop last week at the Department of Commerce National Institute of Standards and Technology in Gaithersburg, Md. on the draft FIPS 201-2.
The workshop enabled NIST, other government agencies and industry to discuss the initial changes and to propose other changes to PIV standard. FIPS 201-1 has more than 5 years of experience and the issuance of millions of credentials to consider as the new draft goes forward. The comment period for FIPS 201-2 closes June 6.
FIPS 201 is one part of a number of initiatives on the part of the Federal government around identity and cybersecurity. The Federal Chief Information Officer Council has released the draft of the Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance, Part B that goes into the use of PIV credentials for both logical and physical security. The FICAM effort also includes the Trust Framework Provider Adoption Process for lower assurance levels to both structure and a range of identity tokens.
Companions to FIPS 201 and the FICAM include the National Strategy for Trusted Identities in Cyberspace (NSTIC) that was recently released by the White House and which is managed about of a program office at NIST. Besides NSTIC the CIO Council, the General Services Administration and the Federal PKI Management Authority have promoted the expansion of PIV to organizations outside of Federal employees and contractors with PIV-Interoperability or PIV-I.
Understanding the activity around identity on the part of the United States Government needs to look at these things–and other related activity–as a whole.
As part of the overview to workshop NIST presented its “top ten” list of the changes to FIPS 201. While not exactly ready for Letterman it provides and excellent overview of what is changing in the document.
Annotated NIST FIPS 201-2 Top 10
1. Asymmetric Card Authentication Key is mandatory
The asymmetric card authentication key provides interoperability over the contactless interface. Previously optional, the key now provides a mandatory contactless PKI component. A symmetric key is also available as an option in addition to and in combination with the asymmetric key. This enables a practical approach to key management in a federated environment while providing options for speed and enterprise specific keys.
2. Introduction of enrollment record or chain of trust as maintained by the issuer.
The document puts an emphasis on chain of trust with good reason particularly given the interoperability goals of FIPS 201. There are a number of reasons where the chain of trust helps to improve the economics and reduce the effort when you take lifecycle considerations into account.
Some of these benefits of this include: eliminates complete re-enrollment, eliminates recapturing biometrics and background Investigation may not need to be repeated.
3. Iris recognition as an additional biometric modality is introduced.
The draft proposes using a standard image–which then requires non-standard template/model creation and matching. Further testing and recognition rates were discussed and will likely be forthcoming and build on existing Iris Exchange (IREX) work at NIST.
Iris biometrics bring benefits that include:
- Alternative in the case where fingerprints cannot be obtained as a basis of biometric binding of the individual to the credential
- Iris can be used as an authentication method.
An increasing number of vendors and applications use cases around iris matching and the draft now enables these to be part of an organizations identity toolkit.
4. Standards based technology advancement is really about Optional On Card Biometric Comparison (OCC) coincidentally called match on card. (Question here is should it be optional or should it be mandatory?)
OCC use cases include enrollment, authentication, and PIN reset. Gilles Lisimaque, from ID Technology Partners, raised an interesting point on degrading the number of authentication factors if you combine PIN and BIO in the reset transaction.
5. ISO 24727 as a means of providing interoperability for smart card identification, authentication and digital signatures.
It is a six part standard with the sixth part including a registration authority procedure. NIST discussed registering a PIV authentication profile and provides secure channel features and discussed a forthcoming Special Publication 800-xx on secure contactless communications.
6. Optional feature for card authentication to address issues related to the Rehabilitation Act and Section 508 and access to electronic and information technology procured by Federal agencies.
7. Maximum length of printed name was extended and provides flexibility with dealing with printed names.
Good to have a name people want on the front and this helps in that regard–though it is still the case you can’t put the apostrophe in D’Agostino on a PIV card.
I would add that the real naming issue is related to making the UUID the baseline identifier and that electronic naming trumps printed. It would be nice if UUID was mandatory–will be in DOD–as is the case with PIV-I.
8. Replace indicator for National Agency Check with Investigations (NAC-I) with a background investigation indicator.
This addresses PIV-I where certain populations of cardholders are not applicable for a NAC-I. Indicates that a national background investigation indicator service would be put in place.
9. Allow post issuance updates to PIV card.
This aligns with the desire to have the card live through two three-year certificate cycles and have a six-year life. This also ties to #2 chain of trust to enable the update.
10. Put employment eligibility verification background documents–I9–into the FIPS 201 specification.
This helped clarify some of the background document requirements as it represents the specific items accepted. Interesting not to have included a TWIC.
As a close and an aside one of the interesting things about PIV-I and PIV-I is the ability to use it as an identity credential to get other access credentials, for example, SAML, JSON Web Tokens, OpenID, etc. And while this document only refers to credentials acceptable as background for a PIV card its interesting to think about the ability to register with PIV and PIV-I and their related authentication factors and attributes.