IGTF%20Accreditation%20Review%20of%20MICS%20Authentication%20Profile%20%20(Update)

1
IGTF Accreditation Reviewof MICS Authentication
Profile (Update)

• Marg Murray
• Texas Advanced Computing Center (TACC)
• 30 May 2007

2
1. Intro MICS AP Goals

• Leverage existing IdM infrastructures.
• Generate end entity certificates based on a
  membership or authentication system maintained by
  an organization or federation that last at most 1
  year and 1 month.
• MICS CA maps IdM identity to an X.509 Grid
  certificate identity.
• Define minimum security requirements.

3
2.0 Compliant ArchitectureRequirements

• Provide description of
• Policy Procedures for initial registration
• How IdM is managed and secured
• Connection between IdM and the MICS CA
• Translation from IdM namespace to X.509 namespace
• Protection of chain of trust during translation
  process.
• Demonstrate long-term commitment

4
3. Identity Rules (part 1)

• Any single X.509 DN permanently binds to one and
  only one end entity for the lifetime of the CA
  service.
• Registered subject DN is unique to one registered
  owner.
• RA role and interactions defined by MICS CA
• Initial face-to-face meeting confirms official
  government-issued photo-identification or similar
  documents.
• Identity documents recorded and archived.
• MICS CA CP/CPS must describe how
• Assigned DNs are unique in CA namespace
• Identity is checked
• Assigned DNs are never re-issued
• DN accountability means traceback to physical
  person

5
3. Identity Rules (part 2)

• IdM must
• Encrypt re-usable private information
• Provide contact info for notification of
  certificate issuance
• Provide information to determine whether
  face-to-face identity vetting occurred (likely as
  a LoA)
• IdM may
• Use a 2nd private element (not published and not
  normally used to authenticate)
• If used, the CP/CPS must describe how 'private
  element' maps to identity and how it increases
  identity assurance.
• IdM security mechanisms must be described to PMA.

6
4. Operational Requirements (part 1)

• Dedicated machine in a secure environment
• On-line CA with FIPS 140 device
• Highly protected network accessible from
  Internet
• Tamper-protected log of issued certificates
• MICS CA private key gt 2048 bits
• Encrypted copies kept off-line controlled access
• MICS CA signing lifetime lt 20 years

7
4. Operational Requirements (part 2)

• CP/CPS in RFC 3647 format
• Publish CRLS unless EE certificate lifetime lt 1
  million s (11 days)
• EE certificates
• Must be gt 1024 bits lifetime lt 1year 1month
• X.509v3, RFC3280 compliant
• Section 4.2-4.5 CA EE certificate profile CRL
  profile Host Certificates Revocation CA Key
  Changeover

8
5. Site and IdM System Security

• 5.1 Site CA Security
• 5.2 IdM Security

9
6. Publication and Repository

• http or https URL CA general info web page
• MICS CA root certificate or set of CA
  certificates up to a self-signed root
• http or https URL PEM-formatted CA certificate
• If revocation is supported http URL of PEM or
  DER formatted CRL
• http URL of CP/CPS contact email and postal
  address

10
7. Audits

• MICS CA must record and archive (for at least
  three years)
• CSRs issued certs CRRs login/logout/reboot of
  issuing machine
• MICS CA must accept auditing by other accredited
  Cas
• MICS CA should perform internal operational
  audits of CA/RA staff and IdM interfaces
• MICS CA recommends that IdM system make their
  periodic audits and reviews available to MICS CA
  staff

11
8. Privacy and Confidentiality

• MICS CAs must define and follow a privacy and
  data release policy compliant with their relevant
  national legislation.
• MICS CA is responsible for recording (at the time
  of validation) sufficient information to uniquely
  identify the person getting the certificate.
• The MICS CA is not required to release identity
  information unless presented with a valid legal
  request compliant with relevant laws.

12
9. Compromise and Disaster Recovery

• MICS CA should have a Business Continuity and
  Disaster Recovery Plan
• Doesn't need to be disclosed in CP/CPS
• Must be willing to discuss procedures with PMA

13
10. Due Diligence for Subscribers

• MICS CA should make a reasonable effort to teach
  subscribers how to properly protect their private
  data.
