View
1.747
Download
0
Category
Preview:
Citation preview
All Rights Reserved | FIDO Alliance | Copyright 20172
FEATURED SPEAKERS
Jeremy Grant,
Managing Director,
Technology Business
Strategy, Venable LLP
Brett McDowell,
Executive Director,
FIDO Alliance
Paul Grassi,
Senior Standards and
Technology Advisor,
National Institute of
Standards and Technology
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
http://csrc.nist.gov/publications/PubsSPs.html#800-63-3
Why the update?
• Implement Executive Order 13681: Improving the Security of Consumer Financial Transactions
• Align with market and promote (adapt to) innovation
• Simplify and provide clearer guidance
• International alignment
In the beginning…OMB M-04-04
Issued in 2003
Established 4 LOAs
Established Risk Assessment Methodology
Established Applicability: Externally Facing Systems
Tasked NIST with 800-63
FIPS201/PIV Program Uses Same LOA Model
What are Levels of Assurance
Cost/C
om
ple
xity
Increased confidence in: vetting and authenticators
LO
A1
LOA2
LOA
3
LOA4
We got a problem
[LOA] mitigates the risk associate of a potential authentication error
What’s wrong with LOA2?
SP
80
0-6
3-2
identity proofing LOA2~= LOA3
authenticatorsLOA2~=LOA1
EO
13
68
1
“…consistent with the guidance set forth in the 2011 National
Strategy for Trusted Identities in Cyberspace, to ensure that all
agencies making personal data accessible to citizens through
digital applications require the use of multiple factors of
authentication and an effective identity proofing process, as
appropriate.”
Not to mention…
LOA selected by “determining the potential
impact of authentication errors”
1: Authentication error = attacker steals authenticator
2: Proofing error = attacker proofs as someone else
OMB M-04-04:
Requiring authN and proofing to be the same
could be inappropriate
…and...
However, an authentication error is not a singleton:
Identity Assurance Levels (IALs)
• Refers to the robustness of the identity proofing process and the binding between an authenticator and a specific individual
IAL Description
1 Self-asserted attribute(s) – 0 to n attributes
2 Remotely identity proofed
3In-person identity proofed (and a provision for
attended remote)
Authenticator Assurance Levels (AALs)
• Describes the robustness of confidence that a given claimant is the same as a subscriber that has previously authenticated
AAL Description
1 Single-factor authentication
2 Two-factor authentication
3 Two-factor authentication with hardware authenticator
Federation Assurance Levels (FALs)
• Combines aspects of the federation model, assertion protection strength, and assertion presentation used in a given transaction into a single, increasing scale
FAL Presentation Requirement
1 Bearer assertion, signed by IdP
2 Bearer assertion, signed by IdP and encrypted to RP
3 Holder of key assertion, signed by IdP and encrypted to RP
Making 800-63 More Accessible
Streamlined Content & Normative Language
Privacy Requirements & Considerations
User Experience Considerations
800-63-3
The Mother Ship
800-63A
Identity Proofing &
Enrollment
800-63B
Authentication &
Lifecycle
Management
800-63C
Federation &
Assertions
New Model
LOALevel of
Assurance
IALIdentity Assurance
Level
AALAuthentication
Assurance Level
FALFederation
Assurance Level
Robustness of the identity
proofing process and the
binding between an
authenticator and a
specific individual
Confidence that a given
claimant is the same as a
subscriber that has
previously authenticated
Combines aspects of the
federation model, assertion
protection strength, and
assertion presentation
used in a given transaction
into a single, increasing
scale
Old New
LOA1 LOA2 LOA3 LOA4
IAL1
IAL2
IAL3
AAL1
AAL2
AAL3
FAL1
FAL2
FAL3
Authenticators
• Memorized Secrets
Look-up Secrets
Out-of-Band DevicesMulti-Factor Cryptographic Software
Multi-Factor Cryptographic Devices
Single Factor Cryptographic Devices
Multi-Factor OTP Devices
Single Factor OTP Device
Authenticator Guidance Changes“Token” is out
“Authenticator” is in
New biometric requirements
Restricted Authenticators
OTP via email is out
Pre-registered knowledge tokens are out
Password changes *****
New authenticators at AAL3 (aka LOA4)
FIPS 140-2 Level 1/Physical Level 3 Level 2/Physical 3
* Action Item 1.3.2: The next Administration should direct that all federal agencies
require the use of strong authentication by their employees, contractors, and
others using federal systems.
“The next Administration should provide agencies with updated policies and guidance
that continue 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 Digital Economy, December 1, 2016
Why 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*)
Restricted Authenticators
• Currently just OTP over PSTN
• Requires:
• Notification to user
• Alternative authenticator option
Discusses multiple models & privacy impacts &
requirements1
Modernized to include OpenID Connect2
Clarifies Holder of Key (HOK) for the new AAL 33
800-63-C Federation & Assertions
Attribute requirements4
Attribute References vs. ValuesMaturity Model
High
LowNo FederationOver Collection
FederationOver Collection
FederationJust Values
FederationJust
References
Old New
Give me date of birth.
Give me full address.
I just need to know if they are older than 18.
I just need to know if they are in congressional district X.
New Requirements
CSP RPSHALL support references and value
API
SHOULD request references
What’s Next
expected September
-D: Vectors of Trust
expected Fall 2017
New Volume
Errata
~= Operations Manual/Implementation Guide
v0.1 focused on proofing
Implementation Guidance
Fostering GrowthSeeking new ways to engage our stakeholders
in order to promote innovation and best practices,
while reducing risk and avoiding an ever-constantly
moving target.
GitHub
RegularUpdates
ImplementerDrafts
International
In Closing
01
Major Update
02
Innovation
03
International
04
Participate
Biggest update since
original version.
Did we get it right?
Focused on private
sector capabilities.
Did we future-proof it?
Need 1 less of
these than # of countries.
OK? Use cases?
Not our document.
It’s yours.
Participate!
All Rights Reserved | FIDO Alliance | Copyright 201729
INTERPRETING NIST GUIDANCE
NIST AUTHENTICATOR
ASSURANCE LEVEL 1
NIST AUTHENTICATOR
ASSURANCE LEVEL 3
NIST AUTHENTICATOR
ASSURANCE LEVEL 2
• Easily compromised credentials
• Credentials stored in the cloud
• Example: passwords (“memorized secrets”)
• Public Key Cryptography
• Credentials stored ON DEVICE
• Example: FIDO Authentication
• SMS OTPs now RESTRICTED
All Rights Reserved | FIDO Alliance | Copyright 201730
FIDO FOR NIST AAL3: SECURITY
FIDO AUTHENTICATION MEETS
NIST AUTHENTICATOR ASSURANCE LEVEL 3:
User credentials are on the user’s device and only ever
shares cryptographic “proof of possession” with applications running in the
cloud, which means:
• NO threat of re-used credentials harvested from someone else’s data breach
• NO potential for phishing, since it is technically impossible to share credentials
• NO real possibility of scalable attacks because the adversary must obtain the user’s physical device or remotely defeat the Restricted Operating Environment protecting the private key
All Rights Reserved | FIDO Alliance | Copyright 201731
DEPLOYING FIDO TO MEET NIST AAL3
3.5 BILLIONAVAILABLE TO PROTECT
ACCOUNTS WORLDWIDE
Easy + inexpensive to deploy
Interoperable
Reaches a variety of markets
FIDO protocols + security requirements defined
+ built into 360+ FIDO Certified products
AND…
Did you know… Popular apps like Google,
Facebook, PayPal, eBay + BoA are already
FIDO-enabled and meet NIST requirements
for the highest levels of strong
authentication!
All Rights Reserved | FIDO Alliance | Copyright 201732
Q & A
Jeremy Grant,
Managing Director,
Technology Business
Strategy, Venable LLP
Brett McDowell,
Executive Director,
FIDO Alliance
Paul Grassi,
Senior Standards and
Technology Advisor,
National Institute of
Standards and Technology
Recommended