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

[Simo Sorce]

On Fri, 2017-11-17 at 15:49 -0500, Simo Sorce wrote:
> 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.
> 

Forgot to say:
Note hat AIs are also available to the service, so they allow for a
service-by-service transition if you later want to move authz to the
services themselves.

Simo.

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