Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Adapting Levels of Assurance for NSTIC

2,941 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
  • Login to see the comments

  • Be the first to like this

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 />

×