Draft Special Publication 800-63-3 - Virginia

Draft Special Publication800-63-3Digital Identity Guidelines(formerly known as Electronic Authentication Guideline)SP 800-63-3Digital IdentityGuidelinesSP 800-63AIdentity Proofing &EnrollmentSP 800-63BAuthentication &Lifecycle P 800-63CFederation &Assertions

Why the update? Implement Executive Order 13681:Improving the Security ofConsumer Financial Transactions Align with market and promote(adapt to) innovation Simplify and provide clearerguidance International alignment

Highlights from the PublicComment PeriodJanuary – May 20174900 540 1113Views onGithubUniqueVisitorsComments 800 142 239AcceptedDuplicatesDecline/Noted

Significant Updates

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

SP 800-63-3DigitalIdentityGuideline

In the beginning OMB M-0404Issued 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 AssuranceCost/ComplexityWe got a problemLOA2LOA1LOA3LOA4Increased confidence in: vetting and credential useOA] mitigates the risk associate of a potential authentication error

EO 13681SP 800-63-2What’s wrong with LOA2?identity proofingLOA1LOA2 LOA2 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 throughdigital applications require the use of multiple factors ofauthentication and an effective identity proofing process, asappropriate.”

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 samecould be inappropriate

A real exampleAssessed at LOA1:No proofingSingle factor authNShould be:IAL1: No proofingAAL2 (or higher): Multifactor authN

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 assessmentgoes away, RiskManagement Framework’adorned’ with identityrisks and impacts Agencies have risk-basedflexibility But if they take it, a digitalidentity acceptancestatement is needed*OMB reserves the right to change said plan

New ModelNewOldIALIdentity AssuranceLevelAALLOALevel of AssuranceLOA1LOA2LOA3AuthenticationAssurance LevelIAL1IAL2IAL3AAL1AAL2AAL3Robustness 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 usedin a given transaction into asingle, increasing scale

Identity Assurance Levels(IALs)Refers to the robustness of the identity proofingprocess and the binding between an authenticatorand a specific individualIALDescription1Self-asserted attribute(s) – 0 to n attributes2Remotely identity proofed3In-person identity proofed (and a provision for attendedremote)

Authenticator AssuranceLevels (AALs)Describes the robustness of confidence that a givenclaimant is the same as a subscriber that haspreviously authenticatedAALDescription1Single-factor authentication2Two-factor authentication3Two-factor authentication with hardware authenticator

Federation AssuranceLevels (FALs)Combines aspects of the federation model, assertionprotection strength, and assertion presentation used in agiven transaction into 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

So go ahead and mix-n-matchAAL1AAL2AAL3IAL1 withoutPIIAllowedAllowedAllowedIAL1 with edAllowed

Choose Your Own AAL

Choose Your Own IAL

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 verification Unacceptable, Weak, Fair, Strong,SuperiorWhat’s newwith IDProofing Moves away from a static list ofacceptable documents and increasesoptions for combining evidence toachieve the desired assurance level Visual inspection no longer satisfactoryat higher IAL TFS-related requirements are gone Reduced document requirements insome instances Clearer rules on address confirmation

Expanding &Clarifying IdentityProofing Options Virtual in-person proofingcounts as in-person Remote notary proofing Remote selfie match Trusted referees

No restrictions in theresolution phase of IDProofing Highly restrictive inverification phase Strict and clear rules on theuse of KBVs Definition of proper/allowabledata sources Prefers knowledge of recentTx over static dataKnowledge BasedVerification’s Rolein IdentityProofing Cannot be standalone

SP 800-63BAuthentication &LifecycleManagement

AuthenticatorsMemorized SecretsMulti-Factor OTPDevicesLook-up SecretsSingle FactorCryptographic DevicesOut-of-Band DevicesMulti-FactorCryptographic SoftwareSingle Factor OTPDeviceMulti-FactorCryptographic Devices

Authenticator GuidanceChanges“Token” is out“Authenticator” is inGreater allowance for biometrics, but with rulesSMS OTP RequirementsOTP via email is outPre-registered knowledge tokens are out

New authenticators at AAL3 (akaLOA4)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(Action Item 1.3.2*)* Action Item 1.3.2: The next Administration should direct that all federal agenciesrequire the use of strong authentication by their employees, contractors, andothers using federal systems.“The next Administration should provide agencies with updated policies and guidancethat continue to focus on increased adoption of strong authentication solutions, includingbut, importantly, not limited to personal identity verification (PIV) credentials.”- Commission on Enhancing National Cybersecurity, Report on Securing and Growingthe Digital Economy, December 1, 2016

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

ReauthenticationAAL DescriptionTimeout1Presentation 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 Claims vs. ValuesMaturity ModelHighFederationFederationNo FederationLowFederationJust ClaimsJust ValuesOver CollectionOver CollectionOldNewGive 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 claims and value APIRP SHOULD request claims

Retaining the NewDevelopment ApproachIterative – publish, comment, and update in a series of drafting n GitHub.Collectpubliccommentsvia GitHub.3Adjudicatecomments onGitHub.5Closepubliccommentperiod.

Contributing During esCSRC.nist.govEmail usingcommentmatrixAll emailcommentswill be madeinto GitHubissues

Advanced Contribution OptionStable VersionWhere to sendpull requests

What’s NextPublic Draft Comment Periodopens January 30, 2017closes March 31, 2017 May 1, 2017 (-3 only)Final Documentexpected Summer 2017Implementation Guidance Operations Manual/Implementation Guidev0.1 focused on proofing

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!

Backup

Highlights from the PublicPreviewMay – September 201612,000 3,600 250 Views ContributorsCommits

Draft 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-3