• Long-term X.509 credentials require the user to
  protect his/her private key with a strong pass
  phrase.

14
End of MICS CA Profile Summary

• And now
• Issues
• 2nd authentication element
• Levels of Assurance
• Examples
• NCSA MICS CA
• TACC MICS CA

15
Issue 2nd Identity Element

• Requirements
• High assurance of unique mapping to end entity
• Enhance end entity validation.
• In elevated security mode?
• Examples of what works
• Answers to random questions collected out-of-band
  (e.g., at initial registration)
• Examples of what doesn't work
• Birthday

16
Issue MICS CA and LoA

• IdM Maintains Levels of Assurance (LoA)
• Definitions of different levels are crucial
• Use of a Private Key restricted solely to a
  hardware token enhances LoA.
• Examples???

17
MICS CA Examples

• NCSA MICS CA
• Provisionally accredited for TeraGrid
• Replaces F2F vetting with long-standing NSF
  Allocations Peer Review process
• TACC MICS CA
• Seeking full accreditation for operation within
  Texas applies to more than one grid organization
• 1st recognized IdM UT-System Federation
• 2nd candidate IdM Texas AM University System

18
How Does Shibboleth Work?
I am satisfied with the attributes. Control is
passed to the application.
Your request is forwarded to your Organizations
IdP HS/SSO
11
Identity Provider
User/Web browser
Service Provider
1
Home campus
What is your Organization?
Web application
Authentication System (ISO/SSO/Cert)
3
4
Who are You? Can you login?
Now I know you are someone. I need more
information.
2
Assertion Consumer Service
WAYF (Federation)
What are you asking for and does it require a
shibb session?
5
6
Attribute Requestor
Handle Service/SSO

Resource Manager/Svr Module
I know who you are. Your request and handle is
redirected to SP.
7
What are the attributes for this user?
8
10
Attribute Authority
Web Site
Attributes determined by ARP
9
The allowed attributes are returned to the SP.
LDAP (eduPerson)
19
U.T. System IdM Roadmap
Source https//idm.utsystem.edu/IdentityMgmtpage4
.pdf Color Key Complete Current
Development In-Progress Longer-term Future
20
TACC Member-Integrated CA Portal Services

• AUTHENTICATE Identity
• Does IdP know this user based on in-person ID
  vetting?
• If not in-person, user access to low-risk
  applications is ok, but no X.509 credential
• Request user attributes from IdP.
• If eduPersonEntitlement "PIeligible" attribute is
  asserted, enable "Request Allocation" button
• Query TACC Accounting 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 (CNissuer)
  by querying CN list by eduPersonPrincipalName OR
  eduPersonTargetedID
• Check that IdM is not re-using eduPersonPrincipalN
  ame 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

21
2) UT-System Shibboleth WAYF Dialogue
User Selects Identity Provider from Pull-down menu
22
3) Authenticate withHome Identity Provider
Regular Campus/IdP login. This one is for
UT-System
23
Each IdP Presents Its Own Dialogue/Look and Feel
This is the login dialogue for the UT-Austin IdP
24
UT-System Also Supports the ProtectNetwork IdP
ProtectNetwork offers both free LoA-1 identity
and Validated LoA-2 identity for . (One option
for external, low-risk application users.)
25
TACC MICS Namespace

• DC edu DC utexas DC tacc
• O UT-Austin OUTACC MICS CA
• --------- added if RA not at TACC
• O RA-org OU RA-dept
• O IdM OU IdP
• ---------
• CN PERSON firstname initial lastnameseq
  
• SubjectAltName PERSON email address
• 
  

26
TACC MICS CA DN Uniqueness

• Successful DN registration gt UNIQUE
• Initial registration process checks cn email
  phone eduPersonPrincipalName address
  edupersonTargetedID to prevent duplicates
• Uniqueness is maintained across both TACC MICS
  and TACC Classic CA
• AND
• UT-System eduPersonTargetedID gt UNIQUE
• Campus suffix campus policy enforces
• Alternately, eduPersonPrincipalName email
  phone address can enforce uniqueness
  requirement
• Allows TACC to map each user to a specific DN
  (CNissuer)

27
TACC CA Structure

• Off-line Root CA generates only subordinate CA
  certificates. (OpenCA)
