Computer Science
Computer Catlog
Cryptography Catlog

Caesar Cipher
Digital Signature
Public key cryptography
Symmetric vs. public-key
Key Management
Stream Ciphers
Self-Synchronizing Ciphers
Feedback Shift Registers
Modes of Operation
Multiple Encryption
Transposition Ciphers
Substitution Ciphers
Poly-alpha Substitutions
Poly-alpha Cipher Machine
Cryptanalysis Ciphers
Data Encryption Standard
DES Algorithm
IDEA Algorithm
RC5 Algorithm
RSA Encryption
Rabin Encryption
ElGamal Encryption
MD4 & MD5
Secure Hash Algorithm
Kerberos Authentication
Diffie-Hellman protocols
Key Management Life Cycle

Kerberos and related server-based protocols

    The key transport protocols discussed in this section are based on symmetric encryption, and involve two communicating parties, A and B, and a trusted server with which they share long-term pair wise secret keys a priori. In such protocols, the server either plays the role of a key distribution center (KDC) and itself supplies the session key, or serves as a key translation center (KTC), and makes a key chosen by one party available to the other, by re-encrypting (translating) it under a key shared with the latter.

Kerberos authentication protocol:

    Kerberos is the name given to all of the following: the distributed authentication service originating from MIT's Project Athena, which includes specifications for data integrity and encryption; the software which implements it, and the processes executing such software; and the specific authentication protocol used therein. Focus here, and use of the term "Kerberos", is restricted to the protocol itself, which supports both entity authentication and key establishment using symmetric techniques and a third party.

    The basic Kerberos protocol involves A (the client), B (the server and verifier), and a trusted server T (the Kerberos authentication server). At the outset A and B share no secret, while T shares a secret with each (e.g., a user password, transformed into a cryptographic key by an appropriate function). The primary objective is for B to verify A's identity; the establishment of a shared key is a side effect. Options include a final message providing mutual entity authentication and establishment of an additional secret shared by A and B (a subsection key not chosen by T).

    The protocol proceeds as follows. A request from T appropriate credentials (data items) to allow it to authenticate itself to B. T plays the role of a KDC, returning to A a session key encrypted for A and a ticket encrypted for B. The ticket, which A forwards on to B, contains the session key and A's identity; this allows authentication of A to B when accompanied by an appropriate message (the authenticator) created by A containing a timestamp recently encrypted under that session key.

Protocol Basic Kerberos authentication protocol:

    SUMMARY: A interacts with trusted server T and party B.

    RESULT: entity authentication of A to B (optionally mutual), with key establishment.

1. Notation. Optional items are denoted by an asterisk (*).

    E is a symmetric encryption algorithm.

    NA is a nonce chosen by A; TA is a timestamp from A's local clock.

    k is the session-key chosen by T , to be shared by A and B.

    L indicates a validity period (called the "lifetime").

2. One-time setup. A and T share a key KAT ; similarly, B and T share KBT. Define Ticket B def= EKBT (k,A,L); authenticator def = Ek (A, TA, A* subkey).

3. Protocol messages.

    A T : A,B,NA                                      (1)

    A T : ticket B ,EKAT (k, NA, L,B)             (2)

    A B: ticket B , authenticator                 (3)

    A B : Ek(TA,B* subkey)                         (4)

4. Protocol actions. Algorithm E includes a built-in integrity mechanism, and protocol failure results if any decryption yields an integrity check failure.

    (a) A generates a nonce NA and sends to T message (1).

    (b) T generates a new session key k, and defines a validity period (lifetime L) for the ticket, consisting of an ending time and optional starting time. T encrypts k, the received nonce, lifetime, and received identifier (B) using A's key. T also creates a ticket secured using B's key containing k, received identifier (A), and lifetime. T sends to A message (2).

     (c) A decrypts the non-ticket part of message (2) using KAT to recover: k, NA, lifetime L, and the identifier of the party for which the ticket was actually created. A verifies that this identifier and NA match those sent in message (1), and saves L for reference. A takes its own identifier and fresh timestamp TA, optionally generates a secret A subkey, and encrypts these using k to form the authenticator. A sends to B message (3).

    (d) B receives message (3), decrypts the ticket using KBT yielding k to allow decryption of the authenticator. B checks that:

        i. the identifier fields (A) in the ticket and authenticator match;

        ii. the timestamp TA in the authenticator is valid; and

        iii. B's local time is within the lifetime L specified in the ticket.

    If all checks pass, B declares authentication of A successful, and saves A subkey (if present) as required.

    (e) (Optionally for mutual entity authentication:) B constructs and sends to A message (4) containing A's timestamp from the authenticator (specifically excluding the identifier A, to distinguish it from the authenticator), encrypted using k. B optionally includes a subkey to allow negotiation of a subsession key.

    (f) (Optionally for mutual entity authentication:) A decrypts message (4). If the timestamp within matches that sent in message (3), A declares authentication of B successful and saves B subkey (if present) as required.

Security and options in Kerberos protocol

    (i) Since timestamps are used, the hosts on which this protocol runs must provide both secure and synchronized clocks.

    (ii) If, as is the case in actual implementations, the initial shared keys are password-derived, then the protocol is no more secure than the secrecy of such passwords or their resistance to password-guessing attacks.

    (iii) Optional parameters A subkey and B subkey allow transfer of a key (other than k) from A to B or vice-versa, or the computation of a combined key using some function f(A subkey, B subkey).

    (iv) The lifetime within the ticket is intended to allow A to re-use the ticket over a limited time period for multiple authentications to B without additional interaction with T , thus eliminating messages (1) and (2). For each such re-use, A creates a new authenticator with a fresh timestamp and the same session key k; the optional subkey field is of greater use in this case.