[30192] in Kerberos
Re: Kerboros explain
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Aug 4 12:20:09 2008
From: Ken Raeburn <raeburn@mit.edu>
To: kisito <momo_tene@yahoo.fr>
In-Reply-To: <18787840.post@talk.nabble.com>
Message-Id: <CBDD588E-62CD-4752-A247-3A36C5716C95@mit.edu>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Mon, 4 Aug 2008 12:19:31 -0400
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Aug 2, 2008, at 06:03, kisito wrote:
> In the operation of the Kerberos protocol, why Authentication
> Server , when
> delivering the TGT, does not directly issued the service ticket? (so
> I do
> not see why have complicated the protocol by introducing the TGS)
If you're going to contact a dozen services during your login session,
the TGT will let you get service tickets for them without asking for
your password over and over again.
Theoretically (if the protocol were set up for it) you could get them
all at once and prompt for the password only once, but that only works
if you know what all of them are when you log in; for a realm with
possibly thousands of servers, you can't practically get Kerberos
style credentials (dependent on shared secrets between the KDC and
each individual service, hence needing different credentials for each
service) for all of them at login time just in case you might want to
talk to them later. It also doesn't help in the cross-realm
authentication case, where you need credentials to send to some other
site's KDC, so it can issue you credentials to talk to one or more
services at that site; this is also done with a kind of TGT issued by
your "home" KDC.
The ticket-granting ticket model lets you transparently (we hope!) get
additional tickets as you need them during your session, without
having to decide up front.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
