- P R I M E R -
KERBEROS NETWORK COMPUTER SECURITY

(CONCEPTUAL OVERVIEW)

(greeklatinaudio.com   Austin TX September 2001)


This discussion is an obvious departure from the regular content theme of greeklatinaudio.com
Thus, an explanation is in order. Justification here is tenuous but discernible in at least 3 ways:

1. KERBEROS IS genuinely GREEK(!)
Il faut tout simplement se souvenir du fameux KerberoV le bon chien de l'enfer...

2. KERBEROS was born in the UNIX world.
How LATIN can U get? - UNIX: (fr. Latin) a female UNIT!  (For those of you who may not know, UNIX is a very famous and robust computer operating system. And KERBEROS is a computer security platform frequently used to protect networked UNIX systems.)

3. I work professionally as a computer security administrator...
And I see a very real need for a coherent presentation of KERBEROS security at the basic conceptual level.

Expanding on this last item...
The subject of KERBEROS security (at the introductory or basic conceptual level) is deplorably dealt with in available technical literature. ("tech-lit" in this narrative) I have personally NOT found anything (on the bookshelf, or the internet) which explains KERBEROS security such that the cold and hapless layman or the KERBEROS security newbie could understand. Thus, this explanation is proffered to those who would like to get around "le bon chien" of technical obfuscation - and get in the door...

For KERBEROS gurus who land on this site and read this, your criticisms and suggestions for enhancement are certainly encouraged and welcome!

jsimon@greeklatinaudio.com




- P R I M E R -
KERBEROS NETWORK COMPUTER SECURITY

(CONCEPTUAL OVERVIEW)

This overview is a consolidation and complete re-write of several conceptually insufficient and term-anemic "tech-lit" explanatory texts for KERBEROS basics which are found in current KERBEROS technical literature. For the benefit of those who wish to acquire a basic understanding of these matters, (without having to crawl on hands and knees over the usual "vomit" and "broken glass" of technical concept-obliteration) more precise and consistent terminology is incorporated in this overview, and more care is given to the formulation of related narrative context.



For the benefit of the reader, this material is presented in progressive sections. For easing the management of finding and referencing these sections, they are EACH frame-delineated for easy visual identification. These sections are:

TERMS LIST:
A glossary of precise terms used in this narrative.

"TECH-AXIOMS":
These are verbal concept "formulae" which focus on 3 key terms (from the TERMS LIST) presenting them in axiomatic context. (The meaning of "axiomatic context" will become clear when you encounter it in the second section.

EVENT SCENARIOS:
These are descriptions of actual KERBEROS event scenarios which will carefully incorportate the TERMS and "TECH-AXIOMS" established in this narrative to make clear WHAT HAPPENS when a user logs on to a system protected by KERBEROS, and requests a network computer service. These event scenarios are: (in the order that they appear)

- 1ST SCENARIO: OBTAINING A TGT FROM AS

- 2ND SCENARIO: USING THE TGT TO OBTAIN
  A NETWORK SERVICE TICKET FROM TGS

- 3RD SCENARIO: USING THE NETWORK SERVICE-TICKET
  TO OBTAIN A NETWORK SERVICE



A FREE WARM-FUZZY for the reader:
This narrative describes alot of moving pieces which contribute to KERBEROS network security. Simply bear in mind that this description of moving pieces, for the most part, (i.e., almost invariably) applies at the level of KERBEROS SOFTWARE. This means that the "user-human" does NOT really need to concern himself AT ALL with the technicalities of these matters. It's happening "under the covers" for the benefit of users of a KERBEROS-protected environment. Mercifully the "users-human" don't even know that it's happening.

Thus, for example, in item 7 of the "2ND SCENARIO" below, when you encounter text such as the following:

"7. The USER receives this TICKET-PACKET and decrypts it with his copy of the TGS SESSION-KEY-U (which he received from KERBEROS in the 1st scenario.) etc., etc."
...you needn't worry that YOU (the "USER") are doing this! This is KERBEROS "client" SOFTWARE doing this in your (the USER's) behalf!

see items "CLIENT" and "USER" from the TERMS LIST below for further clarification.




Regarding the TERMS LIST which follows:
The technical terms used in this document have been enhanced for conceptual clarity and will NOT likely be found in use elsewhere. These terms may appear cumbersome, but they are helpfully descriptive. The castrated, semantically conflicting terms normally used in KERBEROS tech-lit are included here merely for cross-referencing and compatibility with current field usage. They are simply tagged in this list to refer to their more precise term-counterparts used in this overview. (for an example of this, see tagged item 5. "KEY")


