TAGPMA Accreditation Review of TACC MICS CA Design

TAGPMA Accreditation Review of TACC MICS CA Design and CP/CPS (Update) Marg Murray Advanced Computing Systems Group Texas Advanced Computing Center (TACC) 17 July 2007 (revised)

Intro: TACC MICS CA Goals • Leverage existing Id. M infrastructures. • Simplify user credential acquisition and management. • Generate short-term X. 509 v 3 end entity certificates for academic science and research users relevant to TACC's campus, state, national and international research projects. TAGPMA F 2 F Banff 17 Jul 2007 2

First Candidate Id. M: UT-System Shibboleth Policy • Charter, Fees, Attributes, Federation Operating Procedures, Member Operating Procedures • Lo. A Technology • 17 Identity providers, (Id. Ps) 1 per campus • 10 federated applications • 1 external vendor Governance • Id. M Governing Board: Technical Operations, Policy Mgmt • Audit • Dispute resolution • https: //www. utsystem. edu/Ident. Mgmt/UTsys. Fed. Apply. asp TAGPMA F 2 F Banff 17 Jul 2007 3

U. T. System Id. M Roadmap Source: https: //idm. utsystem. edu/ Identity. Mgmtpage 4. pdf Color Key: Complete Current Development In-Progress Longer-term Future TAGPMA F 2 F Banff 17 Jul 2007 4

Possible Future Id. M Candidates … an evolving landscape • Bridged Relationships Arranged by the UTSystem Federation – Cross-certifying UT campus CAs with FBCA • University of Texas employs Verisign CAs • http: //www. cio. gov/fbca/ • Texas A&M Shibboleth Federation? • Maybe Texas Tech? TAGPMA F 2 F Banff 17 Jul 2007 5

UTShib Id. M Integration into X. 509 Certificate Workflow • CA – Establish policies and procedures – Process CSRs; Sign certificates • RA – Institution is authoritative (and responsible) for: • Phone directory (public) information • Org status and entitlements – Initial RA F 2 F meeting is authoritative for: • Project and allocation eligibility • VO membership TAGPMA F 2 F Banff 17 Jul 2007 6

In User and Relying Party Workflow • User – – – • Initial Identity Vetting with Id. M and with RA Authenticated Portal Login before anything else "Request a short-term X. 509 Certificate" Store cert somewhere(My. Proxy server; HW token, web browser) Generate a proxy to enable mutual authentication & delegation Present proxy to perform grid tasks; access grid resources Relying Party (relies on TACC CA, not directly on UT Id. P) – Load CA cert and signing policy – Accept cert from requesting user – Check expiration date and signature – Map DN to account in grid-mapfile – Honor user request – Log access TAGPMA F 2 F Banff 17 Jul 2007 7

TACC Member-Integrated CA Portal Services • AUTHENTICATE Identity – Does Id. P know this user based on in-person ID vetting (Lo. A)? • If not in-person, user access to low-risk applications is ok, but no X. 509 credential – Query TACC Accounting System (TAS) DB for User Context • Can check that user answers security question setup at initial registration • Check for active Projects, Allocations, and VO membership and roles • Find user's unique Distinguished Name (CN+issuer) by querying CN list by edu. Person. Principal. Name OR edu. Person. Targeted. ID • Check that Id. M is not re-using edu. Person. Principal. Name by matching email, phone, address • Query VOMRS attribute server to verify user's VO membership and roles • Determine length of short-term certificate – Enable "Get short-term X. 509 cert" button • PROVIDE resulting short-term X. 509 credential when user wants it TAGPMA F 2 F Banff 17 Jul 2007 8

Grid Portal Authentication: Portal Account or Shibboleth Both integrates with TACC TAS database. Either login method authentication methods integrated with underlying TACC TAS database. TAGPMA F 2 F Banff 17 Jul 2007 9

2) UT-System Shibboleth WAYF Dialogue User Selects Identity Provider from Pulldown menu TAGPMA F 2 F Banff 17 Jul 2007 10

3) Authenticate with Home Identity Provider Regular Campus/Id. P login. This one is for UTSystem TAGPMA F 2 F Banff 17 Jul 2007 11

