1 / 9

NCSA Two Factor CA

NCSA Two Factor CA. Jim Basney ( jbasney@illinois.edu ) Adam Slagell ( slagell @illinois.edu ) Feb. 9 , 2012. Need for another NCSA CA. New Blue Waters system requires two-factor authentication (a new requirement at NCSA)

cala
Télécharger la présentation

NCSA Two Factor CA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NCSA Two Factor CA Jim Basney (jbasney@illinois.edu) Adam Slagell (slagell@illinois.edu) Feb. 9, 2012

  2. 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)

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

  4. 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 (www.greatlakesconsortium.org) 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, 20-40 initially)

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

  6. 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

  7. 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 email • Email 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 email to the PI alerting them of activation and passcode changes

  8. 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 & email address • NCSA sends email 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 email 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 email • 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 email is sent to the user upon successful activation

  9. Ready for CP/CPS and Operational Review • https://security.ncsa.illinois.edu/CA/ • 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=FirstNameLastName Serial# • OIDs • 1.3.6.1.4.1.4670.100.4.8 (NCSA Two Factor CA) • 1.2.840.113612.5.2.2.3 (Short-Lived Credential Services) • 1.2.840.113612.5.2.3.2.1 (Identity Vetting by a Trusted Third Party) • 1.2.840.113612.5.2.3.1.2 (Key material held in files)

More Related