Subject: Re: [Ietf-krb-wg] Proxiable/forwardable question

From: "Lewis Adam-CAL022" <[email-masked]>
Date: Wed, 2 Jul 2008 09:23:12 -0400

> 
> It might help a lot if you give up on the hypothetical and 
> tell us what you're really trying to do.  There's a good 
> chance that there is a solution based on existing technology, 
> but it's hard to tell without knowing more about what's going on.
> 

Okay, so basically my situation is that I have a user which is going to
authenticate to a central server.  This central server will then alert
other application servers that the user is on-line.  So when the user
authenticates to the central server by sending it a Kerberos ticket, I
would like for that central server to forward the user's ticket to the
other (application) servers, and for the end result to be that the user
has a shared session key with each of those application servers. Is this
possible?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 02 Jul 2008 10:31:45 -0400

> has a shared session key with each of those application servers. Is this

Let me start by suggesting that you hold this discussion on
[email-masked] instead of on the IETF Kerberos WG mailing list.
[email-masked] is for questions regarding Kerberos deployments
whereas this mailing list is intended for discussions regarding the
development of Kerberos protocol standards.

Next I will suggest if you have not already done so read one or more
of the tutorials on Kerberos so that you have a better idea of how the
protocol actually works and what the roles of the participants are.
You can find some good introductory tutorials at

   http://web.mit.edu/kerberos/papers.html

In your environment you have client C, the KDC K, the Central Server CS,
and an application server AS.  When C wants to authenticate to CS it 
obtains a service ticket for CS from K using a previously obtained 
Ticket Granting Ticket for the user.  This ticket T is encrypted in a 
key that only CS knows and contains a session key that is known to C.
If CS can decrypt T it can obtain the session key and with it C and CS
can prove their identity to one another.

If C ever talks to AS directly then C would obtain a service ticket for 
AS from K.  There is no need for CS to send a session key to AS.  If CS 
is going to be communicating to AS on behalf of C, then C could 
"forward" a ticket to CS that CS can use to authenticate to AS as C.

Note that it is very unclear from your description what your intended 
communication flow is or what protocols are involved.

I have set followup-to [email-masked].

Jeffrey Altman