Levels of Assurance in Authentication Tim Polk April 24, 2007
Credits Bill Burr and Donna Dodson co- authored SP and contributed much of the content in this presentation –Neither would be possible without them!
Why Levels of Assurance? Security Commensurate with Need One Size Does Not Fit All!
Overview A Cautionary Tale: FIPS 112 Current Events –OMB Memorandum –SP –The response to Things To Look Forward To…
FIPS 112, Password Usage Published May 1985 Established 10 factors and baseline criteria –Factor #1 was length range, and the baseline was four Included three example systems: –Password system for {Low, Medium. High} protection requirements
Why A Cautionary Tale? Agencies gravitated to the three example systems –They were intended as examples Agencies continued using them long after their time had passed –Moderate protection was 4-8 characters (uppercase, lowercase, digits) Prescriptive standards are easy to use, but don’t always lead to the best security
Current Events OMB Memorandum SP : Entity Authentication Agency & Industry Feedback
OMB Memorandum E-Authentication Guidance for Federal Agencies (12/16/2003) –Agencies classify electronic transactions into four levels of authentication assurance according to the potential consequences of an authentication error –NIST develops complementary authentication technical guidance to help agencies identify appropriate technologies –Agencies req’d to begin implementation in 90 days after NIST issues guidance
SP Scope: technical authentication framework for secret-based remote authentication (06/2004) –token types –registration & identity proofing –authentication protocols
The Players Token: is a secret, or holds a secret used in a remote authentication protocol Credential Service Provider (CSP): A trusted authority who issues identity or attribute tokens Subscriber: A party whose identity or name (and possibly other attributes) is known to some authority Registration Authority (RA): registers a person with some CSP Relying party: relies on claimant’s identity or attributes Verifier: verifies claimant’s identity
Level 1 Authentication Single factor: typically a password Can’t send password in the clear –May still be vulnerable to eavesdroppers Moderate password guessing difficulty requirements
Level 2 Authentication Single factor: typically a password –Must block eavesdroppers (e.g password tunneled through TLS) –Fairly strong password guessing difficulty requirements –May fall to main-in-the middle attacks, social engineering & phishing attacks
Level 3 Authentication 2 factors, typically a key encrypted under a password (soft token) Must resist eavesdroppers May be vulnerable to man-in-the-middle attacks (e.g. phishing & decoy websites), but must not divulge authentication key
Level 4 Authentication 2 factors: “hard token” unlocked by a password or biometric Must resist eavesdroppers Must resist man-in-the-middle attacks Critical data transfer must be authenticated with a key bound to authentication
Tokens Passwords Soft Cryptographic Tokens One Time Password Devices Hard Cryptographic Tokens
The Response It’s Fantastic –Finally, a basis to compare mechanisms! It’s Too Prescriptive –What about bingo cards? –What about remote biometrics? –What about knowledge based authentication? –What about combinations of tokens?
Things To Look Forward To… SP Part 1 (Secret Based Authentication) –Goal is distribution for public comment 3Q FY2007 SP Part 2 (KBA) –Goal is distribution for public comment 3Q FY2007 Research in remote biometrics
SP Part 1: Electronic Authentication Guideline Features more flexibility - and complexity –More classes of tokens Including bingo cards –Tokens in combination E.g., memorized secret with simple OTP –More support for assertions –More comprehensive Life Cycle
SP Part 2: KBA The electronic process of establishing confidence in a user ’ s identity by verifying personal attributes presented to an information system. KBA process consists of 2 parts: verifying that the identity actually exists and that the user is entitled to that identity.
Questions? /SP800-63V1_0_2.pdf