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

[Simo Sorce]

On Fri, 2017-11-17 at 16:20 +0000, Chris Hecker wrote:
> (Once more, with feeling...and also hopefully acceptable-to-mailman
> formatting.)
> 
> This is all kind of half-baked, so bear with me while I think out-loud:
> 
> - I am using kerberos for my game's authn with clients and a server.
> Clients have connections to the server, and then also p2p connections to
> each other, and I use u2u tickets for those.  This all works swimmingly.  I
> <3 kerberos.
> 
> - I am now integrating a 3rd party authn system (Steam). This system also
> uses sessions and tickets and whatnot but they're not kerberos tickets, so
> I'm going to need to translate somehow, and I want this to all be seamless
> so a Steam user doesn't know they aren't a normal kerberos user (until they
> try something Steam doesn't support, but that's a different topic).
> 
> - I think what I want to do is when a Steam user connects to the server for
> the first time with a Steam ticket, I authenticate it with Steam, and then
> create a kerberos user for that Steam user. I don't want to require people
> to pick a username or password or anything, so I want to generate a unique
> krb username for this user <steamid>/steam or something (and I'll use princ
> aliases if they want to pick another name later), and then also generate a
> randkey.
> 
> This is where it gets interesting...
> 
> - I don't want to give them the key to their krb account because I don't
> want them to be able to log into any of my other kerberized services, so I
> think I'd like to request a TGT for them on the server and then send it to
> the client. This way they can install it and use it to get u2u tickets, or
> tickets to other services.

Is the client performing authentication ?
Are you using TLS or some other channel to talk to the server when you
do not have a kerberos credential ?

> - Can I just do this, and send the TGT to the client and have them install
> it with krb5_cc_store_cred? I do a similar thing with krb5_cc_retrieve_cred
> to get the tgt for u2u?  Does there have to be an AS request to establish a
> session key, or does there need to be a key installed on the client to use
> the TGT correctly?

If you are thinking of doing something similar to copying a ccache file
from the server to the client it should work, but a TGT would allow
this client to access any kerberized service.

If coarse authz is all you need, you could create a STEAM realm on your
steam auth server that is trusted by your main KDC. Service then can
refuse service to those user that are not in their realm.

You could even have the client do an initial login with a secret you
hand them as it would be a separate account.

> - If this isn't going to work, what are my options here? I'd like to keep
> everything except the initial login working with my current kerberos
> system, so I'd really like to get a Steam user a temporary kerberos ticket
> as early as possible so I don't have to handle many special cases. I'd like
> to avoid sending a full key to the client because they could then use that
> to log into my other kerberos services unless I implemented some kind of
> authz stuff that I'd like to avoid for now.

You'll have to do authz in some way. But you can handle it on the KDC
to a degree.

Using a separate realm gives you "coarse" authz at the service level
(you need to change services to deal with this, possibly also u2u is
difficult this way).

Or you would have to hand back specific service tickets only for the
services you want to allow and not a tgt. This may also not work with
u2u.

Or you would have to use something like Auth Indicators, when a
"regular" users logs in you would need to set an AI that says it is a
regular user, a steam user would get a "STEAM" indicator instead.
Then configure your TGS so that only krbtgts that have the regular Auth
Indicator can get tickets for the services you do not want to expose to
 STEAM users. Basically you can build a white/black list for steam
users in the TGS this way and control this access globally.

There are many options really, it all depends on the exact semantics
you need.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc