Upload
khalid-wilkes
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
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.