• Subordinate CA private keys protected by HSM on
  CA server. (OpenCA SafeNet SDK)

TACC Root CA (off-line)
TACC Subordinate MICS CA (on-line)
TACC Subordinate Classic CA (on-line)
28
Shibboleth Identity Verification

• User interacts with access protected URL that
  requires creation of a Shibboleth session
• User picks home campus from pull-down menu
• Redirect (WAYF) sent to specific campus IdP
• username/password Success gt Shib session
  handle
• Redirect back to Special URL at TACC (presence of
  handle asserts identity)
• Shib/SAML call between TACC app campus
  Attribute Authority (AA) retrieves from back end
  datastore (LDAP) eduPersonPrincipalName, cn,
  eduPersonTargetedID, LOA, email, phone,
  address, eduPersonEntitlement(PIeligible)
• If LOA lt 2 OR TACC is in elevated security mode
• Ask user 2nd element question (from initial
  registration)
• If user's answer matches
• ACCEPT Identity AND MAP to unique name AND ISSUE
  CSR

29
How Does Shibboleth Work?
I am satisfied with the attributes. Control is
passed to the application.
Your request is forwarded to your Organizations
IdP HS/SSO
11
Identity Provider
User/Web browser
Service Provider
1
Home campus
What is your Organization?
Web application
Authentication System (ISO/SSO/Cert)
3
4
Who are You? Can you login?
Now I know you are someone. I need more
information.
2
Assertion Consumer Service
WAYF (Federation)
What are you asking for and does it require a
shibb session?
5
6
Attribute Requestor
Handle Service/SSO

Resource Manager/Svr Module
I know who you are. Your request and handle is
redirected to SP.
7
What are the attributes for this user?
8
10
Attribute Authority
Web Site
Attributes determined by ARP
9
The allowed attributes are returned to the SP.
LDAP (eduPerson)
30
TACC MICS Initial Registration

• Portal front-end already has general information
  about user from UT-System Shibboleth
• General Info cn, eduPersonPrincipalName,
  eduPersonTargetedName, address, email, phone
• Portlet can contact CA to check Name (cn) against
  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

31
Hardware Security Controls

• SafeNet ProtectServer Gold PCI HSM card
• FIPS 140-2 Level 3 (Stage 5 Finalization
  12Mar07)
• TACC installed FIPS evaluated firmware and
  software
• Testing using command line tools was successful
  for multi-token operation in FIPS mode
• Application Development underway.
• Servers in Secure Rack within controlled access
  computer room (Logged access limited to Security
  Officers)
• GSA fireproof safe also in Secure Rack contains
  TACC Root CA
• Server containing HSM is dedicated to CA
  functions
• Server is behind a (still problematic) hardware
  firewall

32
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 GridSphere 2.2.8
• Upgrading to tomcat 5.5.21 to avoid security flaw
• Considering advantages of using Shibboleth 2.0
  instead of Shibboleth 1.3

33
Event Logging

• CA server syslog (timestamped)
• System startup shutdown Device install and
  errors service startup shutdown
• HSM event logs (timestamped)
• 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 alarms if stateful packet inspection
  detects that rate of auth attempts is above
  threshold for an individual user. (Still
  debugging HW firewall.)

34
Disaster Recovery Procedures

• CA private keys stored off-line in GSA safe
• CA server uses private keys and signs CSRs using
  tamper-proof HSM functions
• HSM card is on maintenance with spare shipped
  overnight
• CA private keys securely exported from HSM to
  SmartCard stored in GSA safe
• End entity Certificates stored on dedicated CA
  server in HSM and is SMS protected file.
  Periodically burned to CDROM stored in GSA safe
• Servers running RedHat Linux are on hardware and
  software maintenance. Security officer logs in
  and uses OTP to apply vetted patches
• sudo up2date -uvf

35
Additional questions or concerns on the MICS
Authentication Profile?

• Marg Murray, Ph.D. Research Associate
• Advanced Computing Systems
• Texas Advanced Computing Center
• The University of Texas at Austin
• marg_at_tacc.utexas.edu

J.J. Pickle Research Campus 10100 Burnet Rd. (R8700) Austin, TX USA 78758-4497