Security concepts - Symmetric/Asymmetric Cryptography - Hash functions - Digital Signature and Digital Certificates - PKI Grid Security - VOMS Authentication/Authorization management - Kerberos - Shibboleth

1. Current standard implementations for security/authorization in distributed computing infrastructures Michele Orrù – VincenzoCiaschini INFN-CNAF For the complete webinar (with sound) please go: http://www.ogfeurope.eu/tutorials.aspx

3. Hash functions

4. Digital Signature and Digital Certificates

7. An entity: an user, a service, or a machine

8. Credentials

9. Some data providing a proof of identity

10. Authentication

11. Verify the identity of the principal

12. Authorization

13. Map an entity to some set of privileges

14. Confidentiality

15. Encrypt the message so that only the recipient can understand it

16. Integrity

17. Ensure that the message has not been altered in the transmission

18. Non-repudiation

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

22. every user has two keys, one private and one public

23. a message encrypted by one key can be decrypted only by the other one

24. it is hard (computationally unfeasible) to derive the private key from the public one

25. Thousand times slower than symmetric one, but if we need to distribute the keys to principals we have just O(n) keys

26. Examples: Diffie-Helmann, RSA

28. given M, it must be easy to calculate H(M) = h

29. given h, it must be difficult to calculate M = H-1(h)‏

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

31. Digital Signature Suppose we have two users, Michele and Vincenzo, that want to communicate respecting principles such as Integrity and Non-repudiation Michele calculates the hash of the message Michele encrypts the hash using his private key: the encrypted hash is the digital signature. Michele sends the signed message to Vincenzo. 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.

32. Digital Signature

33. Digital Signature

39. Online Certificate Status Protocol (OCSP): a service hosted by the CA which verifies the validity of the certificatesCA certificates are self-signed

40. X.509 Certificates

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

43. Michele verifies CA signature in Vincenzo’s certificate;

44. Michele sends to Vincenzo a challenge string;

45. Vincenzo encrypts the hash of the challenge string with his private key;

46. Vincenzo sends encrypted hash challenge to Michele

47. Michele uses Vincenzo’s public key to decrypt the hash.

48. Michele compares the decrypted string with the has of original challenge

50. 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.”

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

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

53. VOMS scenario

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

58. Examples:

59. michele.orru@CNAF.INFN.IT

62. Authentication Server (AS): replies to the initial authentication request from the client, when the user, not yet authenticated, must enter his password.

64. Kerberos operations: AS - AS_req: First user request (kinitcommand) - 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)

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

66. 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)

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

69. kpkcs11: library that exports the PKCS#11 interface.

71. with Mutual Auth, man-in-the-middle attacks are unfeasible

72. 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).

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

77. The trust relationships between each node is ABUSEDAs 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.

78. Kerberos attack techniques Kerberos 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

80. Implementation of an Authentication and Authorization Infrastructure (AAI)

81. Based on Security Assertion Markup Language (SAML)

82. 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)

83. A Shibboleth Federation allows cross-domain Single-sign On (SSO)

84. Service providers don’t need anymore to maintain username and password DBs

89. Auth system

90. User directory

91. Java Authentication and Authorization Service (JAAS)and Java DataBase Connectivity (JDBC) used to interface the existent infrastructure with Shibboleth.

92. Shibboleth: scenario

94. GridSphere

95. GridShib

97. Wordpress

100. Shibboleth Identity -> VOMS Identity