[Ietf-krb-wg] Proxiable/forwardable question

[Jeffrey Altman]

Lewis Adam-CAL022 wrote:
>  
>> 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?

Let me start by suggesting that you hold this discussion on
kerberos at mit.edu instead of on the IETF Kerberos WG mailing list.
kerberos at mit.edu 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 kerberos at mit.edu.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080702/b0ae81dd/attachment.bin