misc q's: not loading profile from memory, not alloc memory on mk_priv/mk_safe, no replay cache?

[Chris Hecker]

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
>