Kerberos and its application in cross realm operations

Kerberos and its Application in Cross-Realm OperationsSECURITY PROTOCOLS

GROUP-1

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

Basic Kerberos Protocol

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.

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

Kerberos Components

• Principals

• Realms

• Key Distribution Centers (KDC’s)• Authentication Service• Ticket Granting Server

• Credentials• Ticket

• Ticket Granting Ticket

• Service Ticket

• Authenticator

Kerberos Principals

Client Service Server

KDC(Local/Foreign)

Kerberos Protocol

ClientService Server

Step1

Step2

Step3

Step4

Step5

Step6

Kerberos ProtocolStep 1:

AS Request:To Authentication server

Client Principal and Service Principal Name

Client


AS Reply: Encrypted with Clients key(Ticket Granting Ticket, Shared Key)

{TC,TGS}KTGS, {KC,TGS || …}KC

Client


TGS Request: Ticket Granting Ticket, Authenticator, Service Principal Name

{AC,TGS}KC,TGS, {TC,TGS}KTGS, ||…

Client


TGS Reply: Encrypted with the session key from AS Reply(Service Ticket, Session Key)

{TC,S}KS, {KC,S}KC,TGS

Client


Server Request: Client sends Ticket along with the authenticator to Authenticate and Establish Shared Secret

{AC,S}KC,S, {TC,S}KS

Client

Service Server


Server Replies: To client with the proof of Possesion of the Shared key

{timestamp+1}KC,S

Client

Service Server

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.

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.

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.

Cross Realm Interaction

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 !!

• 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 !!

Kerberos based Authentication for Cross Realm Interaction

Kerberos based Authentication for Cross Realm 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

KDC-H

1) T

GT-

T?

3) TGT-T

?

5) ST-SRV?

6) ST-SRV

4) TGT-T

2) TG

T-IHome Realm

KDC-I KDC-T

Trust-Chain

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

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.

Improved Cross-Realm Kerberos Protocol (XKDCP)INTER KEY DISTRIBUTION CENTRE PROTOCOL

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 XASP

XTGSP: Allows users to obtain service tickets from a KDC even if the service is not registered in that KDC.

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.

XTGSPINTER TICKET GRANTING SERVICE PROTOCOL

XTGSP

• When a TGS can not process a request for a service ticket because the service's realm is different from the TGS's 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.

AS TGS-H TGS-F AS

Service

Home Realm Foreign Realm

User

Home KDC Foreign KDC

1 2

3

4

5

6

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

AS TGS-H TGS-F AS

Service


User


1) AS exchange

1) Normal AS Exchange• AS request: C->AS: Client Principal and Service Principal Name• AS response: AS->C :{TUser,TGS}KTGS, {KUser,TGS || …}KUser

AS TGS-H TGS-F AS

Service


User


2) 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 realm name where service is present.

2) TGS_REQ

AS TGS-H TGS-F AS

Service


User


3) 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)

3) XTGSP_REQ

AS TGS-H TGS-F AS

Service


User


4) 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)

4) XTGSP_REP

AS TGS-H TGS-F AS

Service


User


5) 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

5) TGS_REP

AS TGS-H TGS-F AS

Service


User


6) AP exchange• User sends the ticket to S along with an authenticator to

authenticate and establish the shared secretUser->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

6) AP exchange

AS TGS-H TGS-F AS

Service


User


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

3) XTGSP_REQDrawback

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.

XASPINTER AUTHENTICATION SERVICE PROTOCOL

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.

TGS AS-H AS-H TGS

Service


User

Home KDC Foreign KDC2

6

3

1 45

When an AS can not process a AS_REQ message sent by the client because the client does not belong to the local realm, the XASP extension can be used between the visited AS and the home AS to build the required credentials (a TGT) for the roaming client.

TGS AS-H AS-F TGS

Service


User


1) 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 foreign realm to authenticate itself as per the request.

1) AS_REQ

TGS AS-H AS-F TGS

Service


User

Home KDC Foreign KDC2) XASP_REQ

2) XASP_REQ:• If the realm name in the previous message doesn't 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)

TGS AS-H AS-F TGS

Service


User


3) XASP_REP

3) 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)

TGS AS-H AS-F TGS

Service


User


4) AS_REP

4) 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

TGS AS-H AS-F TGS

Service


User


5) TGS Exchange

5) 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 STGS User: {TUser,S}KS, {KUser,S}KUser,TGS

where TUser,S= {User, User-addr, lifetime, KUser,S}

TGS AS-H AS-F TGS

Service


User


6) AP exchange

6) AP exchange:• User sends the ticket to S along with an authenticator to

authenticate and establish the shared secretUser S: {AUser,S}KC,S, {TUser,S}KS

where AUser,S= {User, timestamp}• S User: {timestamp+1}KUser,S

TGS AS-H AS-F TGS

Service


User


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

1) AS_REQ

DoS Attack on Foreign KDC

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.

References

1. 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”, 2007

2. http://tools.ietf.org/id/draft-ietf-cat-kerberos-pk-cross-08.txt

3. http://tools.ietf.org/html/draft-zrelli-krb-xkdcp-00

4. http://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-kerberos.html

Group Members

• Ravi Goyal (200901001)• Puneet Kala (200901008)• Arunangshu Bhakta (200901026)• Unique Jain (200901036)• Lalit Agarwal (200901159)• Taru Raaj Agarwal (200901167)• Drasti Shah (200901172)

Kerberos and its application in cross realm operations

Education

Transcript of Kerberos and its application in cross realm operations