Security ProtocolsSecurity Protocols

Sathish VadhiyarSathish Vadhiyar

Sources / Credits: Kerberos web pages and documents contained / pointed thereinhttp://web.mit.edu/kerberos/www/dialogue.htmlhttp://web.mit.edu/kerberos/www/dialogue.html

KerberosKerberos

Provides authentication and encryptionProvides authentication and encryptionServices and clients in an open networked Services and clients in an open networked environmentenvironmentOne method is for the service to ask for One method is for the service to ask for password, i.e. the server needs to know password, i.e. the server needs to know the password of the user – not scalablethe password of the user – not scalableAnother method – clients have their Another method – clients have their passwords, services have their passwords, passwords, services have their passwords, centralized service called authentication centralized service called authentication service knows both passwordsservice knows both passwords

Kerberos architectureKerberos architecture

A

User:Iam serc1. I want to accessA.

serc1 password

Authentication service:1. serc1 is in my

database2. Password matches.3. ticket_A = {user}

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

CommentsCommentsHow can a server verify that it has How can a server verify that it has decrypted the ticket correctly? – decrypted the ticket correctly? – solution: solution:

What happens if the ticket is stolen What happens if the ticket is stolen by someone over the network? - by someone over the network? - solution: solution:

But still some more problems: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 stolenSolutions: kinit, TGS, TGT

Modified Kerberos architectureModified Kerberos architecture

A

User / kinit:1. Iam serc1. I need a

TGT.

Authentication service / TGS

1. serc1 is in my database2. TGT = {user, TGS, host}

k_TGS, k_user3. 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 A’s 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 TGT2. Decrypts TGT3. Validates TGT4. ticket_A = {user, A,

host} k_server_A5. Send ticket_A

CommentsComments

Reusable tickets – once a ticket to a Reusable tickets – once a ticket to a service is obtained, reuse the same ticketservice is obtained, reuse the same ticket

Hence tickets can be stored in filesHence tickets can be stored in files

What if tickets are stolen and combined What if tickets are stolen and combined with IP spoofing?with IP spoofing?

What if tickets are stolen and used within What if tickets are stolen and used within their lifetimes?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…Comments contd…

Solution – session key provided by AS to Solution – session key provided by AS to both user and the serviceboth user and the service2 copies of session key – one within the 2 copies of session key – one within the service ticket and another outside the service ticket and another outside the ticketticketClientClient Build authenticator – {username,address} Build authenticator – {username,address}

encrypted by session keyencrypted by session key Send {authenticator, ticket} to serviceSend {authenticator, ticket} to serviceServiceService Decrypts ticket, gets session keyDecrypts ticket, gets session key Decrypts authenticator with session keyDecrypts authenticator with session key Compares ticket’s {username, address} with Compares ticket’s {username, address} with

authenticator’s {username, address} AND with authenticator’s {username, address} AND with sending {username, address}sending {username, address}

Comments contd..Comments contd..

What if authenticators are stolen What if authenticators are stolen across the network? across the network?

What if user’s copy of session keys What if user’s copy of session keys are copied when propagated from AS are copied when propagated from AS to the user?to the user?

So,…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 / TGS1. Build k_session_TGS2. 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_TGS2. Authenticator = {user,

host} k_session_A 3. Send {authenticator, A,

user, host, ticket_A} to A

A:1. Decrypt ticket_A with A’s

password, obtain session key

2. Decrypt authenticator with session key

3. Verify {username, address} across 3 records

Kinit / service A’s client:1. Decrypt packet with k_user2. I need access to service A.3. Authenticator = {username,

host} k_session_TGS4. Send {authenticator, TGT,

username, address, service A} to TGS

Authentication service / TGS1. TGS receives TGT2. 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_A6. 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

CommentsComments

