Security Protocols Sathish Vadhiyar Sources / Credits: Kerberos web pages and documents contained / pointed thereinhttp://web.mit.edu/kerberos/www/dialogue.html

Kerberos Provides authentication and encryption Services and clients in an open networked environment One method is for the service to ask for password, i.e. the server needs to know the password of the user – not scalable Another method – clients have their passwords, services have their passwords, centralized service called authentication service knows both passwords

Kerberos architecture A User: Iam serc1. I want to access A. serc1 password Authentication service: 1.serc1 is in my database 2.Password matches. 3.ticket_A = {user} k_server_A 4.send ticket_A to serc1 User -> A: 1.Send {user, ticket_A} A: 1.name1 = Decrypt ticket_A using k_server_A 2.If name1 == user grant access

Comments How can a server verify that it has decrypted the ticket correctly? – solution: What happens if the ticket is stolen by someone over the network? - solution: But still some more problems: Ticket = { user, service } k_server Ticket = {user, service, host} k_server 1.Users enter passwords each time they need a ticket to a service 2.Passwords can be stolen Solutions: kinit, TGS, TGT

Modified Kerberos architecture A User / kinit: 1.Iam serc1. I need a TGT. Authentication service / TGS 1.serc1 is in my database 2.TGT = {user, TGS, host} k_TGS, k_user 3.send TGT to serc1 User -> A: 1.Send {user,host, ticket_A} A: 1.Name1, service1, host1 = Decrypt ticket_A using k_server_A 2.If name1 == user && service1 == A && host1 == host grant access Kinit / service As client: 1.Decrypt TGT with k_user 2.I need access to service A. 3.Send {TGT, A, user, host} to TGS Authentication service / TGS 1.TGS receives TGT 2.Decrypts TGT 3.Validates TGT 4.ticket_A = {user, A, host} k_server_A 5.Send ticket_A

Comments Reusable tickets – once a ticket to a service is obtained, reuse the same ticket Hence tickets can be stored in files What if tickets are stolen and combined with IP spoofing? What if tickets are stolen and used within their lifetimes? Solution – have time stamps on tickets Now ticket = {user, service, host, time when ticket was issued, duration of ticket} k_server

Comments contd… Solution – session key provided by AS to both user and the service 2 copies of session key – one within the service ticket and another outside the ticket Client Build authenticator – {username,address} encrypted by session key Build authenticator – {username,address} encrypted by session key Send {authenticator, ticket} to service Send {authenticator, ticket} to serviceService Decrypts ticket, gets session key Decrypts ticket, gets session key Decrypts authenticator with session key Decrypts authenticator with session key Compares tickets {username, address} with authenticators {username, address} AND with sending {username, address} Compares tickets {username, address} with authenticators {username, address} AND with sending {username, address}

Comments contd.. What if authenticators are stolen across the network? What if users copy of session keys are copied when propagated from AS to the user? So,… Solution – have timestamps of 2 minutes for authenticators (V4) or only-once authenticators (V5) Solution – use adequate encryption of session keys so that users who snoop around the network will not be able to get to the session key

A User / kinit: 1.Iam serc1. I need a TGT. Authentication service / TGS 1.Build k_session_TGS 2.TGT = {username, TGS, host, timestamp, k_session_TGS} k_server_TGS 3.Packet = {k_session_TGS, TGT} k_user 4.Send packet to serc1 User -> A: 1.Decrypt packet with k_session_TGS 2.Authenticator = {user, host} k_session_A 3.Send {authenticator, A, user, host, ticket_A} to A A: 1.Decrypt ticket_A with As password, obtain session key 2.Decrypt authenticator with session key 3.Verify {username, address} across 3 records Kinit / service As client: 1.Decrypt packet with k_user 2.I need access to service A. 3.Authenticator = {username, host} k_session_TGS 4.Send {authenticator, TGT, username, address, service A} to TGS Authentication service / TGS 1.TGS receives TGT 2.Decrypts TGT with its k_server_TGS, obtains k_session_TGS 3.Decrypts authenticator with k_session_TGS 4.Verifies user name, address in ticket, sender and in authenticator 5.Creates k_session_A 6.ticket_A = {user, A, host, k_session_A, time_stamp} k_server_A 7.Packet = {k_session_A, ticket_A} k_session_TGS 8.Send packet to user

Comments Above architecture can also be used for mutual authentication Client first authenticates itself Server then sends a reply encrypted with session key If client can decrypt it, then it is the right server In V5, double encryption of tickets are avoided Ticket forwarding and authorization with proxies are also supported in V5. V5 also supports cross-realm and transitive-realm authentication by sharing secrets between KDCs in 2 realms.

Kerberos Limitations Assumes running on trusted hosts with an untrusted network Attacker can impersonate users who have tickets stored on a machine If KDC is compromised, entire realm is compromised Offline attack to decrypt TGT with different passwords System clock synchronization is needed

GSI Revisited GSI is: GSI uses GSS-API for implementing SSL protocol PKI (CAs and Certificates) SSL Proxies and Delegation PKI for credentials SSL for Authentication And message protection Proxies and delegation (GSI Extensions) for secure single Sign-on PKI: Public Key Infrastructure, SSH: Secure Socket Layer TLS: Transport Level Security Credits: Globus course material

Kerberos vs SSL SSL public-key, certificate-based authentication system public-key, certificate-based authentication system An end of the connection need not have a secret key or password An end of the connection need not have a secret key or password Encryption and decryption keys are not identical Encryption and decryption keys are not identical Certificates stored on disks Certificates stored on disks Creation and delegation of proxies by issuers without the involvement of third-party Creation and delegation of proxies by issuers without the involvement of third-partyKerberos private-key, trusted-third-party authentication system private-key, trusted-third-party authentication system Conventional (shared secret-key) cryptography – encryption and decryption keys are identical Conventional (shared secret-key) cryptography – encryption and decryption keys are identical Passwords not stored on disks Passwords not stored on disks Password revocation is easier Password revocation is easier Creation and delegation of TGTs by third party Creation and delegation of TGTs by third party Needs every site to run Kerberos Needs every site to run Kerberos

SSL Disadvantages Clients manage each other public key rigorously Clients need to secure their private keys CAs also have scalability problems

References html

GSS-API Generic API to support security applications portability IETF standard for adding authentication, delegation, message integrity, and message confidentiality to applications. Some Grids use kerberos GSS-API, others use GSI GSS-API

GSS-API Sample API gss_acquire_cred() gss_acquire_cred() gss_init_sec_context() gss_init_sec_context() gss_accept_sec_context() gss_accept_sec_context() gss_indicate_mech() gss_indicate_mech() gss_init_delegation() gss_init_delegation() gss_accept_delegation() gss_accept_delegation()

Junk !

Kerberos architecture

Miscellanious Kerberos applications are called principals KDC = AS + TGS Backup KDCs called slave servers Key salt and kvno Forwardable tickets, renewable tickets, postdatable tickets, proxiable tickets

Copyrights Copyright 1988, 1997 Massachusetts Institute of Technology Permission to use, copy, modify, and distribute this documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the documentation without specific, written prior permission. M.I.T. makes no representations about the suitability of this documentation for any purpose. It is provided "as is" without express or implied warranty.