- 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 |
- 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 |
|
"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 |
|
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 |
|
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 |
|
END OF 3RD SCENARIO END OF 3RD SCENARIO END OF 3RD SCENARIO |