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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Chris Hecker
(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.

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

Thoughts?

Thanks!
Chris
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 11/17/2017 11:20 AM, Chris Hecker wrote:
> - 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.

It seems like a TGT would allow them the same access to other kerberized
services as the key would, though only for the lifetime of the TGT.

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

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.  krb5_mk_1cred() will package up a credential (ticket and
session key) and encrypt it using an auth context.

> - If this isn't going to work, what are my options here?

One potential building block is S4U2Self (aka "Protocol Transition"),
where a service can request a ticket from an arbitrary user to itself
after authenticating the user with a different auth protocol.  But I
don't think you could easily bootstrap from there to U2U communication
between the clients.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
In reply to this post by Chris Hecker
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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Charles Hedrick
In reply to this post by Greg Hudson
Another approach is kind of iffy from a security point of view, but I have a situation where it’s needed. We have code that will generate any credentials for which it has a keytab, including a TGT. (It’s an MIT person of kimpersonate.) You can transmit it to the other end using krb5_fwd_tgt_creds / krb5_rd_cred.




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: 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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>
>
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos