Security, Authentication and Authorization Virginia Martín-Rubio Pascual RedIRIS/Red.es Curso Grid y e-Ciencia 2010, Valencia 6- 9 Julio 2010

Introduction Grid Security Infrastructures Security at network level Encryption or Cryptography Symmetric algorithms Asymmetric algorithms: PKI (Public Key Infrastructure) Digital signature Certificates X509 Certificates Security at VO level Proxy certificates Command Line Instructions Virtual Organizations VO concept and authorization Agenda

Principal An entity: a user, a program, or a machine Credentials Some data providing a proof of identity Authentication Verify the identity of a principal Authorization Map an entity to some set of privileges Confidentiality Encrypt the message so that only the recipient can understand it Integrity Ensure that the message has not been altered in the transmission Non-repudiation Impossibility of denying the authenticity of a digital signature Agenda

What is Grid Security? The Grid problem is to enable “coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations” From ”The Anatomy of the Grid” by Ian Foster et al. So Grid Security is security to enable VOs What is needed in terms of security for a VO? Introduction

Virtual Organization Concept(VO) VO for each application, workload or community Carve out and configure resources for a particular use and set of users The more dynamic the better… Introduction

Security issues How can communication endpoints be identified? Authentication How can a secure channel established between two partners? Encryption Non-repudiation Integrity Authorisation Who is allowed to access a Virtual Organisation's resources? What are VO members allowed to do? Introduction User Grid Service

Grid Security Infraestructure  Security at network level Cryptography A cryptographic algorithm is a mathematical function that combines simple text or other intelligible information with a digital character string, called key, for producing unintelligible encrypted text. The used key and algorithm are crucial for encrypting. Simbology: Simple Text: M Encrypted Text: C Encrypted with key K 1 : E K 1 (M) = C Decrypted with key K 2 : D K 2 (C) = M Algorithms: symmetric symmetric: K 1 = K 2 asymmetric asymmetric: K 1 ≠ K 2 K2K2 K1K1 Encryption Decryption MCM

Grid Security Infraestructure  Security at network level Cryptography Symmetric algorithms: Same key for encrypting and decrypting (K 1 = K 2 ) Advantages: Speed Disadvantages: How to distribute the keys? Examples: DES 3DES Rijndael (AES) Blowfish Kerberos MaríaPedro ciao3$rciao MaríaPedro ciao3$rciao3$r

Grid Security Infraestructure  Security at network level Cryptography Asymmetric algorithms: Also named Public Key Algorithms. Same conditions: Every user has two keys: 1 private and 1 public To get private key using public one is impossible. A encrypted message with one of these keys can only be decrypted with the other one. Exchanging the private keys is not necessary. The transmitter encrypts the message using the receiver’s public key. The receiver decrypts the message with his private key. Examples: Diffie-Helmann (1977) RSA (1978) DSA ElGamal Juan keys public private Pablo keys publicprivate PabloJuan ciao3$rciao PabloJuan ciaocy7ciao 3$r cy7

Grid Security Infraestructure  Security at network level Cryptography Digital signature: Cryptographic method that allows us to associate a person or machine identity with a message or document. Assure document or file integrity. How does it work? Pablo calculates a hash of the message. Pablo encrypts that hash using his private key: this encrypted hash is the digital signature. Pablo sends the signed message to Juan. Juan calculates the hash(B) of the message and verifies that it’s the same as hash(A), decrypted with Pablos’ public key. If both hashes are the same: Message wasn’t modified  Integriity. Pablo can’t repudiate it. Juan message digital signature Pablo message digital signature message digital signature Hash(A) Hash(B) Hash(A) = ? Claves de Pablo publicprivate

Grid Security Infraestructure  Security at network level Digital certificates The pablo’s digital signature is considered secure if: Pablos private key hasn’t been compromised. Juan knows the Pablo public key. How Juan is able to make sure that Pablo’s public key is in fact his public key and not other person’s public key? There is a third part that certifies that correspondence between public key and owner identity. Both parts must trust in that third part. There are two models to establish that: X.509  Hierarchical organization (used on Grid). PGP  Peer to peer.

Grid Security Infraestructure  Security at network level Digital certificates Certification Authority The “third part” is named Certification Authority (CA). CA Responsabilities: To issue the digital certificates (contains the public key and the user identity) for users, programs and machines. Verify the user identity and personal information. Registration Authorities (RAs). Revoke the certificate if it has been compromised. Certificate renew when it is going to expire. Periodically publishes a certificate revocation list in its web page: Certificate Revocation Lists (CRL): contains all the revoked certificates.

Grid Security Infraestructure  Security at network level Digital certificates Certification Authority How to obtain a certificate: The certificate is issued by the CA The certificate is used as a key to access the grid A certificate request is performed The user identify is confirmed by the RA

