Kerberos

From CryptoWiki
Jump to: navigation, search

Kerberos is network protocol of authentication allowing transfer data through exposed networks for dafe identication. It’s usually focused on the client-server model and provide a mutual authentication – both users through server authenticate each other’s personalities. This model is one of varieties of Nidchem-Schröder authentication protocol based on trusted third party.

Contents

Formal description

Let’s introduce some symbols:

  • A,B – as Alice and Bob, parties of protocol
  • Trent – as a trusted third party
  • L – as key lifetime
  • K – as a session key
  • T – as a timestamp


Protocol uses the symmetrical encryption only and suggests that each correspondent (Alice and Bob) has a common private key with third trusted party (Trent).

Alice sends to a trusted party (Trent) her and Bob’s identifiers.

Kerb1.PNG

Trent generates two messages. The first one includes the T timestamp, the key lifetime L, a new session key for Alive and Bob (K) and Bob’s identifier B. This message is encrypted by common key of Alice and Trent. The second message contains the same excluding identifier, replaced by Alice’s one. The message itself is encrypted by common key of Bob and Trent.

Kerb2.PNG

Alice generates a message on her own ‘A’ identifier and a T timestamp, then encrypts the message by the K session key and sends to Bob with the second Trent’s message.

Kerb3.PNG

For own authentication purpose Bob encrypts a modified Timestamp “T+1” through common session key (K) and sends it to Alice. Kerb4.PNG

Важным предположением является синхронизированность часов всех участников протокола. Однако на практике используется синхронизация с точностью до нескольких минут с запоминанием истории передач (с целью обнаружения повтора) в течение некоторого времени.

Protocol description

Kerberos 4

Kerberos 4 is mostly based on Nidchem-Schroeder protocol excluding two significant changes:

  • the first one has decreased the quantity of messages forwarded between clienf and authentication server;
  • the second, more important one, is all in TGT concept appearing. This concept allows to users to be authentified in several services using user trusted data only once.


As a result, the Kerberos 4 contains two logical components: the AS - authentication server and the TGS — Ticket Granting Server. These use to be supplied as a single program launched on the Key Distribution Centre.

The KDC contains a login-password base for users and services applying Kerberos.

The authentication server has only one function: he receives a request containing requesting client's name, and outputs an encrypted TGT. Then user can apply this TGT to request for next keys for other services. In most Kerberos realizations the TGT lifetime is about 8-10 hours. When this time is over a client has to request it from AS again.

The first message sent to a KDC is a request to the SA aka AS_REQ. This message is sent plain text and contains clentr's identification data, a timestamp and a TGS identifier.

When the KDC receives the AS_REQ he verifies hat a client having sent it really existsand his timestamp corresponds to the KDC local time (+5 minutes usually). This check is carrying out not for ensure defense from repeats (the message is sent plain text), but to time correspondence check. If only one of the checks fails, then a client receives a message about error and can't be authentified. In case of successful check the AS generates a random session key which shall be used by both client and TGS. this key protects coming ticket requests from TGS for another services. The KDC creates 2 copies of a session key: for client and for TGS correspondingly. Then the KDC responses to client with an authentication server message aka AS_REP encrypted by a longtime client key. This includes a TGT encrypted by TGS key (the TGT as it is contains a copy of TGS session key, a client identifier, a key's lifetime, a ticket's lifetime, a KDC timestamp, client's IP-address), a copy of session key for client and a TGS identifier.

When a user wants to get access to the service he will prepare a TGS_REQ containing 3 parts: the service's identifier, the copy of TGT received before and an identifier (an authenticator includes a timestamp encripted by session key received from the AS and works for defense from repeats).

During the client 's request receiving, the KDC forms a new session key for client-service interaction. Then it sends a TGS_REP encrypted by a session key received from the AS. This message contains a new session key, a service ticket consisting of new session key copy, a client identifier, a ticket's lifetime, notes of KDC local time, client's IP. This ticket is usually encrypted by a longtime service key. The ticket's lifetime is also noted.

Details of the last step (sending a service ticket to the application server) haven't been standardized in Kerberos 4, therefore its realization depends on the app completely.


Kerberos 5

Kerberos 5 is a modification of a 4th ver., saves all of its functions and contains many add-ons. However in terms of implementation Kerberos5 is a completely new protocol.

The main reason of 5th version's development was inability of 4th to be expanded. During the time the brute-force attack methode became extremely actual, but fields used in messages had a fixed size, and using of more resistant encryption algorithm wasn't possible.