Above architecture can also be used for mutual Above architecture can also be used for mutual authenticationauthenticationClient first authenticates itselfClient first authenticates itselfServer then sends a reply encrypted with session Server then sends a reply encrypted with session keykeyIf client can decrypt it, then it is the right serverIf client can decrypt it, then it is the right serverIn V5, double encryption of tickets are avoidedIn V5, double encryption of tickets are avoidedTicket forwarding and authorization with proxies Ticket forwarding and authorization with proxies are also supported in V5.are also supported in V5.V5 also supports cross-realm and transitive-realm V5 also supports cross-realm and transitive-realm authentication by sharing secrets between KDCs authentication by sharing secrets between KDCs in 2 realms.in 2 realms.

Kerberos LimitationsKerberos Limitations

Assumes running on trusted hosts with Assumes running on trusted hosts with an untrusted networkan untrusted networkAttacker can impersonate users who Attacker can impersonate users who have tickets stored on a machinehave tickets stored on a machineIf KDC is compromised, entire realm is If KDC is compromised, entire realm is compromisedcompromisedOffline attack to decrypt TGT with Offline attack to decrypt TGT with different passwordsdifferent passwordsSystem clock synchronization is System clock synchronization is neededneeded

GSI RevisitedGSI Revisited

GSI is:GSI is:GSI uses GSS-API for GSI uses GSS-API for implementing SSL protocolimplementing SSL protocol

PKI(CAs and

Certificates)SSL

Proxies and Delegation

PKI forcredentials

SSL forAuthenticationAnd message protection

Proxies and delegation (GSIExtensions) for secure singleSign-on

PKI: Public Key Infrastructure, SSH: Secure Socket LayerTLS: Transport Level Security

Credits: Globus course material

Kerberos vs SSLKerberos vs SSL

SSLSSL public-key, certificate-based authentication systempublic-key, certificate-based authentication system An end of the connection need not have a secret key or An end of the connection need not have a secret key or

passwordpassword Encryption and decryption keys are not identicalEncryption and decryption keys are not identical Certificates stored on disksCertificates stored on disks Creation and delegation of proxies by issuers without the Creation and delegation of proxies by issuers without the

involvement of third-partyinvolvement of third-partyKerberosKerberos

private-key, trusted-third-party authentication systemprivate-key, trusted-third-party authentication system Conventional (shared secret-key) cryptography – encryption Conventional (shared secret-key) cryptography – encryption

and decryption keys are identicaland decryption keys are identical Passwords not stored on disksPasswords not stored on disks Password revocation is easierPassword revocation is easier Creation and delegation of TGTs by third partyCreation and delegation of TGTs by third party Needs every site to run KerberosNeeds every site to run Kerberos

SSL DisadvantagesSSL Disadvantages

Clients manage each other public Clients manage each other public key rigorouslykey rigorously

Clients need to secure their private Clients need to secure their private keyskeys

CA’s also have scalability problemsCA’s also have scalability problems

ReferencesReferences

http://web.mit.edu/kerberos/www/http://web.mit.edu/kerberos/www/dialogue.htmldialogue.html

GSS-APIGSS-API

Generic API to support security Generic API to support security applications portabilityapplications portability

IETF standard for adding IETF standard for adding authentication, delegation, message authentication, delegation, message integrity, and message integrity, and message confidentiality to applications.confidentiality to applications.

Some Grids use kerberos GSS-API, Some Grids use kerberos GSS-API, others use GSI GSS-APIothers use GSI GSS-API

GSS-APIGSS-API

Sample APISample 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 !Junk !

Kerberos architectureKerberos architecture

MiscellaniousMiscellanious

Kerberos applications are called principalsKerberos applications are called principals

KDC = AS + TGSKDC = AS + TGS

Backup KDCs called slave serversBackup KDCs called slave servers

Key salt and kvnoKey salt and kvno

Forwardable tickets, renewable tickets, Forwardable tickets, renewable tickets, postdatable tickets, proxiable ticketspostdatable tickets, proxiable tickets

CopyrightsCopyrights

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