1. Kerberos and its
Application in Cross-Realm
Operations
SECURITY PROTOCOLS
GROUP-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 Principals
Client Service
Server
KDC
(Local/Foreign)

8. Kerberos Protocol
Step5
Step6
Service
Client Server

9. Kerberos Protocol
Step 1:
Client

10. Kerberos Protocol
Step 2:
Client

11. Kerberos Protocol
Step 3:
Client

12. Kerberos Protocol
Step 4:
Client

13. Kerberos Protocol
Step 5:
Service
Server
Client

14. Kerberos Protocol
Step 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 Authentication
for Cross Realm Interaction

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

23. Trust-Chain
KDC-H KDC-I KDC-T
1) 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-Realm
Kerberos Protocol (XKDCP)
INTER KEY DISTRIBUTION CENTRE
PROTOCOL

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

28. XTGSP
INTER TICKET GRANTING SERVICE
PROTOCOL

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

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

33. 3) XTGSP_REQ
Home KDC Foreign KDC
AS TGS-H TGS-F AS
Service
User
Home Realm Foreign Realm
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)

34. Home KDC Foreign KDC
AS TGS-H TGS-F AS
4) XTGSP_REP
Service
User
Home Realm Foreign Realm
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)

35. Home KDC Foreign KDC
AS TGS-H TGS-F AS
5) TGS_REP
Service
User
Home Realm Foreign Realm
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

36. Home KDC Foreign KDC
AS TGS-H TGS-F AS
Service
6) AP exchange
User
Home Realm Foreign Realm
6) 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 Realm
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.

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. XASP
INTER AUTHENTICATION SERVICE
PROTOCOL

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

42. Home KDC Foreign KDC
TGS AS-H AS-F TGS
1) AS_REQ Service
User
Home Realm Foreign Realm
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.

43. 2) XASP_REQ
Home KDC Foreign KDC
TGS AS-H AS-F TGS
Service
User
Home Realm Foreign Realm
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)

44. Home KDC Foreign KDC
TGS AS-H AS-F TGS
3) XASP_REP
Service
User
Home Realm Foreign Realm
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)

45. Home KDC Foreign KDC
TGS AS-H AS-F TGS
4) AS_REP
Service
User
Home Realm Foreign Realm
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

46. Home KDC Foreign KDC
TGS AS-H AS-F TGS
5) TGS
Exchange
Service
User
Home Realm Foreign Realm
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 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 Realm
6) 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. 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

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)