Replying to myself... > I have a single service using a unique service key, can I use the > memory replay cache safely?
Hmm, it looks like there is no memory replay cache type in MIT kerberos. I was confused by some old Sun/IBM docs that are online that describe a memory replay cache type. In this post, Greg sez: > Your protocol may not need a replay cache (basically, if > the client and the server both contribute fresh elements to each > exchange), in which case "none" may be appropriate. http://mailman.mit.edu/pipermail/kerberos/2010-March/015996.html I'm just wondering what exactly "contribute fresh elements" means concretely... Chris On 2011/07/14 18:57, Chris Hecker wrote: > > Hi, I'm planning on using Kerberos for my video game, and so I am > probably using it slightly differently than most installations, and I > want to make sure I'm doing the right thing security-wise, and making > any changes in the right places. Here are some random questions I have > related to this: > > 1. I'd like to specify the profile information via code directly in the > clients, rather than loading it from a file. In other words, I'd like to > simply set the default_realm, the kdc, and whatnot dynamically from > code. Looking through the prof_* code, it looks like the loading/parsing > stuff is pretty file-dependent, and there's a lot of it. It seems like > the best approach would be to modify the NULL profile_init code to > trigger in my case (currently it's in an ifdef for KRB5_DNS_LOOKUP) in > os_init_paths, and then find some way to hook in and manually stuff the > necessary profile variables in with prof_add_relation before kerberos > needs them. I'd rather do this than something horrible like write out a > tmp file and then read it back in. Is there a recommended way to do this > kind of hook? I'm happy to contribute the patch back, of course. > > 2. I was hoping to make versions of mk_priv and mk_safe that use already > allocated buffers, but this seems like it'd be a pretty huge change and > there's a lot more memory allocation in those functions than just the > output buffer, so it's probably not worth it. I assume there's not much > demand for a version of kerberos that doesn't allocate memory (once > session is established)? > > By the way, krb5_mk_safe seems to free outbuf in a couple branches > towards the bottom of the function, even though the examples all pass a > pointer to the stack for that parameter. Shouldn't those free's be > krb5_free_data_contents, and not touch outbuf itself since that function > didn't allocated it? Seems like that's a potential crash bug, if I'm > reading it correctly. Same with krb5_mk_priv. > > 3. I'm trying to understand when it's safe to not use a replay cache, > and from reading the internet[*], it seems like if I have the packets in > a session have any kind of unique challenge-response data in them, I > don't need to worry about replays, right? I control the protocols here, > so I can add anything I want to the packets. I'm also confused by the > session subkey stuff, when would you want to or not want to use > AP_OPTS_USE_SUBKEY? Is that related to the replay problem? Some of the > reports of replay cache performance are somewhat worrying for my > use-case, have things changed much since the links below were written? I > have a single service using a unique service key, can I use the memory > replay cache safely? > > 4. I've made msdev vcproj/sln files that build the kerberos client files > for static linking as opposed to requiring a DLL, and an init file that > calls all the right lib inits and shutdowns. Is there any interest in me > contributing these back? Is there any issue with linking krb5 statically > in a client? > > Thanks for making it this far, this probably should have been 4 emails, > Chris > > * > https://twiki.cern.ch/twiki/bin/view/DataManagement/KerberosReplayCachePerfomance > > http://osdir.com/ml/encryption.kerberos.devel/2006-12/msg00056.html > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
