Current standard implementations for security/authorization in distributed

computing infrastructuresMichele Orrù – Vincenzo Ciaschini

INFN-CNAFFor the complete webinar (with sound) please go:

http://www.ogfeurope.eu/tutorials.aspx

Outline• Security concepts

o Symmetric/Asymmetric Cryptographyo Hash functionso Digital Signature and Digital Certificateso PKI

• Grid Securityo VOMS

• Authentication/Authorization managemento Kerberoso Shibboleth

Glossary• Principal

o An entity: an user, a service, or a machine• Credentials

o Some data providing a proof of identity• Authentication

o Verify the identity of the principal• Authorization

o Map an entity to some set of privileges• Confidentiality

o Encrypt the message so that only the recipient can understand it• Integrity

o Ensure that the message has not been altered in the transmission• Non-repudiation

o Impossibility of denying the authenticity of a digital signature

Symmetric/Asymmetric Cryptography

• Cryptography is a mathematical algorithm that provides important building blocks for the implementation of a security infrastructure

• Which key is used for encryption and decryption is the discriminator for symmetric/asymmetric cryptography

• Symmetric Cryptography: o K1 = K2, the same key is used to encrypt the plain text and decrypt the

cyphertexto Really fast, but if we need to distribute the keys to principals we have O(n2)

keyso Examples: DES, AES, Serpent, Twofish, Blowfish

Symmetric/Asymmetric Cryptography

• Asymmetric Cryptography: o K1 ≠ K2, the keys to encrypt/decrypt are differento every user has two keys, one private and one publico a message encrypted by one key can be decrypted only by the other oneo it is hard (computationally unfeasible) to derive the private key from the public

oneo Thousand times slower than symmetric one, but if we need to distribute the

keys to principals we have just O(n) keyso Examples: Diffie-Helmann, RSAo Curiosity: Kasperky Lab is working on factoring the 1024 bit RSA key used by

the Gpcode virus. According to Bruce Schneier “it's likely to require a lot more than 15 million computer years of work"

One-Way Hash Functions

• Functions (H) that, given as input a variable-length message (M), produce as output a string of fixed length (h)

o the length of h must be at least 128 bits (to avoid birthday attacks)o given M, it must be easy to calculate H(M) = ho given h, it must be difficult to calculate M = H-1(h)o given M, it must be difficult to find M’ such that H(M) = H(M’)

• A birthday attack is a name used to refer to a class of brute-force attacks. It gets its name from the surprising result that the probability that two or more people in a group of 23 share the same birthday is greater that 50%: such a result is called a birthday paradox.

• From many years Philippe Oechslin published a famous paper named “Making a Faster Cryptanalytic Time-Memory Trade-Off”: RainbowCrack is a general propose implementation of this paper. It can find collisions on MD5,SHA1, LM, NTLM hashes.

Digital Signature

• Suppose we have two users, Michele and Vincenzo, that want to communicate respecting principles such as Integrity and Non-repudiation

1. Michele calculates the hash of the message2. Michele encrypts the hash using his private key: the encrypted hash is the digital

signature.3. Michele sends the signed message to Vincenzo. 4. Vincenzo calculates the hash of the message and verifies it with the one received

by Michele and decyphered with Michele’s public key.

• If hashes equal: message wasn’t modified. Michele cannot repudiate it.

Digital Signature

Digital Signature

Digital Certificates

• Michele’s digital signature is safe if:o Michele’s private key is not compromisedo Vincenzo knows Michele’s public key

• How can Vincenzo be sure that Michele’s public key is really Michele’s public key and not someone else’s?o A third party guarantees the correspondence between public key and owner’s

identityo Both Michele and Vincenzo must trust this third party

• Two models:o PGP: “web of trust”;o X.509: hierarchical organization.

PGP “web of trust”

A

B

C

D

E

F

•F knows D and E, who knows A and C, who knows A and B.•F is reasonably sure that the key from A is really from A.

X.509 Certificates

• The “third party” is called Certification Authority (CA).

• Issues Digital Certificates for users, programs and machines

• Check the identity and the personal data of the requestoro Registration Authorities (RAs) do the actual validation

• CA’s periodically publish a list of certificates compromised or no longer valid o Certificate Revocation Lists (CRL): contain all the revoked certificates yet to

expireo Online Certificate Status Protocol (OCSP): a service hosted by the CA which

verifies the validity of the certificates

• CA certificates are self-signed

X.509 Certificates

Which CA can you trust in Grid?

