temporarily granting a TGT for a client coming in with a 3rd party authn system

[Chris Hecker]

Okay, I think I have a handle on this...a few responses and then a few
questions:

simo and greg:

> but a TGT would allow  this client to access any kerberized service.
>

Yeah, I realized this, and then I realized that for my use case even a full
key instead of a ticket would be okay to send, because the service I
currently want to protect against these steam clients logging into is a
CoSign SSO protected website and they'd need a password anyway for that (as
far as I know there's no way to use a krb5 key/tgt to directly log into
CoSign, I should probably check that with the CoSign people...), so I think
I can just send whatever randkey I use to create the kerberos account back
to the client, because they wouldn't be able to do anything with it anyway
for the SSO. I don't expose the changepw service or anything else, so I
think this is safe. Sending a key would be better for load, which I'm
worried about on launch, because then the client doesn't have to keep
asking my steamlogin service for tickets.

simo:

> You'll have to do authz in some way.
>

Yeah, I came to this realization myself, and I think for now I'm going to
just use the /steam part of the princ name for that because that's simple
and I know it works throughout my system (I use /test accounts). Once I get
a bit more experience here I'll figure out if there's a better solution.
Thanks for pointing out the Auth Indicators, those look like they may be
useful.

greg:

> The client needs the session key of the ticket in order to use it.  You
> can transmit that as well, but will need to do so over an encrypted
> channel.
>

I am going to have the client create send/recv subkeys for the auth context
and send those with their initial encrypted Steam app ticket (which as a
payload it can encrypt), so I should be able to create an encrypted
auth_con with those for sending the key back. Somebody could hack the
client to send bad subkeys but if they want the key they can just inspect
it in memory so this doesn't impact security beyond that single client as
far as I can tell.

Should I bother creating send/recv subkeys, or just a single useruser key
for this transmission?  It's basically a one time thing, sending to the
login service so it can send the key back over the encrypted channel. Is
there any advantage to sending two keys instead of one?

Thanks,
Chris