Attributes Returned by UT-System Id. P TAGPMA F 2 F Banff 17 Jul 2007 12

Each Id. P Presents Its Own Dialogue/Look and Feel This is the login dialogue for the UT-Austin Id. P TAGPMA F 2 F Banff 17 Jul 2007 13

Debugging Information Returned by UT-Austin Id. P March 07 June 07 TAGPMA F 2 F Banff 17 Jul 2007 14

UT-System Also Supports the Protect. Network Id. P Protect. Network offers both free Lo. A-1 identity and Validated Lo. A-2 identity for $$. (One option for external, lowrisk application users. ) TAGPMA F 2 F Banff 17 Jul 2007 15

TACC MICS Namespace Accommodates Multiple Id. M/Id. Ps DC = edu; DC = utexas; DC = tacc O = UT-Austin; O=TACC MICS CA O = {Id. M}; OU = {Id. P} CN = {PERSON: firstname initial lastname{seq}} Subject. Alt. Name = {PERSON: email address} Based on feedback received during the meeting, all grid and RA Information - if attached to the X. 509 certificate - will reside in optional extensions. (18 Jul 07) TAGPMA F 2 F Banff 17 Jul 2007 16

TACC CA Structure • Off-line self-signed Root CA generates only subordinate CA CSRs (signed by Root CA). (Open. CA) • Subordinate CA private keys protected by HSM on CA server. (openssl & Safe. Net cryptoki SDK) TACC Root CA (off-line) TACC Subordinate Classic CA (on-line) TACC Subordinate MICS CA (on-line) TAGPMA F 2 F Banff 17 Jul 2007 17

TACC MICS Initial Registration • Portal front-end already has general information about user from UT-System Shibboleth – General Info: cn, edu. Person. Principal. Name, address, email, phone • Need for good contact info is stronger than privacy, but public telephone directory info used where possible • Portlet front-end checks Name (cn) against array of guaranteed unique existing CNs – Results: No match (OK) OR send email to Security Officer "Identity Verification Followup Required!" • CN bound to one and only one individual • CN can be used in both Classic and MICS certificates TAGPMA F 2 F Banff 17 Jul 2007 18

Same Initial Registration Tool for TACC Classic and TACC MICS CAs • Both need CN/DN uniqueness check • Both follow same vetting procedure under control of distributed RA personnel • Both are integrated with the TACC TAS database that supports user management • Only difference: MICS CA can fill in some fields automatically from Id. P attributes. TAGPMA F 2 F Banff 17 Jul 2007 19

