# Presentation: 548026

## NIST E-Authentication GuidanceSP 800-63

- NASA SEWP Security SymposiumJune 1, 2004
- Tim Polktim.polk@nist.gov

## Overview

- Motivation & Relationship to Other Documents
- Scope & Model
- 800-63 technical guidance
- PKI & E-Auth
- Status & Schedule

## NIST E-Authentication Tech Guidance

- OMB Guidance to agencies on E-Authentication
- OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies, Dec. 16, 2003
- _[http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf](http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf)_
- About identity authentication, not authorization or access control
- NIST SP800-63: *Recommendation for Electronic Authentication*
- Companion to OMB e-Authentication guidance
- Draft for comment at: _[http://csrc.nist.gov/eauth](http://csrc.nist.gov/eauth)_
- Comment period ended:  March 15
- Covers conventional token based remote authentication
- Does not cover Knowledge Based Authentication

## Assurance Levels

- OMB guidance defines 4 assurance levels
- Level 1 little or no confidence in asserted identity’s validity
- Level 2: Some confidence in asserted identity’s validity
- Level 3: High confidence in asserted identity's validity
- Level 4: Very high confidence in asserted identity’s validity
- Needed assurance level determined *for each type of transaction* by the risks and consequences of authentication error with respect to:
- Inconvenience, distress & damage to reputation
- Financial loss
- Harm to agency programs or reputation
- Civil or criminal violations
- Personal safety

## E-Auth Guidance Process

- Risk assessment
- Potential impacts
- likelihood
- Map risks to assurance level
- profile
- Select technology
- NIST Technical E-Authentication Guidance, SP800-63
- Validate implemented system
- Periodically reassess

## Potential Impact Categories for Authentication Errors

|  | Assurance Level Impact Profiles |  |  |  |
| --- | --- | --- | --- | --- |
|  | 1 | 2 | 3 | 4 |
| Inconvenience, distress, reputation | Low | Mod | Mod | High |
| Financial loss or agency liability | Low | Mod | Mod | High |
| Harm to agency prog. or pub. interests | N/A | Low | Mod | High |
| Unauth. release of sensitive info | N/A | Low | Mod | High |
| Personal safety | N/A | N/A | Low | Mod High |
| Civil or criminal violations | N/A | Low | Mod | High |

*Potential Impact Categories for Authentication Errors*

- Max. Potential Impacts Profiles

## Technical Guidance Constraints

- Technology neutral (if possible)
- Required (if practical) by e-Sign, Paperwork Elimination and other laws
- Premature to take sides in web services wars
- But SAML looks like it’s here to stay
- Difficult: many technologies, apples and oranges comparisons
- Practical with COTS technology
- To serve public must take advantage of existing solutions and relationships
- Only for ***remote***** **network authentication
- FICC is addressing credentials for building access for Fed. Employees and associates
- Only about identity authentication
- Not about attributes, authorization, or access control
- This is inherited from OMB guidance
- Agency owns application & makes access control decisions

## Personal Authentication Factors

- Something you know
- A password
- Something you have: a token
- for remote authentication typically a key
- Soft token: a copy on a disk drive
- Hard token: key in a special hardware cryptographic device
- Something you are
- A biometric

## Remote Authentication Protocols

- Conventional, secure, remote authentication protocols all depend on proving possession of some secret “token”
- May result in a shared cryptographic session key, even when token is a only password
- Remote authentication protocols assume that you can keep a secret
- Private key
- Symmetric key
- Password
- Can be “secure” against defined attacks if you keep the secret
- Work required for attack can be calculated or estimated
- Make the amount of work impractical
- Often hard for people to remember passwords that are “strong” enough to make the attack impractical

## Knowledge Based Authentication (KBA)

- Not covered in 800-63
- Symposium on 9-10 Feb. at NIST
- Can we just ask questions to authenticate users?
- People do it now
- “Walk-in” customers, real business need
- It’s the age of instant gratification
- Similar to ID proofing process, but without closing the loop
- Could view KBA as similar to passwords
- Only these passwords are not very secret
- Valid claimant might not know them all
- How can we quantify KBA, what are the standards?

## Biometrics

- Biometrics tie an identity to a real person
- Biometrics don’t make good secrets for conventional remote authentication protocols
- Hard to keep them secrets
- Limited number per person
- Can’t change or revoke them
- This is a feature, not a bug, it’s why biometrics are so useful
- Biometric authentication doesn’t depend on keeping it secret, it depends on being sure that it is a fresh, true biometric capture
- 800-63 makes limited use of biometrics
- NIST expects to hold a workshop on biometrics & remote authentication in the fall

## Multifactor Remote Authentication

- The more factors, the stronger the authentication
- Multifactor remote authentication typically relies on a cryptographic key
- Key is protected by a password or a biometric
- To activate the key or complete the authentication, you need to know the password, or poses the biometric
- Works best when the key is held in a hardware device (a “hard token”)
- Ideally a biometric reader is built into the token, or a password is entered directly into token

## E-Authentication Token Model 

- Five Functional Roles
***Claimant:**** *Wants to prove his or her identity
***Verifier:**** *verifies the claimant’s identity by proof of possession of a token
***Relying party:**** *Relies on an identity
***Credentials Service Provider (CSP):**** *Issues electronic credentials and registers or issues tokens
***Registration Authority (RA):**** *Identity proofs the subscriber
- Three Data Objects
***Token:**** *Secret used in an authentication protocol
***Electronic credentials****: *Bind an identity or attribute to a token or something associated with a claimant
***Assertion:**** *Passes information about a claimant from a verifier to a relying party

## E-Authentication Token Model

- A *claimant* proves his/her identity to a *verifier* by proving possession of a *token*, often in conjunction with *electronic* *credentials* that bind the identity and the token.  The verifier may then inform a relying party of the claimant’s identity with an *assertion*.  The claimant got his/her token and credentials from a *Credentials Service Provider (CSP)*, after proving his identity to a *Registration Authority (RA)*.  The roles of the verifier,  relying party, CSP and RA may be variously combined in one or more entities.

## Implementation

- Four Levels defined for
- Tokens
- Registration Process (ID Proofing)
- Authentication Protocols
- Includes requirements for credentials and assertions

## Tokens

- Hard token
- Cryptographic key in a hardware device
- FIPS 140 level 2, with level 3 physical security
- Key is unlocked by password or biometrics
- Soft token
- Cryptographic key encrypted under password
- FIPS 140 Level 1 or higher crypto module
- One-time password device (1TPD)
- Symmetric key in a hardware device with display - FIPS 140 level 1
- Generates password from key plus time or counter
- User typically inputs password through browser
- Password
- Password or PIN with conventional protocol
- Strong password used with special “zero knowledge” protocol

## Token Type by Level

| Allowed Token Types | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| Hard crypto token |  |  |  |  |
| Soft crypto token |  |  |  |  |
| Zero knowledge password |  |  |  |  |
| One-time Password Device |  |  |  |  |
| Strong password |  |  |  |  |
| PIN |  |  |  |  |

***Assurance Level***

## ID Proofing – Three Questions

- Is John Wilson a real person? Does a person named John Wilson with the claimed attributes exist?
- As a practical matter, if somebody lives for a while under a name, that person exists
- Is the applicant that John Wilson?
- Can John Wilson later repudiate his registration?
- John may say, “Look, you may have registered somebody as John Wilson, but it wasn’t me.”

## ID Proofing – is John Wilson a real person?

- Database entries
- Employment records, school records, credit records, voter rolls, tax records, DMV...
- Can’t easily get access to some databases
- Relationship and history with some organization
- School, employer, bank (know your customer), business customer...
- Paper credentials
- Drivers License, Agency ID, Birth Certificate, Passport
- Are the credentials confirmed by the issuer?
- Could be forgeries
- Generally requires in-person appearance at RA

## ID Proofing – is this the real John Wilson?

- In-person Picture ID
- compare applicant to John’s photo
- But, in-person registration is often expensive and inconvenient
- Compromise
- Make the applicant prove he/she knows a lot about John
- Close the loop: Make the applicant prove that he/she can get mail, make a call or get e-mail at an address associated with John in the records

## ID Proofing – can Joe repudiate registration?

- In-person Picture ID
- Keep a copy of John’s picture ID
- Better yet take John’s picture (or signature, fingerprint, etc.)
- But, in-person registration is often expensive and inconvenient
- Compromise
- Make the applicant prove he/she knows a lot about John Wilson, an impostor at least had to do his homework
- Close the loop: Make the applicant prove that he/she can get mail, make a call or get e-mail at an address associated with the claimed identity in the records – an impostor, if there was one at least had access to John’s address of record
- Record a voice at a phone number of record

## ID Proofing

- Level 1
- Self assertion, minimal records
- Level 2
- Remote or in-person; Modeled after OCC “know your customer” rules for banks
- In person: visual inspection of primary gov. photo-ID
- Remote: supply numbers for primary gov. ID and financial account number with records confirmation of one
- Notification to address of record
- Level 3
- Remote or in-person
- In person: present gov photo-ID, confirm ID with issuer or other records, confirm address ofrecord with ID or issuance process
- Remote: supply numbers for primary gov. ID and financial account number with records confirmation of one and confirm address of record
- Level 4
- In person proofing only
- 2 ID’s or database records, must confirm at least one
- Record a biometric
- Can later prove who got the token

## Auth. Protocol Type by Level

| Authentication Protocol Types | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| Private key PoP |  |  |  |  |
| Symmetric key PoP |  |  |  |  |
| Zero knowledge password |  |  |  |  |
| Tunneled password |  |  |  |  |
| Challenge-reply password |  |  |  |  |

***Assurance Level***

## Protections by Level

| Protection Against | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| Eavesdropper |  |  |  |  |
| Replay |  |  |  |  |
| On-line guessing |  |  |  |  |
| Active network attacks |  |  |  |  |
| Malicious host software |  |  |  |  |

***Assurance Level***

## Passwords

- Password is a secret (typically a character string) you commit to memory.
- Secret and memory are the key words here
- As a practical matter we often do write our passwords down
- A password is really a (weak) key
- People can’t remember good keys
- We all live in Password Hell – too many passwords
- And they try to make us change them all the time
- In E-auth we’re only concerned with on-line authentication
- Assume that the verifier is secure and can impose rules to detect or limit attacks
- What is the “strength” of a password?

## Attacks on Passwords

- In-band
- Attacker repeatedly tries passwords until he is successful
- guessing, dictionary, or brute force exhaustion
- Can’t entirely prevent these attacks
- can ensure they don’t succeed very often
- Out of band – everything else
- Eavesdropper
- Man-in-the-middle
- Shoulder surfing
- Social engineering

## In-Band Attacks on Passwords

- Targeted attacks
- Attacker is trying to find the password of a particular person
- “Guessing Entropy” is a measure of the difficulty attacker who knows the password frequency distribution has to find the password of a selected user.  This attacker will try every password for the selected user in order of decreasing probability.
- Untargeted attacks
- Attacker is trying to find anybody’s password, doesn’t care who
- Looks for users with commonly selected passwords
- “Min entropy” is a measure of how hard it is for an attacker who knows the password frequency distribution to fine any user’s password, we don’t care how.  This attacker will try the most common password(s) for all users.

## Password Strength – Min Entropy

- Level 1 – no min entropy requirements
- Level 2 passwords must have at least 10 bits of min entropy
- Level 3 passwords are being considered:
- Would require at least 12 bits of min entropy

## Password Strength – guessing entropy

- Over the life of the password the probability of an attacker with no *a priori* knowledge of the password finding a given user’s password by an in-band attack shall not exceed
- one in 216 (1/65,536) for Level 3
- one in 214 (1/16384) for Level 2
- one in 210 (1/1024) for Level 1
- Strength is function of both password guessing entropy, the system and how it limits or throttles in-band guessing attacks
- Many ways to limit password guessing attack
- 3-strikes and reset password, hang up on bad login attempt...
- Limited password life, but...
- Note that there is not necessarily a time limit
- Many things are trade-offs with help desk costs

## Rough Password Guessing Entropy Estimate

## PKI & E-Auth

- PKI solutions widely available
- Can use TLS with client certs. for levels 3 & 4
- May be the predominant solution for levels 3 & 4 in gov.
- Federal Identity Credentialing Committee
- Common Credential and Federal Identity Card
- Common certificate policy and shared service providers
- Gov. Smart Card Interoperability Standard (GSC-IS)
- Fed. Bridge CA and Fed. Policy Authority are PKI vehicle
- Non-PKI level 3 & 4 solutions
- One-time password devices in common use – can meet level 3
- Cell phones could be a good 1TPD platform
- Zero knowledge passwords for level 3 – not widely implemented
- Level 4 could be done with symmetric key tokens

## FPKI Certificate Policies

- Federal Certificate Policy
- Rudimentary, Basic, Medium and High
- Federal Policy Authority “maps” agency policy
- currently x-certified
- Medium: Treasury, DoD, Agriculture (NFC), NASA, DST ACES, Illinois
- High: State Dept & Treasury
- Common Certificate Policy
- Shared Service providers
- Citizen and Commerce Class
- Streamlined process based on memo of agreement rather than detailed review of CP & CPS

## ID Proofing in “Known” Infrastructures

- Cert policies
- Level 2: FBCA basic, Citizen & Commerce Class
- Level 3: FBCA medium, Common-SW
- Level 4: FBCA High, Common-HW
- At level 2
- Financial institutions regulated by the OCC can issue credentials for their customers
- Educational institutions can issue credentials for their students
- Employers can issue credentials for their employees

## Status & Schedule

- Almost there!
- Publication on or before June 7.
- Open issues:
- Level 3 can *theoretically* be achieved with passwords, but for all practical purposes it will not!

## Questions