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

[Chris Hecker]

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?

Thanks,
Chris


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
>
>
>