1. CAs, RAs & PMAs CAs, RAs & PMAs Roberto Cecchini INFN CA Manager EUIndiaGrid kick-off Trieste, 19/10/06

2. EUIndiaGrid kick-off, Trieste 2 Symmetric algorithms ● The same key is used to encrypt and decrypt ● fast; ● how to distribute the keys in a secure way? ● number of keys O(n 2 ). AB ciao3$rciao AB 3$rciao3$r

3. EUIndiaGrid kick-off, Trieste 3 Public key Algorithms Each user owns two keys: one private and one public – from the public key is practically impossible to find the private one – messages encrypted using one key can be decrypted only by the other The sender encrypts using the public key of the receiver The receiver decrypts using his private key Keys are O(n) B's keys publicprivate A's keys publicprivate AB ciao3$rciao AB cy7ciao 3$r cy7

4. EUIndiaGrid kick-off, Trieste 4 Digital signature A calculates the message hash and encrypts it using his private key: the encrypted hash is the digital signature B recalculates the hash message and checks the result with the one from A If the two hashes are equal the messages has not been tampered with and A cannot repudiate it. A's keys publicprivate A ciao hash (A) B hash (B) hash (A) = ? ciao

5. EUIndiaGrid kick-off, Trieste 5 Grid Security Infrastructure ● The Grid Security Infrastructure (GSI) is based on public key cryptography and makes use of X.509 certificates:  communications between Grid elements must be “secure”: i.e. authenticated and, possibly, encrypted;  no centralized security system, but instead the harmonization of the different systems of the various organizations;  support for “single sign-on”, i.e. the grid users need to authenticate only once.

6. EUIndiaGrid kick-off, Trieste 6 X.509 certificates ● Contains the following information:  a subject name, which identifies the person or object that the certificate represents;  the public key belonging to the subject.;  the name of a Certification Authority which guaranties that the public key and the identity both belong to the subject;  the digital signature of the CA, as a proof of its guarantee. ● It identifies an entity to a remote computer and vice versa ● It doesn't contain authorization information. ● The problem is: how to be certain that the certificate belongs to the legitimate owner?

7. EUIndiaGrid kick-off, Trieste 7 Mutual authentication ● The GSI uses the Transport Layer Security (TLS) for this mutual authentication protocol.  A sends to B his certificate;  B checks A's certificate: in this way B is sure that the certificate hasn't been tampered with;  B generates a random message and sends it to A;  A encrypts B's message with his private key, and sends the result to B;  B decrypts A's messages with A's public key and if the result is equal to the original random message, he is sure that his correspondent has the private key corresponding to the A's certificate: i.e. he is A;  B sends to A his certificate and the reverse procedure begins;  at the end, A and B have established a connection to each other and are certain that they know each others' identities.

8. EUIndiaGrid kick-off, Trieste 8 Resource access control ● The user proves that he owns the corresponding private key to his certificate. ● The resource must decide if the certificate is trustworthy  list of trusted CAs;  how can be decided if a CA is trustworthy? ● At the moment there are more than 100 “accredited” CAs!  necessary a body which advises on the “quality” of the product.

9. INFN CA

10. EUIndiaGrid kick-off, Trieste 10 INFN CA ● http://security.fi.infn.it/CA/en/ ● Issues certificates to people and servers involved in activities to which the INFN participates ● CA Manager:  Roberto Cecchini INFN, Sezione di Firenze Via G. Sansone 1 50019 Sesto Fiorentino ITALY  e-mail: infn-ca@fi.infn.it  Tel: +39 055 4572113  Fax: +39 055 4572364

11. EUIndiaGrid kick-off, Trieste 11 Address space ● Personal certificates:  /C=IT/O=INFN/OU=Personal Certificate/L= /CN= ● Server certificates:  /C=IT/O=INFN/OU=Host/L= /CN= ● Service certificates:  /C=IT/O=INFN/OU=Service/L= /CN= /