An X.509 Certificate contains: Private key is stored in encrypted file – protected by a passphrase Private key is created by the grid user owner’s public key; identity of the owner; info on the CA; time of validity; Serial number; digital signature of the CA Grid Security Infraestructure  Security at network level Digital certificates X.509 certificates Public key Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba 8968 Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA Expiration date: Aug 26 08:08: GMT Serial number: 625 (0x271) X.509 certificate structure CA Digital signature

Grid Security Infraestructure  Security at network level Digital certificates Secure Socket Layer (SSL) Certificates are signed by the CA’s. Each transaction in the Grid is mutually authentificated: 1.Pedro sends his certificate. 2.Service verifies the signature in Pedro’s certificate. 3.Service sends to Pedro a random number. 4.Pedro encrypts it using his private key. 5.Pedro sends the encrypted number to Service. 6.Service uses Pedro’s public key to decrypt the number. 7.Service compares the decrypted number with the original. 8.If they are equal, Service verifies Pedro’s identity. Pedro PedroService Pedro’s certificate Verifies CA signature Random number Encrypts with his private key Encrypted number Decrypt with public key of Pedro Compares the number with the original

Grid Security Infraestructure  Security at network level Digital certificates Solicitud de Digital certificate Depending on which is your country you must use one CA or another. Spanish users must access to: Other CAs are: (Portugal) (Italy) … There are some users who are in a county without CA, ‘catch-all CAs’ exist for them. For example: EGEE catch-all CA: LCG catch-all CA:

Grid Security Infraestructure  Security at network level Digital certificates Solicitud de Digital certificate a IRISGridCA (1/2) You have to access to and select your correspondent Registration Authority (RA), in the example is RedIRIS. Then you have to select the certificate type: Solicitud de certificate (CSR): CSR de Usuario CSR de Servidor/Servicio Complete the user information.

Grid Security Infraestructure  Security at network level Digital certificates Digital certificate request to IRISGridCA (2/2) The CA sends an to the user notifying him that his certificate is prepared and gives him the URL for downloading it. The user must access to that URL and indicate his identifier for downloading the certificate to his browser (this browser must be the same which user used when request the certificate). After that, the user has to export the certificate from the browser to a pkcs12 file and copies this file to the UI where he is going to submit jobs into the Grid. When the certificate is a PKCS12 file the user has to convert it to.pem files. We can use the openssl command for the conversion (openssl is available in the UI) : openssl pkcs12 –nocerts –in my_cert.p12 –out userkey.pem openssl pkcs12 –clcerts –nokeys –in my_cert.p12 –out usercert.pem

Grid Security Infraestructure  Security at network level Digital certificates Certificate renew (1/2) The certificates maximum lifetime is 1 year + 1 month The idea is that at the end of the year (12 th month) a new certificate is issued Users should be warned about the coming expiration and the need to renew Don’t revoke a certificate to issue a new one unless the certificate has been compromised or the user has ceased his activity which entitles him to have a certificate

Grid Security Infraestructure  Security at network level Digital certificates Certificate renew (2/2) During a renewal it is not required to make the user to pass through the identification procedure: This is a big advantage for both the users and the RA However a maximum renewal number without identification is advisable (for instance: every two years the EE must pass through the identification again) In order not to pass through the identification the renewal request must be signed with the user certificate, examples: signed with user certificate CA/RA Web interface that would identify the user certificate If the user certificate expires before renewal the procedure for a new certificate must be followed

Grid Security Infraestructure  Security at VO level Proxy certificate X.509 It would be dangerous to transfer your certificate through the Grid. Proxy Certificates: Signed by the normal end entity cert (or by another proxy). Support some important features Delegation Have a limited lifetime (minimized risk of “compromised credentials”) Proxy certificates are created by the grid-proxy-init command: grid-proxy-init Enter PEM pass phrase: ****** Options for grid-proxy-init: -hours -bits -help

Grid Security Infraestructure  Security at VO level Proxy certificate X.509 grid-proxy-init User enters pass phrase, which is used to decrypt private key. Private key is used to sign a proxy certificate with its own, new public/private key pair. User’s private key not exposed after proxy has been signed Proxy certificate: the private key of the Proxy is not encrypted stored in local file: must be readable only by the owner lifetime is short (typically 12 h) to minimize security risks. User Certificate File Private Key (Encrypted) Pass Phrase User Proxy certificate file

proxy certificate X.509 grid-proxy-init grid-proxy-init ≡ “login to the Grid” To “logout” you have to destroy your proxy: grid-proxy-destroy To gather information about your proxy: grid-proxy-info Options for printing proxy information: -subject-issuer -type-timeleft -strength-help 23 Grid Security Infraestructure  Security at VO level

24 Proxy certificate X.509 Delegation Delegation = remote creation of a (second level) proxy credential. New key pair generated remotely on server. Client signs proxy cert and returns it. Allows remote process to authenticate on behalf of the user. Remote process “impersonates” the user. Grid Security Infraestructure  Security at VO level

