[5438] in Kerberos
Re: forwardable tickets
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Jun 29 18:21:13 1995
To: jkm@faron.mitre.org (Jonathan K. Millen)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "29 Jun 1995 14:00:49 GMT."
<3submh$222@linus.mitre.org>
Date: Thu, 29 Jun 1995 18:09:11 EDT
From: Sam Hartman <hartmans@MIT.EDU>
>>>>> "Jonathan" == Jonathan K Millen <jkm@faron.mitre.org> writes:
Jonathan> Could someone help me understand how Kerberos v5 handles
Jonathan> forwardable tickets? I've been looking at Kohl's
Jonathan> "Evolution of Kerberos..." paper and RFC 1510 but I'm
Jonathan> still confused.
Jonathan> Fist, when and how is a forwardable TGT issued? The AS
Jonathan> normally gives a non-forwardable TGT to the client for
Jonathan> the TGS. Is this the one that is marked fowardable if
Jonathan> the client requests it?
When a client makes a request to the AS, it can include
certain options with this request. One of these options is the
forwardable option. If the client requests a forwardable ticket and
if the AS policy allows the ticket to be forwarded, the AS returns a
ticket with the forwardable option set. For example, you can request
a forwardable ticket with the -f option to kinit in our
implementation.
Jonathan> Then, how is the forwardable TGT sent to the service
Jonathan> that will use it? Ordinarily a service gets a service
Jonathan> ticket that the client has requested from the TGT. Is
Jonathan> the forwardable TGT sent to the service as part of the
Jonathan> same message that sends it the service ticket?
The client must request a forwarded ticket from the TGS. It
presents the current TGT and requests the list of valid IP addresses
(well, addresses; they're generally IP) be modified. Normally, I
would adssume that the only valid address is the address of the
service where the ticket is being forwarded. The TGS returns a new
TGT, valid if used from the new address. This new TGT has the
forwarded option set; I believe that the client's TGS request controls
what other options are requested. Like all TGS replies, the session
key associated with the ticketis returned, encrypted in the old TGT
that was used to make the request.
So, the client now has the new TGT and the session key for the
new TGT. After authenticating through the normal procedure, the
client then sends the new TGT to the server; this can be done
cleartext as the ticket is only readable by the TGS. Then, the client
must send an encrypted copy of the new TGT's session key to the server
where the ticket is being forwarded. This can be done with a app_priv
message.
It isn't important to use Kerberos to make the ticket
exchange. Once I get the forwarded ticket and session key, I can use
any means to transfer the ticket and any secure means to transfer the
session key. Normally Kerberos is the most convenient mechanism.
