OpenID & Strong Authentication CTST 2009: Emerging Technology D14: Smart Cards, Tokens & Digital Identity May 5, 2009 Brian Kelly Vice President TrustBearer Labs
Simplify Multi-factor authentication can be made easier to use and implement by utilizing Web Single Sign On (SSO) standards SAML 2
SAML Enterprise focused Bulk-provisioning (onthe-fly supported) Identity Provider is internal to organization (typically) Commercial and OS products available Consumer focused On-the-flyprovisioning Many identity providers available online for consumers to choose Mostly open-source, and COTS services 3
How does SAML work? verifies signed assertions Login Web Page creates signed assertions App 1 User is logged-in to web app SAML ID Provider App 2 authenticates s App 3 LDAP Other Auth. SAML Service Providers (consumers) 4
How does OpenID work? Consumer Web App Page Login Web app verifies previously enrolled OpenID User is logged-in to web app Consumer Web App OpenID Relying Party (consumer) User authenticates to IDP and enables account to be used with consumer site 5
End-point authentication is agnostic of SSO standard All methods can be supported by SAML or OpenID name / password one time password (OTP) tokens smart cards (e.g. PIV, CAC, FRAC) TPM client digital certificates information cards biometrics image verification 6
Identity Provider offers endpoint authentication options Google, Yahoo, AOL: password myopenid: password, phone verify, client certificate, info card VeriSign PIP: OTP, client certificate, info card, EV SSL TrustBearer: smart cards (CAC, PIV, etc.), biometrics Vidoop: Image recognition (CAPTCHA) The IdP can specify authentication methods used to the RP, which can even request preferences. 7
What authentication method to choose? 8
Required Protections for OMB s E-Auth Assurance Levels Protect against Level 1 Level 2 Level 3 Level 4 On-line guessing Replay Eavesdropper Verifier impersonation Man-in-the-middle Session hijacking From NIST SP 800-63 p. 39 9
Token Types Allowed At Each Assurance Level Token Type Level 1 Level 2 Level 3 Level 4 Hard Crypto Token One-time password device Soft crypto token Passwords & PINs From NIST SP 800-63 p. 39 10
OpenID Provider Authentication Policy Extension (PAPE) Provides a way for Relying Parties to request / view authentication policies of Identity Provider Policies: Phishing-resistant, Multi-Factor, and Physical Multi-Factor Preferred authentication levels e.g. NIST: 1, 2, 3, 4 SAML also allows authentication attributes to be added to a message 11
TrustBearer OpenID What we do What we could do Challenge/response with PIN or Bio verification Allow multiple tokens per account Implement PAPE No name / password option Some SAML support Path validation & revocation checking Use SReg to transmit data on card Allow RPs to request certain smart cards or tokens be used More SAML Support 12
How Government OpenID with smart card auth could work Citizen Web App Page Login OpenID + Sreg + PAPE Data sent to Gov t Web app, Info is verified Citizen is logged-in to web app U.S. Gov t Gov t Web App OpenID Relying Party (consumer) Web app (RP) includes U.S. Gov t OpenID Provider on it s trusted list User is directed to government OpenID provider, which uses CAC / PIV Smart card to authenticate 13 Path Validation & Certificate Revocation Checking
In-the-cloud strong-auth benefits over traditional Client Auth with SSL Less infrastructure / less coding Path validation & revocation checking work is offloaded to Identity Provider Authentication methods can scale up and down depending on application needs Non-cert data on smart card becomes useful (e.g. healthcare) 14
Questions? https://openid.trustbearer.com Brian Kelly brian.kelly@trustbearer.com twitter.com/trustbearer Vice President TrustBearer Labs