Adapting Levels of Assurance for NSTIC

1,414 views

Published on

Presentation from Internet Identity Workshop, May 2011 on ways that Level of Assurance can be adapted to better mesh with the National Strategy for Trusted Identities in Cyberspace (NSTIC). More discussion is at http://blogs.cisco.com/security/adapting-levels-of-assurance-for-the-nstic/

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,414
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Adapting Levels of Assurance for NSTIC

  1. 1. Adapting Levels of Assurance for NSTIC<br />Jim Fenton <fenton@cisco.com><br />
  2. 2. LOA Requirements (M-04-04)<br />“E-Authentication Guidance for Federal Agencies”<br />Dated December 16,2003<br />Issued by Office of Management and Budget<br />Specifies four levels of assurance and when they should be used<br />
  3. 3. M-04-04 Levels of Assurance<br />An indicator of risk/value of the transaction<br />Drives authentication and identity proofing requirements<br />
  4. 4. Impact of Authentication Errors<br />Impacts consider both potential harm and likelihood<br />Categories:<br />Inconvenience, distress, or damage to standing or reputation<br />Financial loss or agency liability<br />Harm to agency programs or public interests<br />Unauthorized release of sensitive information<br />Personal safety<br />Civil or criminal violations<br />Degree of impact<br />Low, Moderate, or High within each category<br />Severity and duration of effect<br />
  5. 5. Maximum Potential Impacts by Assurance Level<br />
  6. 6. NIST SP 800-63<br />“Electronic Authentication Guideline”<br />Issued April 2006 (v1.0.2) by NIST<br />Technical guidelines for how authentication should be done in response to M-04-04<br />Currently being revised by NIST<br />
  7. 7. SP 800-63 Requirements<br />Observation: A lot of existing authentication is done in plaintext<br />We are at level 0!<br />Question: Is proofing an authentication issue or an attribute issue?<br />
  8. 8. Attribute and “Identity” Providers<br />NSTIC distinguishes between “Identity” and Attribute Providers<br />Identity Providers authenticate and provide authentication assertions<br />Pseudonymity implies that other assertions don’t automatically come with authentication<br />Proposal: Fully separate authentication from all other attributes<br />IdP provides referrals to attribute services<br />Question: Isn’t identity proofing an attribute provider, not an authentication requirement?<br />Suggesting separation of proofing from authentication requirements in SP 800-63 revision<br />
  9. 9. How does this work?<br />Effective LOA = min(LOA of authentication, accredited LOA of authentication provider, LOA of attribute binding, accredited LOA of attribute provider)<br />LOA of attribute binding is determined by (lesser of):<br />Attribute provider’s confidence in attribute<br />LOA of authentication used at enrollment with provider<br />Effective LOA maps to M-04-04 requirements<br />
  10. 10. Why do we Care?<br />Identity Providers are the users’ agents in the identity world<br />Require the most trust from the user<br />Therefore user choice is important<br />Removing the proofing requirement enables many more IdPs<br />Can issue LOA 4 hardware token without in-person transaction<br />An arms-length relationship between credential and attribute providers is good for privacy<br />
  11. 11. References<br />OMB M-04-04, “E-Authentication Guidance for Federal Agencies”:<br />http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf<br />NIST Special Publication 800-63, “Electronic Authentication Guideline”<br />http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf<br />My blog series on NSTIC (will be addressing this)<br />http://blogs.cisco.com/tag/nstic-series/<br />

×