Kerberos and its application in cross realm operations
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Kerberos and its application in cross realm operations

  • 872 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
872
On Slideshare
872
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
22
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Kerberos and itsApplication in Cross-RealmOperationsSECURITY PROTOCOLSGROUP-1
  • 2. Contents• Basic Kerberos • Components • Protocol • Strengths • Weaknesses• Cross Realm Operations• Cross Realm Operations with Kerberos Based Authentication • Authentication Simplified • Scalability Issues• Improved Cross Realm Kerberos Authentication Protocols (XKDCP) • XTGSP • XASP • Shortcomings of XTGSP & XASP and their mitigation
  • 3. Basic Kerberos Protocol
  • 4. Introduction to Kerberos• Kerberos provides a way to authenticate clients to services to each other through a trusted third party.• Kerberos makes the assumption that the connection between a client and service is insecure.• Passwords are encrypted to prevent others from reading them.• Clients only have to authenticate once during a pre- defined lifetime.
  • 5. Goals of Kerberos Protocol• Principals must not be able to impersonate other principals (i.e. principals must be authenticated)• The authentication secret (i.e. password) used by the principals must not be transmitted in clear text• It must not be necessary for all principals to be able to authenticate all other principals by themselves.• Principals should only need to authenticate themselves once (in the case of a user, this is typically when they logon to a workstation).
  • 6. Kerberos Components• Principals• Realms• Key Distribution Centers (KDC’s) • Authentication Service • Ticket Granting Server• Credentials • Ticket • Ticket Granting Ticket • Service Ticket • Authenticator
  • 7. Kerberos PrincipalsClient Service Server KDC (Local/Foreign)
  • 8. Kerberos Protocol Step5 Step6 Service Client Server
  • 9. Kerberos ProtocolStep 1: Client
  • 10. Kerberos ProtocolStep 2: Client
  • 11. Kerberos ProtocolStep 3: Client
  • 12. Kerberos ProtocolStep 4: Client
  • 13. Kerberos ProtocolStep 5: Service Server Client
  • 14. Kerberos ProtocolStep 6: Service Server Client
  • 15. Strengths• Passwords are never sent across the network unencrypted. This prevents those unscrupulous people from being able to read the most important data sent over the network.• Clients and applications services mutually authenticate. Mutual authentication allows for both ends to know that they truly know whom they are communicating with.• Tickets have a limited lifetime, so if they are stolen, unauthorized use is limited to the time frame that the ticket is valid.
  • 16. Strengths• Authentication through the AS only has to happen once. This makes the security of Kerberos more convenient.• Shared secret keys between clients and services are more efficient than public-keys.• Many implementations of Keberos have a large support base and have been put through serious testing.• Authenticators, created by clients, can only be used once. This feature prevents the use of stolen authenticators.
  • 17. Weaknesses• Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms.• Kerberos has strict time requirements, which means the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail.• Since all authentication is controlled by a centralized KDC, compromise of this authentication infrastructure will allow an attacker to impersonate any user.
  • 18. Cross Realm Interaction
  • 19. Multiple Realm Scenario• User in one realm (say DAIICT) may intend to use the services in another realm (say NIFT)• In such a case, how will the user (DAIICT student) authenticate himself to the foreign KDC (NIFT KDC) while sitting in DAIICT?• How will the user (DAIICT student) authenticate himself to the foreign KDC (NIFT KDC) while visiting NIFT?• But, user’s (DAIICT student) trustworthiness is known only to the local KDC (DAIICT KDC). Thus, only respective local KDC can authenticate the user.• Hence, there’s a need for Cross-Realm Authentication !!
  • 20. • Main issues in existing cross-realm authentication frameworks: • User needs to authenticate itself every time he tries to access a different service • User has to manage a large number of accounts • Low Scalability These issues have been addressed by using Kerberos Based Authentication in Cross-Realm Interactions !!
  • 21. Kerberos based Authenticationfor Cross Realm Interaction
  • 22. Kerberos based Authentication for CrossRealm Interaction• Allow users of one realm to authenticate with services in other realms• One time authentication required• Implemented by sharing a “secret” that realizes the trust relationship between realms• Using the shared secret key, KDC’s can check the authenticity of cross-realm request coming from users of trusted realm and then can securely issue service tickets for them
  • 23. Trust-Chain KDC-H KDC-I KDC-T1) TGT-T? 2) TGT-I 5) ST-SRV? 6) ST-SRV Home Realm
  • 24. Issues in Cross Realm Kerberos• Inter-realm trust management • KDCs can have a direct or indirect relationship with other KDCs. • In direct relationships, KDC of each realm must maintain keys with all foreign realms. • Difficult to maintain large number of keys. • Indirect trust relationship means that there is a chain of trust’ linking the two realms. • A chain of trust can be determined by DNS hierarchy or else manually (can become cumbersome).
  • 25. Issues in Cross Realm Kerberos• Reliability- • If any of the realms in the authentication is not available, then the principals of the end-realms cannot perform cross-realm operations.• Client Centralised Exchanges- • Clients have to perform TGS exchanges with all the KDCs in the trust path. • When clients have limited computational capabilities, overhead of these cross-realm exchanges may grow into unacceptable delays.
  • 26. Improved Cross-RealmKerberos Protocol (XKDCP)INTER KEY DISTRIBUTION CENTREPROTOCOL
  • 27. XKDCP(Inter Key Distribution Centre Protocol)• The XKDCP extension allows the client to obtain the service ticket from any KDC for which she already has a TGT.• XKDCP is based on public-key certificates. XKDCP XTGSP XASPXTGSP: Allows users to obtain service tickets from a KDC even if theservice is not registered in that KDC.XASP: Allows two Kerberos KDCs to collaborate in order to authenticatea roaming user and to deliver a TGT that can be used in the visitedrealm.
  • 28. XTGSPINTER TICKET GRANTING SERVICEPROTOCOL
  • 29. XTGSP• When a TGS can not process a request for a service ticket because the services realm is different from the TGSs realm, then the XTGSP protocol can be used between the TGS of both realms to build the desired service ticket.• Allows users to obtain service tickets from a KDC even if the user is not registered in that KDC.• Used in remote access scenarios • a user has a TGT for a local KDC and wishes to access a service deployed in a remote realm.
  • 30. 3 Home KDC Foreign KDC AS TGS-H TGS-F AS 4 1 2 5 Service 6 User Home Realm Foreign Realm• Client does not need to contact the remote KDC at all in which the service is registered.• Local KDC will deliver the service ticket that can be used directly to authenticate with the remote service.
  • 31. Home KDC Foreign KDC AS TGS-H TGS-F AS 1) AS exchange Service User Home Realm Foreign Realm1) Normal AS Exchange• AS request: C->AS: Client Principal and Service Principal Name• AS response: AS->C :{TUser,TGS}KTGS, {KUser,TGS || …}KUser
  • 32. Home KDC Foreign KDC AS TGS-H TGS-F AS 2) TGS_REQ Service User Home Realm Foreign Realm2) TGS_REQ:User requests a ticket from the ticket-granting service (TGS) User TGS: {AUser, TGS}KUser,TGS, {TUser,TGS}KTGS, ||… where AUser,TGS= {User, timestamp, realm}Note: Additionally “Realm” field should be set to the foreign realmname where service is present.
  • 33. 3) XTGSP_REQ Home KDC Foreign KDC AS TGS-H TGS-F AS Service User Home Realm Foreign Realm3) XTGSP_REQ• It is built from users TGS_REQ message.• Also includes a signed payload to authenticate home KDC. TGS-H->TGS-F: {TGS_REQ}sigKDCH, cert(KDC-H)
  • 34. Home KDC Foreign KDC AS TGS-H TGS-F AS 4) XTGSP_REP Service User Home Realm Foreign Realm4) XTGSP_REP• TGS-F authenticates the previous message by verifying the public key signature.• Issues a ticket and an associated session key. Ticket is encrypted by key shared between the server and the foreign KDC. TGS-F->TGS-H: {{Session Key}KKDC-H, {TUser,S}KS}sigKDC-F, cert(KDC-F)
  • 35. Home KDC Foreign KDC AS TGS-H TGS-F AS 5) TGS_REP Service User Home Realm Foreign Realm5) TGS_REP• TGS-H authenticates the previous message by verifying the public key signature.• Decrypts the session key and encrypts it with the key shared between the Home-KDC and the user. TGS-H->User:{Session Key}KKDC-H, User, Ticket
  • 36. Home KDC Foreign KDC AS TGS-H TGS-F AS Service 6) AP exchange User Home Realm Foreign Realm6) AP exchange• User sends the ticket to S along with an authenticator to authenticate and establish the shared secret User->S: {AUser,S}KUser,Service, {TUser,S}KS• S decrypts the first part and obtains TUser,S to know the session key KUser,S replies to user with proof of possession of the shared secret S->User: {timestamp+1}KUser,S
  • 37. Drawback 3) XTGSP_REQ Home KDC Foreign KDC AS TGS-H TGS-F AS Service User Home Realm Foreign RealmXTGSP_REQ• The message sent by TGS-H are verified by TGS-F using public key certificates.• TGS-F is not capable enough to decide if the Home KDC should be offered the services or not.
  • 38. Proposed Solution• TGS-F should maintain a table enlisting specifically that which service can be used by which KDC .• Whenever it receives a message from an entity not mentioned in the list, it should contact its AS for further verification.• It should reply back to the requesting KDC only if its reliability is approved by its AS.
  • 39. XASPINTER AUTHENTICATION SERVICEPROTOCOL
  • 40. XASP• Allows two Kerberos KDCs to collaborate in order to authenticate a roaming user and to deliver a TGT that can be used in the visited realm to obtain service tickets .• Used in situations where the home KDC (or the KDC for which the client has a TGT) is not reachable.
  • 41. 2 Home KDC Foreign KDC TGS AS-H AS-H TGS 3 1 4 5 Service 6 User Home Realm Foreign RealmWhen an AS can not process a AS_REQ message sent by the client because theclient does not belong to the local realm, the XASP extension can be usedbetween the visited AS and the home AS to build the required credentials (a TGT)for the roaming client.
  • 42. Home KDC Foreign KDC TGS AS-H AS-F TGS 1) AS_REQ Service User Home Realm Foreign Realm1) AS_REQ:• User  AS-F: Client Principal and Service Principal Name• The client must put her home realm name in the ‘realm’ field of the request.Note: Any user can probe a foreign realm and make the KDC of the foreignrealm to authenticate itself as per the request.
  • 43. 2) XASP_REQ Home KDC Foreign KDC TGS AS-H AS-F TGS Service User Home Realm Foreign Realm2) XASP_REQ:• If the realm name in the previous message doesnt match with its own realm name, AS-F locates the KDC that serves the client’s home realm (AS-H).• This request signed duly for authentication. AS-F->AS-H: {AS_REQ}sigKDCF, cert(KDC-F)
  • 44. Home KDC Foreign KDC TGS AS-H AS-F TGS 3) XASP_REP Service User Home Realm Foreign Realm3) XASP_REP:• Home KDC authenticates the previous message by verifying the signature using public key cryptography.• Creates a TGS session key encrypted by user’s secret key.• A copy of same TGS session key is encrypted using foreign KDC’s public key.• A signature is also included that authenticates itself to the foreign KDC. AS-H->AS-F: {{TGS_SK}Kuser, {TGS_SK}KKDCF}sigKDCH, cert(KDC-H)
  • 45. Home KDC Foreign KDC TGS AS-H AS-F TGS 4) AS_REP Service User Home Realm Foreign Realm4) AS_REP:• KDCF validates by verifying the signature.• Decrypts the TGS session key using its own private key, which is used to build a TGT for the roaming user.• TGS session key encrypted by user’s secret key and TGT are sent to user. AS-F->User: {TGS_SK}Kuser, {TUser,TGS}KTGS
  • 46. Home KDC Foreign KDC TGS AS-H AS-F TGS 5) TGS Exchange Service User Home Realm Foreign Realm5) TGS Exchange:• User requests a ticket from the ticket-granting service (TGS) User TGS: {AUser, TGS}KUser,TGS, {TUser,TGS}KTGS, ||… where AUser,TGS= {User, timestamp, realm}• TGS returns a ticket for User to talk to S TGS User: {TUser,S}KS, {KUser,S}KUser,TGS where TUser,S= {User, User-addr, lifetime, KUser,S}
  • 47. Home KDC Foreign KDC TGS AS-H AS-F TGS 6) AP Service exchange User Home Realm Foreign Realm6) AP exchange:• User sends the ticket to S along with an authenticator to authenticate and establish the shared secret User S: {AUser,S}KC,S, {TUser,S}KS where AUser,S= {User, timestamp}• S User: {timestamp+1}KUser,S
  • 48. DoS Attack on Foreign KDC Home KDC Foreign KDC TGS AS-H AS-F TGS 1) AS_REQ Service User Home Realm Foreign Realm• Any User can probe a foreign realm and keep the KDC of the foreign realm busy to authenticate itself.• The KDC will therefore remain busy in authenticating the user and will not do any productive work.• Foreign KDC cant authenticate the client.
  • 49. Proposed Solution• Public key certificates can also be used for clients.• Each time a client wants to contact the foreign KDC it will send the message along with its certificate.• The foreign KDC can keep a track of the messages sent by a particular user.• It can reject the messages if they exceed the threshold limit of a user.
  • 50. References1. Saber Zrelli, Tunc Medeni and Yoichi Shinoda, “Improving Kerberos Security System for Cross-Realm Collaborative Interactions: An Innovative Example of Knowledge Technology for Evolving & Verifiable E-Society”, 20072. http://tools.ietf.org/id/draft-ietf-cat-kerberos-pk-cross-08.txt3. http://tools.ietf.org/html/draft-zrelli-krb-xkdcp-004. http://web.mit.edu/rhel-doc/5/RHEL-5- manual/Deployment_Guide-en-US/ch-kerberos.html
  • 51. Group Members• Ravi Goyal (200901001)• Puneet Kala (200901008)• Arunangshu Bhakta (200901026)• Unique Jain (200901036)• Lalit Agarwal (200901159)• Taru Raaj Agarwal (200901167)• Drasti Shah (200901172)