To solve this problem was decided to create an expandable protocol able to be used on various platforms basen on the ASN.1.technology. It let to use in transactions different types of encryption. Due to this the compatibility wih a previojs version was realized. Moreover a KDC now can choose the most safe encryption protocol supported by every party.

The original Kerberos 4 was vulnerable facing brute-force. This vulnerability is related with the fact that a KDC gives an encrypted TGT to every client. The impostance of such problem is sharpened by user's habitude to create easy passwords.

To complicate a carrying out of this kind of attack there was a preliminary authentication added in Kerberos 5. On this step a KDS requires that a user has confirm his identity before he gets a ticket.

The KDC policy is responsible for preliminary authentication, if it's required, a user will receive the KRB_ERROR message during his first request to the SA. This message will inform him that he should send an AS_REQ with his data to be identified. If a KDC doesn't recognize it, then a user will receive an another KRB_error informing about error, and therefore a TGT won't be given.

Specification

The Kerberos v5 works next way:

User sign-on:

  1. User enters his name and password on his client machine;
  2. Client machine implements with a password an unilateral function (usually a hash), and a result becomes a secret user/client key.

Client's authentication:

  1. C lient sends his AS_REQ to the AS to get his verified authentication data and send them later to the TGS server (later he (if client)will use them to get tickets with any extra requests to implementation of a private key) this request contain:
    • Client's identifier, his timestamp and server identifier.
  2. If a KDC orders a preliminary authentication, then user receives a KRB_error message, as answer to which he sends a repeating request but with his identification data now;
  3. The AS checks if there is this client in the base. When yes, then the AS sends back the AS_REP message containing:
    • Session key/TGS, a TGS identifier and ticket's lifetime encrypted through the client's private key;
    • TGT that includes client's identifier and net-address, a KDC timestamp, ticket's lifetime and a session key Client/TGS. It is usually encrypted through the private TGS key
    • If not, a client receives a new message about error having passed.
  4. Having received the message, a client decrypts his part to get the session key Client/TGS. This session key is used for further exchange with TGS server. (NB: client can't decrypt his TGT as it's encrypted through a private TGS key). In this moment user has enough data to be authorized on TGS.


Client TGS authorization:

  1. For request a client forms his TGS_REQuest, containing next data:
    • TGT received before and service's identifier
    • Authenticator combining client ID and a timestamp, encryptes on a session key Client/TGS
  2. Having got TGS_REQ, TGS extracts a TGT from there and decrypts it using a TGS private key. It brings to it a session key Client/TGS through which it decrypts the authenticator. Then if generates a session client/service key and sends a TGS_REP including:
    • Service ticket (containing client ID, ip-address, a KDC timestamp, ticket's lifetime ans a session key client/service) encrypted through a service private key.
    • Session key client/service, service identifier and ticket's lifetime, encrypted on a session key Client/TGS.

Client's service request:

  1. After TGS_REP is received a client has enough information for authorization on a service. A client connects to him and sends him a message containing:
    • The encrypted service ticket received earlier;
    • New authenticator encrypted on a session key client/service and including client's ID and a timestamp
  2. The service decrypts a ticket with its own private key and gets a session client/service key. Using a new key it decrypts the authenticator and forwards to a client the next message to confirm its readiness to serve client and to make him see it's really the claimed server.
    • Timestamp given by client +1, encrypted on a session key client/service.
  3. Client decrypts the confirmation, using a session key client/service and verifies if the timestamp is updated correctly. When yes, then a client can trust to server and can start working.
  4. The server provides him the requested service.

PKINIT

The PKINIT extension concerned the preliminary client authentication step, whereupon it turned out to pass next way:

  1. User is identified in system and shows his private key.
  2. Client machine forms its request to the AS (AS_REQ) where it defines that the asymmetric encryprion will be used. This request is distinguished due to the fact, that it's signed with user's private key and contains besides standart information a certificate of user's public key.
  3. When a KDC has received a request, it first checks the certificate's genuineness, then a digital signature. Then the KDC checks local time sent in the request.
  4. When the KDC is ensured in client's authenticity, it forms an AS_REP in which the session key is encrypted through a user's public key. Moreover the response contains a certificate of KDC and is signed by its private key (like user's request).
  5. Having received the answer, the user verifies the KDC signature and decrypts his session key using his private one.

The further steps are implemented according to the standard description Kerberos V5.