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

Chris Hecker checker at d6.com
Sat Nov 25 19:25:00 EST 2017

Oh, and to actually send the key back, I assume I can just pack up the
keyblock and send that encrypted with mk_priv, there's no mk_1cred
equivalent for sending a key it seems?


On Sat, Nov 25, 2017 at 4:23 PM, Chris Hecker <checker at d6.com> wrote:

> 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

More information about the Kerberos mailing list