• EUGridPMA (http://www.eugridpma.org/)

• “The EUGridPMA is the international organization to coordinate the trust fabric for e-Science grid authentication in Europe. It collaborates with the regional peers APGridPMA for the Asia-Pacific and The Americas Grid PMA in the International Grid Trust Federation. The charter document defines the group's objective, scope and operation. It is the basis for the guidelines documents on the accreditation procedure, the Authentication profile for X.509 secured "classic" certification authorities and other IGTF recognised Profiles".

• RPMs and DEB metapackages are available for almost every Linux distribution

The Grid Security Infrastructure (GSI)

• Every Grid transaction is mutually authenticated:o Vincenzo sends his certificate;o Michele verifies CA signature in Vincenzo’s

certificate;o Michele sends to Vincenzo a challenge string;o Vincenzo encrypts the hash of the challenge string

with his private key;o Vincenzo sends encrypted hash challenge to

Micheleo Michele uses Vincenzo’s public key to decrypt the

hash.o Michele compares the decrypted string with the has

of original challengeo If they match, Michele verified Vincenzo’s identity

and Vincenzo can not repudiate it.

Based on X.509 PKI:

Security issues

• When a malicious attacker manages to have Vincenzo private key, can lead to Michele impersonation.

• Private keys must be stored in safe places and in encrypted form (armored, in the PGP dialect)

• In real-world cases most of the time Non-repudiation is not working, because private keys are not stored in protected places. If Vincenzo want to affirm that he didn’t sign the message to Michele, he can just say that a virus infected his machine stealing the private key.

X.509 Proxy Certificate

• On the Grid the user does not use his own long living certificate: security problems may arise.

• The solution is to use an X.509 Proxy Certificate (GSI extension to X.509 Identity Certificates).

• According to RFC 3820: “Use of a proxy credential is a common technique used in security systems to allow entity A to grant to another entity B the right for B to be authorized with others as if it were A. In other words, entity B is acting as a proxy on behalf of entity A.”

X.509 Proxy Certificate

• Has a limited lifetime• Is signed by the normal end entity certificate or by another proxy• Delegation = remote creation of a (second level) proxy credential

• Allows remote process to authenticate on behalf of the user

Virtual Organizations and VOMS

• To submit to the Grid, personal certificates are not the end of the story. Users MUST join at least one of the groups allowed to use the

Grid resources = Virtual Organization (VO)

• VOMS (Virtual Organization Membership Service) extends the proxy info with VO membership, group and role.

VOMS scenario

Groups and Roles in VOMS

• Every user in a VO belongs to at least one group:o E.g: /infngrid

• And may also belong to some subgroups:o E.g: /infngrid/g1, /infngrid/g2, meaning subgroups g1 and g2 of /infngrid

• There are also Roles:o E.g: /Role=VO-Admin

• Roles make sense only in the contest of a group:o E.g: /Role=VO-Admin in the group /infngrid.

• Compact way of describing it: (FQAN)o /infngrid/Role=VO-Admin

o Holding the role of VO-Admin in the group /infngrid

Kerberos

• Kerberos is an authentication protocol for trusted hosts on untrusted networks.

• Kerberos does not provide any guarantees if the machines or services being used are vulnerable.

• Kerberos' strategies are useless if a malicious attacker compromises the server, stealing the secret key. Indeed, the intruder will put this key on another machine, and spoofing the DNS name or IP address for that server he can impersonate it.

Kerberos aims

• The user's password must never travel over the network; • The user's password must never be stored in any form on the client machine; • The user's password should always be encrypted in the authentication server

database; • The user is asked to enter a password only once per work session. Therefore users

can transparently access all the services they are authorized for. This characteristic is known as Single Sign-On;

• Not only do the client have to prove that he is who he says, but, when requested, the application server must prove its authenticity to the client as well. This characteristic is known as Mutual authentication;

• Following the authentication and authorization phases, the client and server must be able to encrypt the connection. Kerberos provides support for the generation and exchange of an encryption key K'A to be used to encrypt data.

Kerberos glossary

• Realm: states for an authentication administrative domaino a user/service belongs to a realm if and only if he/it shares a secret (password

or key) with the authentication server of that realm

• Principal: is the name used to refer to the entries in the authentication server database.o A principal is always associated with a user, host or service of a given realm.o Examples:

o michele.orru@CNAF.INFN.ITo pop3/mail.cnaf.infn.it@CNAF.INFN.IT

• Ticket: is something a client presents to an application server to demonstrate its identityo Each ticket always has an expiration time (usually hours): the realm admin

cannot prevent users from using the tickets they already possess.

Kerberos glossary

• Key Distribution Center (KDC): the authentication server, based on its ticket distribution function for access to the services.

• Even if it resides entirely on a single physical server, in can be logically divided in:o Database: contains the entries associated with users/hosts/services, and

informations about the tickets.o Authentication Server (AS): replies to the initial authentication request from

the client, when the user, not yet authenticated, must enter his password. o Ticket Granting Server (TGS): can be considered as an application server (given

that to access it it is necessary to present the TGT – ticket-granting ticket) which provides the issuing of service tickets as a service

Kerberos operations

Kerberos operations: AS

- AS_req: First user request (kinit command) - AS_rep: it contains the TGT ticket (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user)

Kerberos operations: TGS

- TGS_req: includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key - TGS_rep: the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted

Kerberos operations: AP

- AP_req: the service ticket (from TGS) with the previous reply and an authenticator generated by the client, but encrypted using the service session key - AP_rep: the reply that the application server gives to the client to prove it really is the server the client is expecting (only on Mutual Auth)

Kerberos Leveraged PKI

• Kerberos Leveraged PKI (K-PKI) leverages an existing Kerberos infrastructure to provide a lightweight Public Key Infrastructure (PKI).

• kx509 and KCA are part of the National Science Foundation Middleware Initiative (NMI) EDIT software release.

• Components:o KCA: Kerberized server that generates the certificateso kx509: standalone client that acquires a short-term X.509 certificate from the

KCA and stores it in the local user;s Kerberos ticket file. The certificate can be used by PKI-aware applications trough the kpkcs11 library

o kpkcs11: library that exports the PKCS#11 interface. o KCT: runs next to the KDC, accepting user certificates via SSL from a special

Apache module (mod_KCT) and returns a Kerberos service ticket.

Kerberos attack techniques

• KDC spoofing

o attack which relies basically on the ability to spoof KDC replieso with Mutual Auth, man-in-the-middle attacks are unfeasibleo BUT some authentication layers such as PAM on Unix systems, does not use

the whole Kerberos auth process by default: they use a shortcut of the first step (see Kerberos operations: AS), trying to decrypt the AS_REP using the password provided by the user, completely ignoring the ticket-granting ticket (TGT).

o Demonstration code written by Dug Song (the developer of the infamous DSNIFF tool suite) can be download here: http://www.monkey.org/~dugsong/kdcspoof.tar.gz

Kerberos attack techniques

• Replay attack

o attack where a previously sniffed AP_REQ is reused in order to impersonate the victim against the accessed service

o the replay attack requires the ability to listen on the network as well as the ability to send fake packets

o Timestamps, address-full tickets (containing the IP address), replay cache make this attack almost impossible

• BUT the two described attacks can be combinedo KDC spoofing to generate AS_REP responseso Replay attack to reply TGS_REP responses, instead of AP_REP

Kerberos attack techniques• Kerberos Hijacking

o process of capturing a user’s ticket and using it to access resources that trust the user: this means “logging in the machines that accept the user’s Kerberos ticket”

o The trust relationships between each node is ABUSED

• As we have discussed before, “Kerberos does not provide any guarantees if the machines or services being used are vulnerable”.

• Hijacking Kerberos tickets always starts compromising a kerberized system, and gaining root access to it.

Kerberos attack techniquesKerberos Hijacking: practical demonstration

# ls -al /tmp/krb* -rw------- 1 vincenzo eng 383 Aug 28 08:19 /tmp/krb6bb_89763_AX98k3 <-- FREE ACCESS! # klist Ticket cache: FILE:/tmp/krb6bb_6425 <-- expected filename Default principal: michele@target Valid starting Expires Service principal 08/28/09 12:14:50 08/28/09 22:14:50 krbtgt/target@target renew until 09/05/07 12:14:39

Let change the file to the expected name run klist:

# cp /tmp/krb6bb_89763_AX98k3 /tmp/krb6bb_6425 # klist Ticket cache: FILE:/tmp/krb6bb_6425 Default principal: vincenzo@target <---we are now Vincenzo! Valid starting Expires Service principal 08/28/07 08:19:42 08/28/07 18:19:42 krbtgt/target@target renew until 09/05/07 08:19:42

Shibboleth

• Shibboleth is an Internet2 Middleware Open Source project• Implementation of an Authentication and Authorization Infrastructure (AAI)

• Based on Security Assertion Markup Language (SAML)o SAML is an OASIS XML-based standard for exchanging A&A data between

security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions)

