kerberos and its application in cross realm operations
TRANSCRIPT
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
Kerberos ProtocolStep 2:
AS Reply: Encrypted with Clients key(Ticket Granting Ticket, Shared Key)
{TC,TGS}KTGS, {KC,TGS || …}KC
Client
Kerberos ProtocolStep 3:
TGS Request: Ticket Granting Ticket, Authenticator, Service Principal Name
{AC,TGS}KC,TGS, {TC,TGS}KTGS, ||…
Client
Kerberos ProtocolStep 4:
TGS Reply: Encrypted with the session key from AS Reply(Service Ticket, Session Key)
{TC,S}KS, {KC,S}KC,TGS
Client
Kerberos ProtocolStep 5:
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
Kerberos ProtocolStep 6:
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
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
Home Realm Foreign Realm
User
Home KDC Foreign KDC
• 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)