1 / 38

Setting up and Managing National CA for GRID Computing

H I A S T Setting up and Managing National CA for GRID Computing Ghassan SABA, HIAST Regional Seminar on Identity Management and E-signatures Damascus, 29-31 October 2007 Outline What are Grids? Security in the GRID GRID Certificates HIAST Plan to be the Syria’s CA for GRID computing

adamdaniel
Download Presentation

Setting up and Managing National CA for GRID Computing

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. H I A S T Setting up and Managing National CAfor GRID Computing Ghassan SABA, HIAST Regional Seminar on Identity Management and E-signatures Damascus, 29-31 October 2007

  2. Outline • What are Grids? • Security in the GRID • GRID Certificates • HIAST Plan to be the Syria’s CA for GRID computing • CP/CPS preparation • CA design issues Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  3. What are Grids? • Set of services over the Internet, allowing geographically dispersed users to share: • computer power • data storage capacity • remote instrumentation • Grid Computing is a particular example of distributed computing based on the idea to share resources on a global scale Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  4. What Grid is About:Aggregation in Virtual Organizations Distributed resources and people Linked by networks, crossing administrative domains Sharing resources, common goals Dynamic behaviors Fault-tolerant R R R R R R R R R R R R R R VO-A VO-B Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  5. What is VO • Virtual organizations (VOs) are collections of diverse and distributed individuals that seek to share and use diverse resources in a coordinated fashion • Users can join into several VOs, while resource providers also partition their resources to several VOs. Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  6. Requirements for Grid computing • An Authentication and Authorization system, providing secure access to resources: • secure communication, secure data, resources etc. • security across organisational boundaries • single sign-on for users of the Grid • A mechanism (middleware) for managing and allocating resources to users and applications • A reliable, high-performance network connection amongst resources Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  7. Needs for new security standard • Several security standards exist: • Public Key Infrastructure (PKI) • Secure Socket Layer (SSL) • Kerberos • Need for a common security standard for Grid services • Above standards do not meet all Grid requirements (e.g. delegation, single sign-on etc.) • Grid community mainly uses X.509 PKI for the Internet • Well established and widely used (also for www, e-mail, etc.) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  8. Why Grid Security is Hard? • Dynamic formation and management of virtual organizations (VOs) • VO Resources and users are often located in distinct administrative domains • Interactions are not just client/server, but service-to-service on behalf of the user: • Requires delegation of rights by user to service • Services may be dynamically instantiated • Policy from sites, VO, users need to be combined • Varying formats • Want to hide as much as possible from applications! slide based on presentation given by Carl Kesselman at GGF Summer School 2004 Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  9. The Grid Trust solution • Instead of setting up trust relationships at the organizational level, set up trust at the user/resource level • Grid users must belong to a Virtual Organization • Sets of users belonging to a collaboration • Each VO user has the same access privileges to Grid resources • VOs maintain a list of their members • The list is downloaded by Grid machines to map user certificate subjects to local “pool” accounts • Sites decide which VOs to accept • Users are able to set up dynamic trust domains • Personal collection of resources working together based on trust of user Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  10. ComputeCenter Service Rights VO ComputeCenter Use Delegation toEstablish Dynamic Distributed System Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  11. Proxy • Consists of a new certificate with new public, private keys, and owner’s identify (/CN=proxy added to name) • Certificate signed by owner (not CA) • Proxy given limited lifetimes • Proxy’s private key does not need to be kept as secure as owner’s private key - setting file permissions usually sufficient Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  12. Proxy Certificates Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  13. Grid Security Infrastructure (GSI) • de facto standard for Grid middleware • Based on PKI • Implements some important features • Single sign-on: no need to give one’s password every time • Delegation: a service can act on behalf of a person • Mutual authentication: both sides must authenticate to the other • Introduces proxy certificates • Short-lived certificates including their private key and signed with the user’s certificate • Proxies provide “single sign-on”: • Enable user and it’s agents to acquire additional resources without repeated authentication (passwords) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  14. GSI General Overview Proxies and delegation (GSI Extensions) for secure single Sign-on Proxies and Delegation SSL/ TLS PKI (CAs and Certificates) SSL for Authentication and message protection PKI for credentials Based on Slide from Globus Tutorial Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  15. Structure of a X.509 certificate Public key Subject:C=CH, O=CERN, OU=GRID, CN=John Smith 8968 Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA Expiration date: Aug 26 08:08:14 2005 GMT Serial number: 625 (0x271) CA Digital signature X.509 certificates and authentication B A A A’s certificate Verify CA signature Random phrase Encrypt with A’ s private key Encrypted phrase Decrypt with A’ s public key Compare with original phrase Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  16. Grid Certificates (X.509) • X.509 is ITU Standard: • ITU-T Recommendation X.509 (1997 E). Information technology - Open Systems Interconnection - The Directory: Authentication Framework • Defines a certificate format (originally based on X.500 Directory Access Protocol) • Latest standard: X.509 version 3 certificate format • X.509 certificate includes: • User identification (someone’s subject name) • Public key • A “signature” from a Certificate Authority (CA) that: • Proves that the certificate came from the CA. • Vouches for the subject name • Vouches for the binding of the public key to the subject Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  17. CA Involved entities Certificate Authority User Public key Private key certificate Resource (site offering services) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  18. Name: CA Issuer: CA CA’s Public Key CA’s Signature Certificate Authorities • Issue certificates for users, programs and machines • Check the identity and the personal data of the requestor • Registration Authorities (RAs) do the actual validation • Manage Certificate Revocation Lists (CRLs) • They contain all the revoked certificates yet to expire • CA certificates are self-signed Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  19. Cert Independent Scotland ID Certificate Request User generatespublic/privatekey pair. User send public key to CA along with proof of identity. CA confirms identity, signs certificate and sends back to user. CertificateRequest Public Key Public Certificate Authority Private Key encrypted on local disk slide based on presentation given by Carl Kesselman at GGF Summer School 2004 Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  20. Authorisation Requirements • Detailed user rights assigned: • User can have certain group membership and roles • Involved parties: • Resource providers. • Keep full control on access rights. • The users Virtual Organisation. • Member of a certain group should have same access rights independent of resource. • Resource provider and VO must agree on authorisation: • Resource providers evaluate authorisation granted by VO to a user and map into local credentials to access resources Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  21. HIAST Plan to be the Syria’s CAfor GRID computing • HIAST was nominated to be the Registration Authority (RA) for GRID computing community in Syria in 2006 • We are now working on the following points: • Studying how to meet all EUGRIDPMA requirements until acceptance • Subscribing to EUGRIDPMA mailing list • Evaluating and checking the CP/CPS documents published by other CA’s • Writing a draft document of HIAST’s CP/CPS • Evaluating the options to begin acquisition and subsequent installation of necessary hardware and software • Developing a secure website to be the interface for certificate requests and to help users find all information regarding CA, CRL, CP/CPS documents and contact information • Interacting with EUGRIDPMA to review all the above steps in details • Setting up the CA and making it operational • Getting the accreditation and announcing the service Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  22. The main points which will be coveredthrough the CP/CPS Document • CP (Certificate Policy): is to establish WHAT participants must do • CPS (Certification Practice Statement): is to disclose HOW the participants perform their functions and implement control 1. CA Role: • Issuing certificates and CRLs • Publishing the issued certificate and CRLs • Managing all the hardware and software Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  23. The main points which will be coveredthrough the CP/CPS Document 2. RA Role: • Authenticating the user which makes the request • Verifying the information provided by the user • Notifying the CA all the requests 3. Request Types: • Certificate request • Renewal request. • Revocation request 4. Certificate Types: • Personal certificate • Server/Host certificate • Service certificate Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  24. 5. The Procedure in details will include: • How to design secure certificate request (new, renewal and revocation) • How to validate the identities of certificate requests. • Way of authentication • Communication between the CA and RA 6. The required CA Equipment : • Dedicated computer system not connected to network • Software needed (OpenCA) 7. Physical control and security Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  25. Role of Certification Authority • Verifies certificate request information • Generates and digitally signs the certificate • Revokes certificate if information changes • Revokes certificate if private key is disclosed • Support certificate hierarchies Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  26. Certificate Policy (CP) • Who is responsible for the RA/CA operation? • What is the community served? • What are the rules for identifying Subjects? • What’s in a certificate? • What constraints are there on operation of the CA? • What must be done if something goes wrong? Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  27. CA Design issues • Main points to cover in design: • Structure of CA: online or offline? • Structure of RAs network • CA/RA responsibilities • Identity validation process for new certificate requests • Secure communication of RAs and CA • Properties of CA, user, host and service certificates and private keys (Refer to RFC 3280 for certificate profile): • Certificate extensions • Passphrase for private keys Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  28. CA Design issues (2) • Main points to cover in design (cont'd): • Structure your CP/CPS as defined in RFC 3647 • Define revocation situations and CRL (Certificate Revocation List) life time (Refer to RFC 3280 for CRL profile) • Describe clearly certificate request handling • Security of dedicated CA (physical security, how to keep private key and passphrase for root CA cert) • Web repository, what to publish on CA website • Specify necessary records and archives • Define a CA disaster recovery plan Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  29. CP/CPS Preparation 1. Make a request for an OID arc • Every CP/CPS version of every CA must have a unique object identifier. Your organization, that is responsible to operate the CA must have a valid OID arc. There are two alternatives to have it: • You can apply to IANA for an OID arc. (http://www.iana.org/cgi-bin/enterprise.pl)it takes almost two months! HIAST OID is : 1.3.6.1.4.1.27601 2.You can apply to IGTF for an OID arc. (http://www.eugridpma.org/objectid/) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  30. Establish your CA website • CA web repository must include: • General info about your CA (homepage) • CA root certificate • CRL URL • CP/CPS – policy document • official contact email address, responsible for CA • physical postal contact address • ssl protected web form for certificate requests (either via OpenCA or your own scripts) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  31. Operational Requirements • CA must protect its private key appropriately • Must not generate key pairs for Subjects • Certificate management • Revocation required at Basic or higher LOA • Requires standard CRL; allows for OCSP • Relying Party required to check for revocation • Suspension not used • Security Audit Procedure • Everything that might affect the CA or RA Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  32. Physical, Procedural and Personnel Security Controls • CA Roles • Administrator - sysadmin; installs & configures • Officer - approves issuance and revocation of PKCs (Public Key certificates) • Operator - routine system operation & backup • Auditor - reviews syslogs; oversees external audit • Separation of roles required • at least 2 people (Admin./Op. & Officer/Auditor) • at least 3 at higher LOAs • Some tasks require action by 2 out of 4 persons Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  33. Installation of CA • X.509 standard, public key infrastructure (PKI) used in Grid Certification Authorities • OpenSSL is the preferred tool for X.509 operations including creating and signing certificate requests, CRLs, revoking certificates, renewing certificates. • See main openssl commands on page http://www.openssl.org/docs/apps/openssl.html • You have two main alternatives to set up your CA: • Write your own scripts • Install and run OpenCA Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  34. Install and run OpenCA • You can download and install free software OpenCA for your CA/RA operations including online certificate requests: • http://www.openca.org/ • It uses OpenLDAP, OpenSSL, Apache facilities. • It is suitable for a large scale CA. Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  35. Maintenance of CA • Below are the most important issues to follow for a successful operation: • Prepare the environment for dedicated offline CA machine. • Maintain CA protection at best efforts. (Smart card, security personnel, safes...) • Train your RA personnel. • Always keep secure communication between RAs and CA. • Keep your RA staff as distributed as possible. (local RAs for identity validation) Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  36. Maintenance of CA (2) • Most important issues for CA maintenance: • Give importance to identity validation. (face-to-face meeting, checking from an ID card) • Show immediate reaction to revocation circumstances. • Be on time for periodical CRL issuing and publishing. • Know OpenSSL commands well. • Make sure you have the accurate records as you have stated in your CP/CPS. Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  37. Acknowledgements • Some slides of this presentation are taken or inspired from the following presentations and/or web sites: • Carl Kesselman, GRID Security Overview, GGF Summer School 2004 • Asli Zengin, Rome, Tutorial for Certification Authority Managers, 12.09.2006 • Heinz Stockinger, Grid Security, EMBRACE Grid Tutorial, Helsinki, 16 June 2006 • Globus Web site, www.globus.org Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

  38. Thank you For your Attention Damascus, Regional Seminar on Identity Management and E-signatures, 29-31 October 2007

More Related