• A Shibboleth Federation allows cross-domain Single-sign On (SSO) o Service providers don’t need anymore to maintain username and password

DBs

• Originally developed for Web browser-based services, Shibboleth is currently being extended to support services that use other interfaces, such as SOAP Web services.

Shibboleth: Federated Identity

• Federated Identity management is a key concept in AAI scenarios

• Sharing information outside your administrative domain: in this situation active protection of user information is vital

• User aspects that must be protected:

o User’s identifier: the application doesn’t necessarily need to know who the user is

o User’s identity: give the application only what is absolutely needed.

Authentication and Authorization Infrastructure

• Without AAI:o authentication/authorization between different applications of multiple

domains always become a tedious processo inter-institutional access can become really expensive to implement

• With AAI:o we can obtain efficient implementation of inter-institutional accesso we fully leverage on an authorization layer that is independent from the

location

Shibboleth: Home organization

•Pre-existent:o Auth systemo User directory

•Java Authentication and Authorization Service (JAAS)and Java DataBase Connectivity (JDBC) used to interfacethe existent infrastructure with Shibboleth.

Shibboleth: scenario

Already shibbolized apps

• Grid applications:o Condoro GridSphereo GridShibo MyProxy

• Open Source CMSs:o Drupalo Wordpresso Zope/Plone

• Others:o Google Apps/Gmailo Microsoft Sharepoint

VASH

• Interoperability of AAI and Grid• VO information + IdP information

o more granular authorization decisions

• VASH = VOMS Attributes from Shibboletho consolidates IdP and VO user data on the VOMSo Shibboleth Identity -> VOMS Identityo provides administration facilities

Thanks for you attention.