|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
MIME-Version: 1.0 In-Reply-To: <CAOdMLc0hikz40wEO54XcDkEjRYAJ102+oTb=Pj8Lo3EJ5+xXZg@mail.gmail.com> From: Chris Hecker <checker@d6.com> Date: Sat, 25 Nov 2017 16:25:00 -0800 Message-ID: <CAOdMLc3LBkdQQ7nBXajjret9pX9P6dRrvckV6RQzSTqBREXVSw@mail.gmail.com> To: Charles Hedrick <hedrick@rutgers.edu> Cc: "kerberos@mit.edu" <kerberos@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kerberos-bounces@mit.edu 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@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 > > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |