Special Publication 800-63-3 - NIST

Special Publication 800-63-3Digital Identity Guidelines(formerly known as Electronic Authentication Guideline)SP 800-63-3Digital IdentityGuidelinesSP 800-63AIdentity Proofing src.nist.gov/publications/PubsSPs.html#800-63-3SP 800-63BAuthentication &Lifecycle ManagementSP 800-63CFederation &Assertions

Why the update? Implement Executive Order 13681:Improving the Security of ConsumerFinancial Transactions Align with market and promote (adaptto) innovation Simplify and provide clearer guidance International alignment

Significant Updates

SP 800-63-3DigitalIdentityGuideline

In the beginning OMB M-04-04Issued in 2003Established 4 LOAsEstablished Risk Assessment MethodologyEstablished Applicability: Externally Facing SystemsTasked NIST with 800-63FIPS201/PIV Program Uses Same LOA Model

What are Levels of Assurance[LOA] mitigates the risk associate of a potential authentication errorCost/ComplexityWe got a problemLOA2LOA3LOA1Increased confidence in: vetting and authenticatorsLOA4

New ModelNewOldIALIdentity AssuranceLevelAALLOAAuthenticationAssurance LevelLevel of tness of the identityproofing process and thebinding between anauthenticator and a specificindividualConfidence that a givenclaimant is the same as asubscriber that haspreviously authenticatedLOA4FALFederationAssurance LevelFAL1FAL2FAL3Combines aspects of thefederation model, assertionprotection strength, andassertion presentation used ina given transaction into asingle, increasing scale

EO 13681SP 800-63-2What’s wrong with LOA2?identity proofingLOA1 LOA2LOA2 LOA3authenticators“ consistent with the guidance set forth in the 2011 NationalStrategy for Trusted Identities in Cyberspace, to ensure that allagencies making personal data accessible to citizens through digitalapplications require the use of multiple factors of authentication andan effective identity proofing process, as appropriate.”

Not to mention OMB M-04-04:LOA selected by “determining the potentialimpact of authentication errors”However, an authentication error is not a singleton:1: Authentication error attacker steals authenticator2: Proofing error attacker proofs as someone else and.Requiring authN and proofing to be the same couldbe inappropriate

Identity Assurance Levels (IALs)Refers to the robustness of the identity proofing processand the binding between an authenticator and a specificindividualIALDescription1Self-asserted attribute(s) – 0 to n attributes2Remotely identity proofed3In-person identity proofed (and a provision for attendedremote)

Authenticator Assurance Levels(AALs)Describes the robustness of confidence that a givenclaimant is the same as a subscriber that has r authentication2Two-factor authentication3Two-factor authentication with hardware authenticator

Federation Assurance Levels (FALs)Combines aspects of the federation model, assertion protectionstrength, and assertion presentation used in a given transactioninto a single, increasing scaleFALPresentation Requirement1Bearer assertion, signed by IdP2Bearer assertion, signed by IdP and encrypted to RP3Holder of key assertion, signed by IdP and encrypted to RP

Making 800-63 More Accessible800-63-3The Mother Ship800-63AIdentity Proofing &Enrollment800-63BAuthentication &LifecycleManagement800-63CFederation &AssertionsStreamlined Content & Normative LanguagePrivacy Requirements & ConsiderationsUser Experience Considerations

A future exampleHealth Tracker ApplicationOldModelNewModelAssess at LOA3 and unnecessarily proofindividualORAssess at LOA1 and use single-factor authNAssess at IAL1 because agency has no needto know identityANDAssess at AAL2 because the informationshared is personal data (EO 13681)

The Plan* OMB rescinds M-04-04 800-63-3 takes on digitalidentity risk managementand becomes normative eAuth risk assessment goesaway, Risk ManagementFramework ’adorned’ withidentity risks and impacts Agencies have risk-basedflexibility But if they take it, a digitalidentity acceptancestatement is needed*OMB reserves the right to change said plan

So go ahead and mix-n-matchAAL1AAL2AAL3IAL1 without PIIAllowedAllowedAllowedIAL1 with edAllowed

optionalIALAALFALGuidance is risk-based with some‘traps’

Choose Your Own IAL

Choose Your Own AAL

Choose Your Own FAL

Risk Based Feedback LoopAgency & NISTAgencyImplementationAgency & NISTDigital IdentityPracticeStatementNCCOEProjectsNew Rev XRev 3 Updates

Including step-wise guidance

SP 800-63AIdentityProofing &Enrollment

The Identity Proofing Process

Clarifies methods for resolving an ID to asingle person Establishes strengths for evidence,validation, and verificationWhat’s newwith IDProofing Unacceptable, Weak, Fair, Strong,Superior Moves away from a static list of acceptabledocuments and increases options forcombining evidence to achieve the desiredassurance level Visual inspection no longer satisfactory athigher IAL TFS-related requirements are gone Reduced document requirements in someinstances Clearer rules on address confirmation

Expanding &Clarifying IdentityProofing Options Virtual in-person proofing countsas in-person Remote notary proofing Remote selfie match Trusted referees Other innovations

An Example

No restrictions in the resolutionphase of ID Proofing Highly restrictive in verificationphase Strict and clear rules on the useof KBVs Definition of proper/allowabledata sources Prefers knowledge of recent Txover static dataKnowledge BasedVerification’s Role inIdentity Proofing Cannot be standalone

SP 800-63BAuthentication&LifecycleManagement

AuthenticatorsMemorized SecretsMulti-Factor OTP DevicesLook-up SecretsSingle Factor CryptographicDevicesOut-of-Band DevicesMulti-Factor CryptographicSoftwareSingle Factor OTP DeviceMulti-Factor CryptographicDevices

Authenticator Guidance Changes“Token” is out“Authenticator” is inNew biometric requirementsRestricted AuthenticatorsPassword changesOTP via email is outPre-registered knowledge tokens are out*****

New authenticators at AAL3 (aka LOA4)FIPS 140-2Level 1/Physical Level 3Level 2/Physical 3Why it matters M-05-24 Applicability (Action Item 1.3.2*)Derived PIV Credentials (Action Item 1.3.2*) Consumers already have these (Action Item 1.3.1)PIV Interoperability should expand beyond PKI (ActionItem 1.3.2*)* Action Item 1.3.2: The next Administration should direct that all federal agencies require theuse of strong authentication by their employees, contractors, and others using federalsystems.“The next Administration should provide agencies with updated policies and guidance thatcontinue to focus on increased adoption of strong authentication solutions, including but,importantly, not limited to personal identity verification (PIV) credentials.”- Commission on Enhancing National Cybersecurity, Report on Securing and Growing the DigitalEconomy, December 1, 2016

Restricted Authenticators Currently just OTP over PSTN Requires: Notification to user Alternative authenticator option

Same requirements regardless of AAL SHOULD (with heavy leaning to SHALL) be:PasswordGuidanceChanges Any allowable unicode character Up to 64 characters or more No composition rules Won’t expire Dictionary rules SHALL - Storage guidance to deter offlineattack (salt, hash, HMAC)

ReauthenticationAALDescriptionTimeout1Presentation of any one factor30 days2Presentation of any one factor12 hours or 30 minutes of activity3Presentation of all factors12 hours or 15 minutes of activity

SP 800-63CFederation &Assertions

800-63-CFederation & Assertions1Discusses multiple models & privacy impacts & requirements2Modernized to include OpenID Connect3Clarifies Holder of Key (HOK) for the new AAL 34Attribute requirements

800-63federationAnywhere assertions are usedIntra/inter-agency federated credentialsCommercial federated credentials(but 800-63-3 remains agnostic to any architecture)

Attribute References vs. ValuesMaturity ModelHighLowNo FederationOver CollectionOldFederationOver CollectionFederationJust ValuesFederationJust ReferencesNewGive me date of birth.I just need to know if they are older than 18.Give me full address.I just need to know if they are in congressional district X.New RequirementsCSP SHALL support references and value APIRP SHOULD request references

Retaining the New DevelopmentApproachIterative – publish, comment, and update in a series of drafting sprints12ReleasePublicDraft.4Update draftdocumentson GitHub.Collectpubliccommentsvia GitHub.3Adjudicatecomments onGitHub.5Close publiccommentperiod.

What’s NextImplementation Guidance Operations Manual/Implementation Guidev0.1 focused on proofingNew Volume-D: Vectors of Trustexpected 2018ErrataReleased in September, 2017

Fostering GrowthSeeking new ways to engage our stakeholdersin order to promote innovation and best practices,while reducing risk and avoiding an ever-constantlymoving ational

In Closing01020304Major UpdateInnovationInternationalParticipateBiggest update sinceoriginal version.Did we get it right?Focused on privatesector capabilities.Did we future-proof it?Need 1 less ofthese than # of countries.OK? Use cases?Not our document.It’s yours.Participate!

Special Publication 800-63-3 Digital Identity Guidelines (formerly known as Electronic Authentication Guideline) SP 800-63-3. Digital Identity Guidelines. SP 800-63A. Identity Proofing & Enrollment. SP 800-63B. Authentication & Lifecycle Management. SP 800-63C. Federation & Assertions. https://pages.nist.gov/800-63-3File Size: 3MBPage Count: 43