TERMS LIST
TERMS LIST
TERMS LIST

A.) COMMON KERBEROS ACRONYMS:
The short list of acronyms which follows is provided here because ANY explanation of KERBEROS (including this one!) throws these acronyms around abundantly. The reader must be familiar with them. Their meaning will be explained in the TECHNICAL TERMS list which immmediately follows.


      - AS:       AUTHENTICATION-SERVICE

      - KDC:    KEY-DISTRIBUTION-CENTER

      - KDS:     KEY-DISTRIBUTION-SERVICE

      - TGS:     TICKET-GRANTING-SERVICE

      - TGT:     TICKET-GRANTING-TICKET


B.) TECHNICAL TERMS:

1. AUTHENTICATION SERVICE   (AS)

see KERBEROS


2. AUTHENTICATOR (weak term)

see instead: SERVICE-TICKET-AUTHENTICATOR   and  TGT-AUTHENTICATOR


3. CLIENT (used interchangeably with USER) quod vide

This term is loose and ambiguous in KERBEROS literature. A CLIENT may be the "user-human" AND/OR the logically-connected "client" software that acts as a buffer between the user-human and KERBEROS, or between the user-human and the SERVICE which he (the user-human) is talking to.

In this narrative, feel free to interpret this term in the manner which most closely fits the context. NOTE however, that in MOST cases, this will refer to "client" software.


4. KERBEROS

An open computer network security system designed at M.I.T. and named after the 3-headed dog which, in Greek mythology, guards the gates of Hell.    (In passing, one might ask, "Who, in his right mind, would want to circumvent KERBEROS and get into hell, anyway?!")

In any case...
THE KERBEROS SECURITY SYSTEM IS THE SUBJECT OF THIS NARRATIVE OVERVIEW.

KERBEROS CONSISTS OF TWO MAIN COMPONENTS:

1. AUTHENTICATION-SERVICE  (AS)   think: "KERBEROS/AS"
The USER-authenticating portion of KERBEROS which is activated at USER logon time. AS validates (authenticates) USERs by means of their respective registered USER-KEYs. Upon successful USER validation, AS issues TGTs.

2. TICKET-GRANTING-SERVICE  (TGS)   think: "KERBEROS/TGS"
The ticket-granting portion of KERBEROS. USER presents TGT (obtained from AS) to TGS in order to obtain subsequent specific SERVICE-TICKETs.


5. KEY (weak term)

see instead: SERVICE-KEY,   SESSION-KEY,   USER-KEY

Want a key monsieur? Pick one!: apartment key, skeleton key, ignition key, key to my heart, key to your heart, ACE key, piano key, saxophone key, misspelled quay, qui, kee(wee), brass key, master key, etc. ad infinitum key-tum...