Proxy has limited lifetime (default is 12 h) –Bad idea to have longer proxy However, a grid task might need to use a proxy for a much longer time –Grid jobs in HEP Data Challenges on LCG last up to 2 days MyProxy server: –Allows to create and store a long term proxy certificate: –myproxy-init -s -s: specifies the hostname of the myproxy server –myproxy-info Get information about stored long living proxy –myproxy-get-delegation Get a new proxy from the MyProxy server –myproxy-destroy File transfer services in gLite validates user request and eventually renew proxies –contacting myproxy server 25 Grid Security Infraestructure  Security at VO level Proxy X.509 certificate Long Term Proxy  Myproxy

Grid users MUST belong to virtual organizations Sets of users belonging to a collaboration User must sign the usage guidelines for the VO VOs maintain a list of their members on a LDAP Server The list is downloaded by grid machines to map user certificate subjects to local “pool” accounts "/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461".dteam "/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968".cms "/C=CH/O=CERN/OU=GRID/CN=Patricia Mendez Lorenzo-ALICE".alice... Grid Security Infraestructure  Security at VO level Proxy X.509 certificate VOs y authorization

27 Extend information in the proxies members of the VO, groups, roles. Absolutely compatible with Globus Toolkit. Every VO has a database which contains information about the members of the group, roles and capacities of each user. Users contact with voms server requesting their information of authorization Server sends the information of authorization to the client, who includes it in a proxy certificate. $voms-proxy-init –-voms gilda Creates a certificate and extends it with the voms server information. $ voms-proxy-info –all Shows information of the certificate together with voms extension. Grid Security Infraestructure  Security at VO level Proxy X.509 certificate Servidor VOMS (Virtual Organization Members Service)

Short for Fully Qualified Attribute Name, is what VOMS uses to express membership and other authorization info. Groups membership, roles and capabilities may be expressed in a format that bounds them together: /Role=[ ][/Capability= ] ~]$ voms-proxy-info -fqan /vo.formacion.es-ngi.eu/Role=NULL/Capability=NULL FQAN are included in an Attribute Certificate. Attribute Certificates are used to bind a set of attributes (like membership, roles, authorization info etc) with an identity. ACs are digitally signed. VOMS uses AC to include the attributes of a user in a proxy certificate 28 Grid Security Infraestructure  Security at VO level Proxy X.509 certificate FQAN y AC (Atribute Certificate)

Server creates and signs an AC containing the FQAN requested by the user, if applicable AC is included by the client in a well-defined, non critical, extension assuring compatibility with GT-based mechanism [ui-SL5] /home/virginia > voms-proxy-info -all subject : /DC=es/DC=irisgrid/O=rediris/CN=virginia.martinrubio/CN=proxy issuer : /DC=es/DC=irisgrid/O=rediris/CN=virginia.martinrubio identity : /DC=es/DC=irisgrid/O=rediris/CN=virginia.martinrubio type : proxy strength : 1024 bits path : /tmp/x509up_u500 timeleft : 11:59:55 === VO vo.general.es-ngi.eu extension information === VO : vo.general.es-ngi.eu subject : /DC=es/DC=irisgrid/O=rediris/CN=virginia.martinrubio issuer : /DC=es/DC=irisgrid/O=ifca/CN=host/voms01.ifca.es attribute : /vo.general.es-ngi.eu/Role=NULL/Capability=NULL timeleft : 11:59:55 uri : voms01.ifca.es: Grid Security Infraestructure  Security at VO level Proxy X.509 certificate VOMS y AC (Atribute Certificate)

At resources level, authorization info is extracted from the proxy and processed by LCAS and LCMAPS Local Centre Authorization Service (LCAS) Checks if the user is authorized (currently using the grid-mapfile) Checks if the user is banned at the site Checks if at that time the site accepts jobs Local Credential Mapping Service (LCMAPS) Maps grid credentials to local credentials (eg. UNIX uid/gid, AFS tokens, etc.) Map also VOMS group and roles (full support of FQAN) 30 "/VO=dteam/GROUP=/dteam" dteam "/VO=eumed/GROUP=/eumed/ROLE=SoftwareManager" eumed "/VO=eumed/GROUP=/eumed" eumed Grid Security Infraestructure  Security at VO level proxy certificate X.509 LCAS & LCMAPS

You need a digital certificate and be member of a VO. ¡¡Keep your private key safe!! Proxy commands voms-* To manage proxies Myproxy commands myproxy-* To delegate proxies 31 REMEMBER…

References GridGrid LCG Security: Globus Security Infrastructure: VOMS: CA: BackgroundBackground GGF Security: IETF PKIX charter: PKCS: 32

33 Thanks for your attention! Questions?