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

CAs, RAs & PMAsCAs, RAs & PMAs

Roberto CecchiniINFN CA Manager

EUIndiaGrid kick-offTrieste, 19/10/06

EUIndiaGrid kick-off, Trieste 2October, 19 2006

Symmetric algorithmsSymmetric algorithms

● The same key is used to encrypt and decrypt● fast;● how to distribute the

keys in a secure way?● number of keys O(n2).

A B

ciao 3$r ciao

A B

ciao 3$r ciao3$r

3$r


Public key AlgorithmsPublic 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

public private

A's keys

public private

A B

ciao 3$r ciao

A B

ciao cy7 ciao

3$r

cy7


Digital signatureDigital 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

public private

A

ciao ciao

hash (A)

B

hash (B)

hash (A)

= ?

ciao


Grid Security InfrastructureGrid 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.


X.509 certificatesX.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?


Mutual authenticationMutual 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.


Resource access controlResource 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.

INFN CAINFN CA


INFN CAINFN 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 CecchiniINFN, Sezione di FirenzeVia G. Sansone 150019 Sesto FiorentinoITALY

e-mail: [email protected] Tel: +39 055 4572113 Fax: +39 055 4572364


Address spaceAddress space

● Personal certificates: /C=IT/O=INFN/OU=Personal Certificate/L=<RA

name>/CN=<name and surname>● Server certificates:

/C=IT/O=INFN/OU=Host/L=<RA name>/CN=<server FQDN>

● Service certificates: /C=IT/O=INFN/OU=Service/L=<RA

name>/CN=<service name> /<server FQDN>


Obligations: INFN CAObligations: 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.


Obligations: RAsObligations: 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.


Obligations: subscribersObligations: 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.


Obligations: relying parties 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.


RA: new personal certificateRA: 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).


User authorizationUser authorization


Personal certificate requestPersonal certificate request


RA: personal cert renewalRA: 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-mail3. 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.


RA: host certificateRA: 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 [email protected] in a e-mail digitally signed by his certificate1.one email for each request, specifying in the subject

the FQDN of the host5. 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).


RA: revocationRA: 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.


Server certificatesServer 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/


Request generationRequest generation

● Generation of a request: an example> openssl req -new -nodes -out req.pem -keyout key.pem -config host.confUsing configuration from host.confGenerating 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 []:ITOrganization []:INFNCertificate type [ ]:HostStructure name (for instance: Pisa) []:FirenzeServer FQDN [ ]:postino.fi.infn.itServer manager email address [ ]: [email protected]> 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).

IGTF & PMAsIGTF & PMAs


APGridPMAAPGridPMA

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


CharterCharter

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


APGrid PMAAPGrid PMA


EUGrid PMAEUGrid PMA


The Americas Grid PMAThe Americas Grid PMA


PMA Structure & OpsPMA 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


IGTFIGTF

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


IGTF ObjectivesIGTF 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).


IGTF maintained profiles IGTF maintained profiles 1/21/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


IGTF maintained profiles IGTF maintained profiles 2/22/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).

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

Documents

private key keys

b hash b hash

public key algorithms

b b decrypts

public key cryptography

corresponding private

certificate b checks

digital signature b