Standard KERBEROS literature speaks loosely and imprecisely of KEYs. (Thank you...) There are, in fact, three keys (mentioned above, and defined in this list) which occur in a KERBEROS environment, each of which has a distinct function. (Imagine if you will, dear reader, the confusion and aggravating inadvertant concept-overlap which ensues when an explanation of KERBEROS KEY activity (which is fairly intense) is undertaken, and these distinctly different KEYs are ALL simply called KEYs!

(see individual entries for these KEYS)


6. KEY-DISTRIBUTION-SERVICE  (KDS)  (misnomer)
    aka: KEY-DISTRIBUTION-CENTER:   (KDC)   (misnomer)

KERBEROS explanatory literature uses both of the above terms interchangeably - and probably has a few dozen other variations of the term tucked away at convenient and surprising locations - for the sole purpose of obfuscating hapless fuscates...

HOWEVER...
PLEASE NOTE THAT KDS (or KDC) IS GENERALLY REGARDED AS KERBEROS HIMSELF!
  (Much of KERBEROS documentation written by KERBEROS "gurus" acknowledges that KDS (or KDC) is KERBEROS. Thus, although this equation is undoubtedly debatable in many quarters, it is pervasive enough in KERBEROS literature to be accepted and used in this overview.)

More about the KDS/KDC misnomers...
Altho KERBEROS does distribute keys, note that his raison d'etre is NOT key distribution. Furthermore, of the 3 kinds of keys encountered in a KERBEROS system, KERBEROS actually "distributes" only ONE of these: the SESSION-KEY. The other two kinds of keys (USER-KEY and SERVICE-KEY) are not "distributed" at all due to the security threat that such action would introduce; and KERBEROS takes great pains to see that these KEYS are NOT distributed! (See the definitions for these KEYs.)

Furthermore, the principle focus-item which IS "distributed" over a KERBEROS-guarded system is a SERVICE-TICKET - NOT A KEY! And a SERVICE-TICKET's accompanying key (SESSION-KEY) is only an "adjunct" part of the SERVICE-TICKET distribution process: The key is intended to "secure" or "validate" the ticket, but the ticket remains the principle focus-item being distributed.

relevant analogy...
A passenger transport system (e.g., railroad) transports passengers. The passengers must have tickets to use the system. However, tickets are only an "adjunct" part of the transport process. Passengers are the focus here - NOT tickets! (If tickets were the focus, then railroad services could eliminate all sorts of costly niceties which are designed exclusively for passengers, e.g., sleeper cars, diner cars, kitchen cars, bathrooms, air-conditioning, etc...(tickets don't need these niceties!)) Thus, we DO NOT normally refer to such a system as a ticket transport system. Such terminology mistakenly shifts the conceptual focus from passengers to tickets. In the same manner; the term KDS (or KDC) mistakenly shifts the conceptual focus from tickets to keys in a KERBEROS system!

In view of this, "TDS" (TICKET-DISTRIBUTION-SERVICE) might be a more precise term instead of KDS. (or KDC) BUT, TDS is still a term which is lacking in implications because KERBEROS does much more than distribute tickets. He is, after all, a system security "watchdog" whose responsibilities are quite extensive.

Therefore...
Why not simply call him KERBEROS.  (What a novel idea!)

With the above in mind, the terms and abbreviations: KEY-DISTRIBUTION-SERVICE,  KDS,  KEY-DISTRIBUTION-CENTER,  KDC,  are NOT used in this narrative. The term KERBEROS is used instead to replace them all.

see KERBEROS


7. kinit

A work station (local) KERBEROS client piece of software that talks to the USER and AS at logon . This term is included here because it occurs frequently in KERBEROS literature, however, it is not used in this narrative.


8. PRINCIPAL
One of the players or entities using (or found in) a KERBEROS-secured network environment. For all practical purposes, the only PRINCIPALs which we must be concerned with here are:

- KERBEROS himself
- the USERs
- network SERVICEs (e.g., mail SERVICE,  print SERVICE,  etc., including the KERBEROS services, AS and TGS, i.e., "KERBEROS himself." )

see also SESSION


9. "replaying a ticket"  (i.e., replaying a SERVICE-TICKET)

Using a SERVICE-TICKET illegally, e.g., SERVICE-TICKET usage by an unauthorized USER. KERBEROS design is intended to prevent this by means of the SERVICE-TICKET-AUTHENTICATOR quod vide.


10. SERVICE (generic concept)

Many SERVICES are provided by a network. e.g., print SERVICE,  file SERVICE,  mail SERVICE, etc. (Including KERBEROS security services: e.g., AS and TGS) In order to use a network SERVICE, the USER must first have a TICKET for that SERVICE, i.e., a SERVICE-TICKET.


11. SERVICE-KEY

NOTE: Pay attention to the subtle but significant difference between...
- SERVICE-KEY and...
- SESSION-KEY quod vide

A SERVICE-KEY is a unique key associated with each SERVICE. (Conceptually, a SERVICE-KEY is a SERVICE's encrypted password registered with KERBEROS) Each SERVICE has such a unique key (password) known only by the SERVICE and KERBEROS. The SERVICE-KEY functions in the same manner for its respective SERVICE as the USER-KEY functions for its respective USER. Thus, each SERVICE (e.g., mail SERVICE, print SERVICE, etc., has a SERVICE-KEY which only it (the SERVICE) and KERBEROS know.

e.g.,
- AS has his own SERVICE-KEY ("password")
- TGS has his own SERVICE-KEY ("password")
- a network's mail SERVICE has his own SERVICE-KEY ("password")
- a network's print SERVICE has his own SERVICE-KEY ("password")
- etc.

Note that "password" here is not really a password in the same manner that USER-KEY is a password. i.e., a SERVICE cannot "select" a password like a USER can. So KERBEROS builds and manages a unique digitally-recognized registered SERVICE-KEY (a "password," if you will) for each SERVICE in its domain.


12. SERVICE-TICKET

A ticket issued by KERBEROS for a network SERVICE, e.g., a ticket for mail SERVICE, a ticket for print SERVICE, etc.

Important: Note that a TGT is also a SERVICE-TICKET, i.e., a ticket for TICKET-GRANTING-SERVICE.

SERVICE-TICKETs are ALWAYS accompanied by, and associated with a SESSION-KEY.

see TGT, SESSION-KEY


13. SERVICE-TICKET-AUTHENTICATOR

see also TGT-AUTHENTICATOR

A short-lived time-stamp vector built by USER's client sofware which accompanies and authenticates each SERVICE-TICKET by identifying its sending work-station and comparing it with the work-station identity of the SERVICE-TICKET requestor.

There is a one-for-one correspondence between a SERVICE-TICKET-AUTHENTICATOR and a SERVICE-TICKET, i.e., A SERVICE-TICKET-AUTHENTICATOR cannot live without a SERVICE-TICKET and vice versa.

SERVICE-TICKET-AUTHENTICATOR has a common life span of minutes (e.g., 5 minutes) to prevent illegal "replaying of SERVICE-TICKETs."


14. SESSION (loose concept)

A dialog between PRINCIPALs in a KERBEROS-protected network environment.

examples of PRINCIPALs within SESSIONs:

- USER dialog in session with AS (to get a TGT)
- USER dialog in session with TGS (to get a SERVICE-TICKET, e.g., a mail SERVICE-TICKET)
- USER dialog in session with requested service (to get a requested service(!) ) etc.


15. SESSION-KEY

NOTE: Pay attention to the subtle but significant difference between...
- SESSION-KEY and...
- SERVICE-KEY quod vide

A SESSION-KEY is a unique key randomly-generated in duplicate by KERBEROS and associated with each new session initiated between a USER and a SERVICE. The SESSION-KEY thus becomes a sort of digital "secret" which the USER and the SERVICE "share" and by which they can authenticate themselves to one another. Therefore, one copy of a duplicated SESSION-KEY is intended for the USER. The other copy of a duplicated SESSION-KEY is intended for the SERVICE which the USER is targeting.

Because these SESSION-KEYs are always generated in duplicate, this narrative distinguishes (when necessary) between the two identical copies as follows:

- SESSION-KEY-U   USER's copy
- SESSION-KEY-S   SERVICE's copy

Note carefully that within any given SERVICE-TICKET, KERBEROS embeds a corresponding SESSION-KEY-S , and encrypts the whole thing (SERVICE-TICKET and embedded SESSION-KEY-S ) with the SERVICE-KEY of the target service.


16. TGT  ("Ticket-Granting Ticket")

TGT is the initial "admission ticket" provided for USER by AS, generally at logon. TGTs allow USERs to obtain subsequent specifically requested SERVICE TICKETS for desired network SERVICEs, e.g., print SERVICE, mail SERVICE, KERBEROS SERVICE, etc.

Important:  TGT is itself a SERVICE-TICKET. i.e., a "TGS SERVICE-TICKET."  However, this name is redundant, so TGT will be used throughout this narrative.

The basic differences between a TGT and a typical SERVICE-TICKET follow:

- TGT is issued by AS and is used to petition TGS for SERVICE-TICKETs
- SERVICE-TICKETs are used to petition network services for services(!) e.g., a print SERVICE-TICKET is used to petition network print service for (you guessed it!) print service!

trivium:
Granting a TGT is one of the initial functions which AS performs automatically on behalf of USERs logging on. Without a TGT, a USER cannot play. TGT is roughly comparable to a temporary security badge issued to visitors at a secured site. Once visitors are on-site, (with security badge displayed) they then have access to common site facilities. (vending machines, bathrooms, cafeterias, etc...)


17. TGT-AUTHENTICATOR

A TGT-AUTHENTICATOR is a SERVICE-TICKET-AUTHENTICATOR for a TGT, which is (you recall) a SERVICE-TICKET for TGS.

see SERVICE-TICKET-AUTHENTICATOR


18. TICKET (weak term)

see instead, SERVICE-TICKET

Want a ticket?: ticket to the game, ticket to the show, ticket to the club, traffic ticket, ticket to ride, ticket to the funny farm, ad infinitum ticket-tum

NOTE THAT THERE IS ONLY ONE KIND OF TICKET IN A KERBEROS ENVIROMENT, AND THAT IS A SERVICE-TICKET, quod vide.


19. TICKET-GRANTING SERVICE  (TGS)

see KERBEROS


20. TICKET-PACKET (a subtle and sometimes-required KERBEROS "filler" concept.)

Some KERBEROS literature uses this concept - some does not - depending upon what's being discussed and who's discussing it.

Thus, for the record:
The term "TICKET-PACKET," is a KERBEROS "transport-vehicle-container/wrapper" concept. This simply implies that when KERBEROS is shipping stuff all over the place, he ships it all as related components which are conceptually "wrapped" as transport "entities." (or "packets")  A packet of security components may consist of SERVICE-TICKETs,  KEYs,  AUTHENTICATORs,  and whatever else is required to make things work. These components may frequently be thought of as "wrapped" or "packaged" (because they travel together) hence the "packet" concept. (Kind of like putting a fence around a herd of rabid pigs...for conceptual peace of mind, of course...)

Some KERBEROS literature speaks of this "wrapped" entity directly and calls it by some conceptual name (most frequent of which is TICKET-PACKET). Other literature does not directly speak of the matter as such but implies that it is going on. Some explanations of KERBEROS don't "work" if this "wrapper" concept is NOT taken into consideration.

A TICKET-PACKET may be regarded as a single "traveling party" like Dad, Mom and the kids. The contents of a TICKET-PACKET are variable, depending upon which network services the TICKET-PACKET is requesting.

NOTE: A TICKET-PACKET is NOT a TICKET. However, it CONTAINS a TICKET.

This TICKET-PACKET concept is roughly analogous to a DROP of water (molecules) "wrapped" in a thin molecular "film" ("wrapper") which is invisible - but which physicists assure us is there - AND which (!) needn't be accounted for in most cases. i.e., one need not peel drops of water before drinking them...


21. USER (used interchangeably with CLIENT) quode vide

This term is loose and ambiguous in KERBEROS literature. A USER may be the user-human AND/OR the logically-connected "client" software that acts as a buffer between the user-human and KERBEROS, or between the user-human and the SERVICE which he (the user-human) is talking to.

In this narrative, feel free to interpret this term in the manner which most closely fits the context. NOTE however, that in MOST cases, this will refer to "client" software.



22. USER-KEY

Encrypted USER password registered with KERBEROS - known only by USER and KERBEROS



END OF TERMS LIST
END OF TERMS LIST
END OF TERMS LIST



Now that the preceding TERMS LIST for describing KERBEROS concepts has been provided, the following list of "TECH-AXIOMS" will prove helpful in NARROWING the focus of actual KERBEROS activity to three central protagonists - honored members of the above TERMS LIST:

To wit...
If one could observe with bit-and-byte cyber-granularity the goings-on of a KERBEROS environment, three entities would constantly appear as omnipresent slap-stick players running all over the place like the "Keystone Kops," riding comfortably in TICKET-PACKETS, of course...

These entities are the following, AND they are hereinafter color-coded as:

1. SERVICE-TICKET
2. SERVICE-TICKET-AUTHENTICATOR
3. SESSION-KEY

Remember: A TGT is a special SERVICE-TICKET and therefore, will be so color-coded.
Remember: A TGT-AUTHENTICATOR is a special SERVICE-TICKET-AUTHENTICATOR and therefore, will be so color-coded. Please review the TERMS LIST if these equations are not clear.

In our continuing narrative, the above terms will remain color-coded as indicated for clarity of reference and focus.


"TECH-AXIOMS
"TECH-AXIOMS
"TECH-AXIOMS

The following "TECH-AXIOMS" are BASIC CONCEPTS, which hover specifically around our three color-coded terms:

These "TECH-AXIOMS" will present themselves again and again in the final KERBEROS EVENT SCENARIOS section. Thus, becoming familiar with them at this point will prove beneficial.


axiom-1.  A TGT is also a SERVICE-TICKET.
Thus, there is also a corresponding TGT-AUTHENTICATOR.


axiom-2.  KERBEROS ALWAYS generates SESSION-KEYs IN DUPLICATE:

- One for the USER:  SESSION-KEY-U
- One for the SERVICE:   SESSION-KEY-S

SESSION-KEYs are used by clients and services to encrypt and decrypt SERVICE-TICKETs  and SERVICE-TICKET-AUTHENTICATORs.


axiom-3.  SERVICE-TICKETs,   SESSION-KEYs,   and SERVICE-TICKET-AUTHENTICATORs   are very closely corresponding entities, and may be regarded as the "travelling trinity" of a KERBEROS security system.

More specifically...
SERVICE-TICKETs  and SESSION-KEYs  ALWAYS travel together.

But...
When coming from the USER's workstation,  SERVICE-TICKETs  and SESSION-KEYs   are ALWAYS accompanied by a   SERVICE-TICKET-AUTHENTICATOR.


axiom-4.  SESSION-KEYs   are required by USERs and SERVICEs to access authentic SERVICE-TICKETs.

AND... such tickets (from a USER) are "authentic" only if they have an accompanying SERVICE-TICKET-AUTHENTICATOR.


axiom-5.  REMEMBER THAT THERE ARE CONCEPTUALLY TWO (2) KINDS OF SERVICE-TICKETs

a.) A TGT  (i.e., an initial SERVICE-TICKET  granted by AS.)

The TGT is essentially a required "admission" ticket if one wants to play with KERBEROS TICKET GRANTING SERVICE. (TGS) Altho the TGT is granted by AS, it is intended to be presented to TGS for subsequently required SERVICE-TICKETs.

b.) A common SERVICE-TICKET

A generic term always implying a more specific SERVICE-TICKET,  such as... print SERVICE-TICKET,   mail SERVICE-TICKET,   file SERVICE-TICKET, etc. (and, of course, a TGT )


axiom-6. SERVICE-TICKET-AUTHENTICATORs are short-lived (c. 5 minutes) time-stamped authenticators for SERVICE-TICKETs.

They are built by client software and sent to services along with SERVICE-TICKETs.  They are intended to prevent unauthorized "replaying of a ticket."



END OF "TECH-AXIOMS
END OF "TECH-AXIOMS
END OF "TECH-AXIOMS




THE FOLLOWING SECTIONS DESCRIBE THREE TYPICAL KERBEROS AUTHENTICATION EVENT SCENARIOS USING THE ABOVE TERMS AND CONCEPTS.

These scenarios are presented one-at-a-time in the order that they must occur as the USER logs on to the system and interfaces with the system's mail SERVICE to get (you guessed it!) his mail.

These scenarios are:

1. OBTAINING A TGT FROM AS
(Always the 1st item of order in a "kerberized" network.)

2. USING THE TGT TO OBTAIN A NETWORK SERVICE-TICKET FROM TGS
(The object, of course, for obtaining a SERVICE-TICKET is to be able to request subsequent network SERVICE, e.g., print SERVICE, mail SERVICE, etc. (Obtaining a network SERVICE-TICKET  is predicated upon previously obtaining a TGT )

3. USING THE NETWORK SERVICE-TICKET  TO OBTAIN A NETWORK SERVICE
In our example scenario to follow, our target NETWORK SERVICE will be mail SERVICE. Obtaining a NETWORK SERVICE is predicated upon previously obtaining a network SERVICE-TICKET..


REMEMBER!
These scenarios are progressively dependent upon one another, i.e., one cannot get a network SERVICE-TICKET  without a TGT, and one cannot get a network SERVICE without a network SERVICE-TICKET.. (This basic and generic principal (regarding correct sequence-of-service protocol) was immortalized by Seseme Street star, Earnie, c.1984, who said,

"In order to get a cookie, you must [first] lift the lid [of the cookie jar]." (Thank you Earnie!)



IMPORTANT NOTE: The following scenarios presume that our user-human has already been appropriately REGISTERED with KERBEROS.

For example...
When a person joins a company, this entails, among very many other administrative procedures, acquiring a userid so that he can logon to the company's system.

To do this, the newly-hired person must follow some company-prescribed protocol, e.g., fill out a form and send it (or email it) to an administrative group who will register him with KERBEROS such that he will end up with a userid known to (registered with) KERBEROS. This userid will have a password associated with it, which will ultimately be of the person's choosing. The password may subsequently be changed by the person, or KERBEROS administration, at any time. The password is encrypted and is, in fact, the person's USER-KEY.

THUS, ASSUMING THAT THE ADMINISTRATIVE GROUP HAS PERFORMED ITS EMPLOYEE REGISTRATION FUNCTIONS CORRECTLY, THE NEWLY-HIRED PERSON (USER) IS NOW ABLE TO LOGON WITH A VALIDATED USERID AND DO WORK.





1ST SCENARIO: OBTAINING A TGT FROM AS
1ST SCENARIO: OBTAINING A TGT FROM AS
1ST SCENARIO: OBTAINING A TGT FROM AS



1. USER logs on to system using his KERBEROS-registered userid.
Logon protocol automatically initiates dialog with AS to confirm registered userid authenticity. (USER is NOT prompted for password at this time.) Because AS is talking to USER, he presumes a request for a TGT . (Remember that a TGT is a variation of a SERVICE-TICKET, i.e., a SERVICE-TICKET for TGS which the USER must have if he is to do any meaningful work.


2. AS generates a TGT as well as a random TGS SESSION-KEY in duplicate.
One of the duplicate TGS SESSION-KEYs is intended for verification by TGS later. This is, of course, the TGS SESSION-KEY-S and it is embedded within the TGT and encrypted with the unique registered TGS SERVICE-KEY. The other duplicate TGS SESSION-KEY (i.e., TGS SESSION-KEY-U) is intended for the USER when he communicates with TGS.


3. AS packages these items as a TICKET-PACKET and encrypts the whole thing with the USER's USER-KEY.  KERBEROS then sends the TICKET-PACKET to the USER.


4. The USER receives the TICKET-PACKET and is prompted for his password.
If the correct password is given, then the TICKET-PACKET is successfully decrypted for the USER. (Note that, by this means, the password stays at the USER's workstation and is not floating around the sytem in clear text.) Successful decryption of the TICKET-PACKET authenticates the USER who thereby obtains the following:

a.) An authenticated TGT with an embedded TGS SESSION-KEY-S
      ALL of which is STILL encrypted with the TGS SERVICE-KEY)

     and...
b.) His (USER's) TGS SESSION-KEY-U


With an authenticated TGT and a TGS SESSION-KEY-U the USER is now able to request subsequent network SERVICE TICKETs from TGS, as needed.

Remember: At this point, the TGT has an embedded TGS SESSION-KEY-S for TGS - AND this TGT with its embedded TGS SESSION-KEY-S is STILL encrypted with the TGS SERVICE-KEY. Therefore, USER cannot read the TGT. HE must "blindly" pass it to TGS.

END OF 1ST SCENARIO
END OF 1ST SCENARIO
END OF 1ST SCENARIO





2ND SCENARIO: USING THE TGT TO OBTAIN A NETWORK SERVICE TICKET FROM TGS
2ND SCENARIO: USING THE TGT TO OBTAIN A NETWORK SERVICE TICKET FROM TGS
2ND SCENARIO: USING THE TGT TO OBTAIN A NETWORK SERVICE TICKET FROM TGS


NOTE: This scenario presumes that the USER has successfully participated in the 1ST SCENARIO described above and, therefore, has the following necessary items: (output from 1ST SCENARIO)

- an authenticated TGT with an embedded TGS SESSION-KEY-S
  all of which is still encrypted with TGS SERVICE-KEY)

  and...
- his (USER's) TGS SESSION-KEY-U

ORDER OF BUSINESS: THE USER WANTS TO READ HIS MAIL.)
Hence, the NETWORK SERVICE-TICKET. that we are after is the mail SERVICE-TICKET.


1. USER activates his mail SERVICE client.
USER's mail SERVICE client knows that it must now petition mail SERVICE using a mail SERVICE-TICKET. Therefore, client looks for a mail SERVICE-TICKET and does NOT find one. (Sacre Bleu!)


2. In the absence of a mail SERVICE-TICKET, the client grabs the encrypted TGT (which is a TGS SERVICE-TICKET you recall) and builds a TGT-AUTHENTICATOR, (which is a TGS SERVICE-TICKET-AUTHENTICATOR you recall!), encrypting it with USER's copy of TGS SESSION-KEY-U.


Client now sends this stuff to TGS to request a mail SERVICE-TICKET.


3. TGS receives this stuff and does the following:

- decrypts the TGT (and embedded copy of TGS SESSION-KEY-S ) using TGS SERVICE-KEY.
  By doing this, TGS obtains the TGS SESSION-KEY-S

  and...
- decrypts TGT-AUTHENTICATOR using his newly obtained TGS SESSION-KEY-S

NOTE: SUCCESSFUL DECRYPTION OF THESE ITEMS MEANS THAT THE "PRINCIPALS" INVOLVED HERE ARE NOW MUTUALLY AUTHENTICATED. Therefore...


4. TGS proceeds to prepare the following:

- the requested mail SERVICE-TICKET

  and...
- a new mail service SESSION-KEY
  (in duplicate, of course (one for the USER and one for the SERVICE))


Remember that KERBEROS embeds the mail service's copy of the mail service SESSION-KEY (i.e., the mail service SESSION-KEY-S ) in the mail SERVICE-TICKET and encrypts the whole thing with the mail service's registered SERVICE-KEY.


5.Then, KERBEROS creates a transport TICKET-PACKET containing:

- the requested mail SERVICE-TICKET with embedded mail service SESSION-KEY-S
  (ALL of this encrypted with mail service's registered SERVICE-KEY)

  and...
- The USER's mail service SESSION-KEY-U


6. KERBEROS then encrypts this TICKET-PACKET with his copy of the TGS SESSION-KEY-S (which he generated in the 1ST SCENARIO) and sends it off to the USER.


7. The USER receives this TICKET-PACKET and decrypts it with his copy of the TGS SESSION-KEY-U. (which he received from KERBEROS in the 1ST SCENARIO.) The USER thus obtains the following two items so that he may proceed with his request for mail SERVICE.

a. His mail SERVICE-TICKET (with embedded mail service SESSION-KEY-S )
   all of this still encrypted with mail service's registered SERVICE-KEY.

  and...
b. His mail service SESSION-KEY-U


NOTE:
At this point, the USER has two (2) valid SERVICE-TICKETs and two (2) corresponding valid SESSION-KEYs which he may continue to use for several hours. These are:

a.) A TGT (which has embedded TGS SESSION-KEY-S )
    and a corresponding TGS SESSION-KEY-U.

b.) A mail SERVICE-TICKET (which has an embedded mail service SESSION-KEY-S )
    and a corresponding mail service SESSION-KEY-U

END OF 2ND SCENARIO
END OF 2ND SCENARIO
END OF 2ND SCENARIO





3RD SCENARIO: USING THE NETWORK SERVICE-TICKET TO OBTAIN A NETWORK SERVICE
3RD SCENARIO: USING THE NETWORK SERVICE-TICKET TO OBTAIN A NETWORK SERVICE
3RD SCENARIO: USING THE NETWORK SERVICE-TICKET TO OBTAIN A NETWORK SERVICE

NOTE: This scenario presumes that the USER has successfully participated in the 2ND SCENARIO described above and, therefore, has the following necessary items: (output from the 2ND SCENARIO)

- an authenticated mail SERVICE-TICKET with an embedded mail service SESSION-KEY-S
  all of which is still encrypted with mail SERVICE-KEY

  and...
- his (USER's) mail service SESSION-KEY-U


1. The USER STILL wants his mail (!) He activates his mail client. His mail client knows that it must petition mail SERVICE using a mail SERVICE-TICKET. Therefore, the mail client looks for a mail SERVICE-TICKET. and finds one...

Merveilleus, comme c'est tout magnifique, le monde cybernetique entier!

------------------------
At this point, note the subtle cross-session connections: In this, the 3RD SCENARIO, the mail SERVICE-TICKET (obtained from TGS in the 2ND SCENARIO) was encased in a TICKET-PACKET encrypted with the TGS SESSION-KEY-S generated in the 1ST SCENARIO ) (!)


2. USER now grabs the authenticated mail SERVICE-TICKET and builds a mail SERVICE-TICKET-AUTHENTICATOR encrypting it with his copy of the mail service SESSION-KEY-U. USER sends this stuff to network mail SERVICE.


3. mail SERVICE receives this stuff and does the following:

- decrypts the mail SERVICE-TICKET
  (and its embedded copy of the mail service SESSION-KEY-S )
  using his registered mail service SERVICE-KEY

- decrypts the mail SERVICE-TICKET-AUTHENTICATOR
  using his newly obtained copy of the mail service SESSION-KEY-S

NOTE: Successful decryption of these items means that everybody involved is mutually authenticated. Therefore, the USER's coveted goal of obtaining mail service from network mail SERVICE is granted: THE USER GETS HIS MAIL !

---------------------
EPILOGUE: After all of this technical travail, the USER's mail turns out to be a ton of spam, a pile of e-bills and a stack of Dear-John letters from various online dating services...

USER ambles off into the sunset dejected and suicidal...destined for yet another (and FINAL) encounter with KerberoV as he gets sucked kicking and screaming into the abysmal trenches of TartaroV...


END OF 3RD SCENARIO
END OF 3RD SCENARIO
END OF 3RD SCENARIO



- FINIS KERBEROS CONCEPTS -


FAQ