National Center for Supercomputing Applications University of Illinois at Urbana-Champaign NCSA Two Factor CA Jim Basney Adam Slagell Feb. 9, 2012

Need for another NCSA CA New Blue Waters system requires two- factor authentication (a new requirement at NCSA) Certificates accepted for Blue Waters login must come from a CA that also uses two- factor authentication Existing software only supports all-or-nothing CA trust (versus checking policy OIDs) IGTF accreditation required for XSEDE interoperability Not all Blue Waters users are XSEDE users (and vice versa)

Familiar CA architecture Same as existing NCSA SLSC CA but uses RSA SecurID tokens instead of Kerberos passwords Same user database and operational environment RSA PINs same complexity as Kerberos Tokens from new manufacturing process, post RSA breach

Familiar identity vetting process NCSA staff vetted through employee database PIs who are getting allocations are few and carefully vetted >70% of these come from NSF directly through the PRAC process Verified address through NSF Fastlane Other PIs either come through a peer-review process for Great Lakes Consortium ( or are special NCSA collaborators NCSA sponsors must verify addresses For UIUC allocations, we have verified addresses through HR system There are no unsponsored projects or unsolicited requests for allocations In all cases, we have verified addresses for the PIs (~100 over the system’s lifetime, initially)

How RSA tokens are delivered Two options: In person By postal mail

Getting tokens in person Must show government ID (e.g., state driver’s license) to NCSA allocations staff NCSA activates token and binds to NCSA account Users are also given their initial PIN, which is used in case they want to change their passcode, reset the token, or activate the replacement token

PIs getting tokens by postal mail Once a sponsor or a committee (e.g., PRAC or GLPC) decides to give a new account, the PI is sent an has a link with a nonce that can be clicked once and expires in 1 week The PI clicks on the link which presents them with the PI agreement and user AUP which they must accept The token and initial PIN is mailed to the verified address PIs must save their initial PIN if they ever want to reset the token or change their passcode The PI receives the token and uses the initial PIN to activate it and set a passcode NCSA sends to the PI alerting them of activation and passcode changes

Other users getting tokens by postal mail We delegate user identity vetting to PIs (like with other NCSA CAs) Once PIs have tokens, they can request tokens for additional users through a web portal PI provides user’s name & address NCSA sends with a unique one use URL (expires in 1 week) to the new user to begin the account creation process User clicks on link to accept AUP and submit postal address NCSA sends to the PI containing a URL for verifying the user’s information PI must log in to the portal with RSA token PI must verify the user’s postal address to prevent mistakes and interceptions (e.g., wrong John Smith) of the original Once the PI validates the address, the token is mailed to the user The user follows the same steps as the PI to activate the token A confirmation is sent to the user upon successful activation

Ready for CP/CPS and Operational Review CP/CPS in RFC 3647 format CA certificate, signing policy file, CRL Example user certificate CA DN /C=US/O=National Center for Supercomputing Applications /OU=Certificate Authorities/CN=Two Factor CA EEC DNs (same as other IGTF accredited NCSA CAs) /C=US/O=National Center for Supercomputing Applications /CN=FirstName LastName Serial# OIDs (NCSA Two Factor CA) (Short-Lived Credential Services) (Identity Vetting by a Trusted Third Party) (Key material held in files)