12. EUIndiaGrid kick-off, Trieste 12 Obligations: INFN CA ● INFN CA operates a certification authority service in accordance with all provisions of its Certificate Policy (CP) and associated Certificate Practice Statement (CPS) (http://security.fi.infn.it/CA/CPS/). ● Its obligations include:  to issue certificates based on the requests from entitled subscribers, validated by an appointed Registration Authority;  to notify the subscriber of the certificate issuance;  to publish the issued certificates;  to accept revocation requests according to the procedures outlined in its CP/CPS;  to issue and publish Certificate Revocation Lists (CRLs) with the maximum tempestivity.

13. EUIndiaGrid kick-off, Trieste 13 Obligations: RAs ● INFN CA delegates the tasks of identification and authorization of certificate subjects to Registration Authorities (RA). ● Their obligations include:  to authenticate the entity which makes the certification request;  to verify that requester is entitled to obtain the certificate and that the information provided in the request is correct;  to accept revocation requests;  immediately notify the INFN CA of all the events which require a certificate revocation;  provide information to the subscriber on how to properly maintain a certificate and the corresponding private key;  record and archive all certificate requests, all revocation requests and notifications of certificate issuance.

14. EUIndiaGrid kick-off, Trieste 14 Obligations: subscribers ● Subscribers must:  read and adhere to the procedures published in the CP/CPS;  generate a key pair using a trustworthy method;  take reasonable precautions to prevent any loss, disclosure or unauthorized use of the private key associated with the certificate, in particular, for natural person certificates: ● selecting a suitable passphrase of at least 12 characters ● not storing it in a location accessible from the network (e.g. in an AFS or NFS directory); ● notify immediately INFN CA in case of loss or compromise of the private key. ● Failure to comply to these obligations is sufficient cause for the revocation of the certificate.

15. EUIndiaGrid kick-off, Trieste 15 Obligations: relying parties ● Relying parties must:  understand and accept the CP and associated CPS;  verify the CRL before validating a certificate;  use the certificates only for the allowed purposes.

16. EUIndiaGrid kick-off, Trieste 16 RA: new personal certificate 1.The user meets the RA face-to-face; 2.the RA verifies the user's identity using a valid document; 3.the RA fills the form at https://security.fi.infn.it/cgi- bin/RAvfy.pl with the user information: name, surname and email address; 4.the RA communicates to the user the ID code produced by the on-line authorization process; 5.within 48 hours the user request the certificate, selecting the entry Personal certificate request and filling the form with the same information provided to the RA and the ID code; 6.if everything is correct, the CA will issue the certificate and send to the user the instructions for the download with the same browser used for the request (the RA will be informed).

17. EUIndiaGrid kick-off, Trieste 17 User authorization

18. EUIndiaGrid kick-off, Trieste 18 Personal certificate request

19. EUIndiaGrid kick-off, Trieste 19 RA: personal cert renewal 1.The user, with a valid certificate, selects the entry Personal Certificate Renewal; 2.the RA will receive a notification of the request by e-mail 3.if the request is legitimate, the RA sends a signed reply to the notification within 48 hours; 4.the CA will issue the new certificate after the RA approval and will send a notification to the user and the RA.

20. EUIndiaGrid kick-off, Trieste 20 RA: host certificate 1.The user generates the request using the appropriate template 2.the users sends the request to the competent RA in an e-mail digitally signed by his personal certificate 3.the RA ascertains the right of the user to request the certificate and check the formal validity of the request 4.the RA sends the request to infn-ca@fi.infn.it in a e-mail digitally signed by his certificate 1.one email for each request, specifying in the subject the FQDN of the host 5.the INFN CA sends an e-mail to the address specified in the request asking for a reply (e-mail validity check) 6.when the reply is received, the INFN CA issues the certificate and sends it to the address in the request (the RA is informed).

21. EUIndiaGrid kick-off, Trieste 21 RA: revocation ● Revocation of a certificate:  revocation requests for a personal certificate must be sent to the INFN CA by an e-mail message digitally signed by the owner or, if not possible, by the competent RA.  the message must contain the reason why the revocation is requested and the subject must contain the user's name and the certificate number.  revocation requests for server or service certificates must always be forwarded to the INFN CA by the competent RA under the same rules.

22. EUIndiaGrid kick-off, Trieste 22 Server certificates ● The server name must to be correctly registered (direct and reverse) in the DNS  pay attention to DNS propagation delay! ● To generate a request, use the OpenSSL configuration file available from https://security.fi.infn.it/CA/en/docs/  irregular requests will be rejected  N.B.: the “Structure Name” field must contain the value of the “L” field, as shown in the RA table at https://security.fi.infn.it/CA/en/RA/

23. EUIndiaGrid kick-off, Trieste 23 Request generation ● Generation of a request: an example > openssl req -new -nodes -out req.pem -keyout key.pem -config host.conf Using configuration from host.conf Generating a 1024 bit RSA private key...............................++++++.++++++ writing new private key to 'key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country []:IT Organization []:INFN Certificate type [ ]:Host Structure name (for instance: Pisa) []:Firenze Server FQDN [ ]:postino.fi.infn.it Server manager email address [ ]: roberto.cecchini@fi.infn.it > chmod 600 key.pem ● The certificate will be usually issued within 2 working days (please note, however, that the service is offered on a best effort basis).

24. IGTF & PMAs

25. EUIndiaGrid kick-off, Trieste 25 APGridPMA ● The APGridPMA (http://www.apgridpma.org/) is the international organization to coordinate the trust fabric for e-Science in Asia-Pacific, working in close collaboration -- via the International Grid Trust Federation (IGTF) -- with the other regional peers:  EuGridPMA;  the Americas Grid PMA.

26. EUIndiaGrid kick-off, Trieste 26 Charter ● The PMA is responsible for accreditation of authorities issuing identity assertions for Grid Authentication. The PMA will  define and issue minimum requirements and best practice documents;  maintain and revise these documents according to current developments;  accredit Authorities with respect to the minimum requirements;  accredit Authorities only for those applications that relate to inter-organizational distributed resource sharing in a scientific context.

27. EUIndiaGrid kick-off, Trieste 27 APGrid PMA

28. EUIndiaGrid kick-off, Trieste 28 EUGrid PMA

29. EUIndiaGrid kick-off, Trieste 29 The Americas Grid PMA

30. EUIndiaGrid kick-off, Trieste 30 PMA Structure & Ops ● Membership:  representatives of each Accredited Authority (AA)  representatives of major relaying partners. ● Chair one year renewable. ● At least two meetings per year. ● Activities:  documents  accreditation functions  repository  audit

31. EUIndiaGrid kick-off, Trieste 31 IGTF ● IGTF: http://www.gridpma.org/  Harmonizes and synchronizes member PMAs policies to establish and maintain global trust relationships.  Its constituency are the regional Policy Management Authorities: ● European Grid PMA (EuGridPMA: ~38 CAs); ● Asia Pacific Grid PMA (APGridPMA: 10 CAs); ● The Americas Grid PMA (TAGPMA).  Each PMA is represented by its chair.

32. EUIndiaGrid kick-off, Trieste 32 IGTF Objectives ● The IGTF (like PMAs) doesn't provide identity assertions, instead ensure that the assertions issued by the AA of any of its member PMAs meet or exceed the relevant authentication profile. ● IGTF maintains a set of authentication profiles, assigned for management to a specific PMA:  classic PKI (EuGridPMA);  short-lived credential services (TAGPMA);  member integrated (TAGPMA).

33. EUIndiaGrid kick-off, Trieste 33 IGTF maintained profiles 1/2 ● Classic PKI (EuGridPMA)  long-term credentials to end-entities, who will themselves posses and control their key pair and their activation data.  Hardware Security Modules or Offline operation  two classes of end-entity certificates: ● Hosts and “Grid services” ● Users  strict identity management and verification requirements

34. EUIndiaGrid kick-off, Trieste 34 IGTF maintained profiles 2/2 ● Short-lived credential services (TAGPMA)  automated system to translate the local site identity into a Grid identity: ● end-entity identity validation is based on the local site authentication system. ● Member integrated (TAGPMA)  automated system to issue certificates based on pre-existing identity data maintained by a federation or large organization. ● Experimental (APGridPMA).