1C/ Fido 2 101

FIDO 2 101

Session Convener: John Bradley and David Waite

Notes-taker(s): George Fletcher

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

FIDO 2

• FIDO 2 is a marketing term for two specs
  • WebauthN - Level 2 in W3C
    • JS API between RP and browser
  • CTAP2.1 - FIDO Alliance
    • Client To Authenticator Protocol (CTAP) - browser to hardware key

CTAP 2.0

• V2 added multi factor auth and discovery of keys (?)
• V2.1 - cleaned up stuff in V2, added privacy features, fixed stuff for FIPS certification
  • Supported by Chrome on OS x and Linux
  • Microsoft Edge maybe in the fall
  • Apple - unknown date
• V2.2 - just started work on this
• Firefox/Safari at WebAuthn Level 1

U2F

• Predecessor to CTAP 2.0
• RP’s should no longer user the U2F API
• RP’s should switch to the new API

Actors in the FIDO environment

• Relying Party - Server+web/native app
• Client - Browser/OS
• Authenticator - Key/Platform
  • WebAuthN is Javascript API for RP to Browser/OS
  • CTAP is hardware protocols for Browser/OS to hardware Authenticator

History of FIDO2

• Originally named Nubby - effort between Google and Yubikey

U2F protocol API

• Make Credential - Invoked by RP
  • Challenge
  • Browser invoked Authenticator with Challenge and adds the AppID (now RPID)
  • Authenticator
    • Challenge
    • AppID Hash
    • Generate key pair based on AppID Hash
    • Generate credential ID
  • Returns…
    • Credential ID
    • Auth Data
    • Assertion
    • Public Key
  • Goes back to RP
• This API is stateless as the key/authenticator doesn’t store any data
• When the user wants to authenticate
  • Invoked by RP with challenge + credential ID [] - list
  • Browser invokes Authenticator (getAssertion)
    • AppID
    • Credential ID List
    • Browser iterates through the Cred ID list
  • Authenticator
    • uses the AppID and Cred ID to see if it’s one understood by this key
    • also receives authenticator data hash
    • Decode the Credential ID in order to regen the pub/priv key pair
    • Signs over client data and authentication data hash
    • Send back an assertion
  • RP verifies…
    • RP auth data matches it’s site
    • the assertion is signed by the correct public key
• Built for second factor use
  • credential data is not stored on the key
  • RP does first factor and then based on that knows the information to send to the browser to validate the second factor

WebAuthN W3C standard (level 1)

• • AppId -> moved to being origin based (foo.example) -> now RPID
  • Backward compatible with U2F
  • Add support for the key to manage state and store credentials
  • “Does the user have a way to login to my site”? based on data stored in the key
    • Display name for the user provided for the stored data to allow the user to distinguish
      • • account id
        • friendly name
        • email address
      • Useful for password less based login
      • Browser will display the “account chooser”
      • RP gets a signed assertion containing the identity the user selected
    • Supported everywhere except Chrome on Android and Firefox on linux and OS x
      • not supported at all on Android
    • Have something in all the browser
  • UX is problematic for different platforms
    • OS level UX is required
    • From user perspective the UX is still very confusing
  • WebAuthN Level 2
    • Fixing issues found during the rollout of resident credential support
    • RP gets to choose whether the credential should be discoverable
    • In CTAP2.1 added enterprise related features
    • minimum pin length requirements
    • limited to specific enterprise configured RPIDs
    • biometric enrollment
    • Set different privacy levels
    • cred protect level 2
    • getAssertion will not find the key unless the user has done some authentication (biometric or pin)
    • Credential Management API
  • WebAuthN Level 3 - pushing for broader adoption
    • Goal to migrate off of passwords
    • Make it easier for people to get out of storing passwords
    • RP adoption is difficult and desire level 3 to address these issues