Grix by Markus Binsteiner TACC RA Interface Development in Progress • Written in Java • Standalone app • works with GT 4 (except for proxy renewal (gt 4 bug? ) • Talks to VOMRS • Talks to My. Proxy 3. 6 • Markus released source code and can check/assist with mods for TACC CAs TAGPMA F 2 F Banff 17 Jul 2007 20

Vetting by Distributed RAs • Web page lists RA Operators List and contact info. • TACC can offer a web form to document ID and setup security questions & answers • Amenable to f 2 f mtg (in person or by video), phone investigation, notarized documents, etc. until RA is satisfied. TAGPMA F 2 F Banff 17 Jul 2007 21

Sidebar: Grix facilitates Certificate Renewal • APACGrid CA sends reminder email to user one month before certificate expires. • User initiates renewal from Grix • Mostly relevant to long-term certificates, but might consider using it for longrunning jobs. TAGPMA F 2 F Banff 17 Jul 2007 22

Grix 'Get Grid Proxy': User Option 1 TAGPMA F 2 F Banff 17 Jul 2007 23

Grix Get Grid Proxy: User Option 2 TAGPMA F 2 F Banff 17 Jul 2007 24

Grix Destroy Grid Proxy TAGPMA F 2 F Banff 17 Jul 2007 25

Grix Supports My. Proxy http: //grid. ncsa. uiuc. edu/myproxy/fromscratch. html • My. Proxy 3. 8 adds openssl engine support • My. Proxy 4. 0 adds setup and mgmt, (but uses Simple. CA? ). • This will reside on its own front-end server? TAGPMA F 2 F Banff 17 Jul 2007 26

Hardware Security Controls • Safe. Net Protect. Server Gold PCI HSM card – FIPS 140 -2 Level 3 (Certificate 739, 26 Apr 2007) • TACC installed FIPS evaluated firmware and software • Testing using command line tools was successful for multitoken operation in FIPS mode • Application Development underway. • Servers in Secure Rack within controlled access computer room (Logged access limited to Security Officers) • Government-issue fireproof safe also in Secure Rack contains TACC Root CA materials and backups • Server containing HSM is dedicated to CA functions • Server is behind a working hardware firewall TAGPMA F 2 F Banff 17 Jul 2007 27

Dedicated CA Server • Contains tamper-proof PCI HSM • Runs openssl, HSM command line utilities, libcthsm. so, libcryptoki. so, jcprov. jar • TACC applications will handle PKCS#11 – Link with '-L /opt/Eracom/lib' and use FIPS mode – Require authenticated login prior to key access – One token per application • Two slots per token (1 for CA key; 1 for User key) – – Use KMU utility for key backup and restore External keys used with key-encrypting-key Master (CA) key-encrypting-key stored on HSM Working (User) key unwrapped prior to use; destroyed after • My. Proxy repository (on its own front-end server) TAGPMA F 2 F Banff 17 Jul 2007 28

HSM Configuration • Uses FIPS Security Policy ("FIPS-mode") • Slot Design – 1 required 'HSM Admin' slot – 1 User slot for CA key backup to Smart. Card – 3 Labeled User slots with Application PINs • MICS CA; Classic CA; Root CA • Secure memory = 4 MB (~2500 1024 b key-pairs) – Keys only exist in clear in slot on HSM token. – Application can "wrap" encrypt key-pairs for export – MICS key-pairs have a short lifetime (≤ 10. 5 days) TAGPMA F 2 F Banff 17 Jul 2007 29

Software Security Controls • • • OS kept at most current security patch level CA Server timestamps synced with ntpd CA Server runs only minimum OS services CA Server runs shorewall (software firewall) Front-end and Back-end Portlets that talk to CA developed following security best practices – Now have a development portal server and a production portal server (provided by UT-System) – Portal prototype developed using Java 2 (JDK 1. 5), Grid. Sphere 3 and Tomcat 6 TAGPMA F 2 F Banff 17 Jul 2007 30

Event Logging • CA server syslog (timestamped) – System startup & shutdown; Device install and errors; service startup & shutdown • HSM event logs (timestamped in $ET_PTKC_LOGGER_FILE set in /etc/default/et_ptkc) – HSM tamper detect and device errors; Slot operations; SO, Admin and User access; • ssh logs (timestamped in /var/log/secure) • Portal apache and tomcat access and error logs (timestamped) • HW firewall quells Do. S when stateful packet inspection detects that rate of auth attempts is above threshold for an individual user. TAGPMA F 2 F Banff 17 Jul 2007 31

Disaster Recovery Procedures • CA private keys securely exported from HSM to Smart. Card; stored in Government-issue safe • CA server uses private keys and signs CSRs using tamper-proof HSM functions • HSM card is on maintenance with spare shipped overnight • End entity Certificates stored on dedicated CA server in HSM and in SMS protected file. Periodically burned to CDROM; stored in GSA safe • Servers running Red. Hat Linux are on hardware and software maintenance. Security officer logs in and uses OTP to apply vetted patches: – % sudo up 2 date -uv{f} TAGPMA F 2 F Banff 17 Jul 2007 32

For More Information on TACC MICS CA Marg Murray, Ph. D. Research Associate Advanced Computing Systems Texas Advanced Computing Center The University of Texas at Austin marg@tacc. utexas. edu I gratefully acknowledge the contributions of Alan Sill (TTU), Paul Caskey (UT-System) and Markus Binsteiner (VPAC) to this project. J. J. Pickle Research Campus 10100 Burnet Rd. (R 8700) Austin, TX USA 78758 -4497 TAGPMA F 2 F Banff 17 Jul 2007 33