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

[Chris Hecker]

Thanks for the quick replies!

> This is coming in 1.10.

Awesome!  Yeah, I need it now, so I'll just hack my copy and then 
replace it with your goodness when it arrives.  Just to get my 
requirements in, I'd like to be able to set all the profile information 
from code, so either you expose an API to init an empty profile, and let 
me stuff it with values, then pass it to krb5_init_context, or you don't 
require the profile to be set up inside init_context, and I stuff 
ctx->profile after init_context creates a null one.  It would be best to 
be able to do this before init_context, so it doesn't try the 80 million 
different file and registry operations looking for a profile before 
finally initing a null one.

> Not that I'm aware of. That would indeed be a pretty huge change.

Yeah, it looked like it.  I'm not going to worry about it for now.  If 
you guys have a long term wish-list, then adding ways to allow the 
caller to provide pre-allocated buffers to avoid all dynamic memory 
allocations once the session is initialized would be great.  Or, at 
least a way to have pooled allocators called instead of raw malloc/free. 
  This kind of thing is important in console games, or any embedded 
system, really.

Did you see my note in the first mail about the mk_safe/mk_free free() 
bugs?  I think that's a potential crash bug in both functions.

> subkeys explanation

Okay, great, so if I do mutual auth, and I use those two flags, and 
don't do anything on the initial client->server authentication, then I 
don't need to worry about cookies or nonces or anything in my packets, 
and I can disable the replay cache (assuming I mk_safe/mk_priv packets 
in both directions)?

Thanks!
Chris




On 2011/07/14 20:59, Greg Hudson wrote:
> On Thu, 2011-07-14 at 21:57 -0400, Chris Hecker wrote:
>> 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.
>
> This is coming in 1.10.  I haven't finished the project writeup for it,
> but there are some design discussions in the krbdev archives.  I'm not
> sure what your constraints are; if you need to make a current release
> work but can modify the code, you may just want to hack up libprofile in
> whatever way is easiest and replace it with the 1.10 pluggable
> configuration system in the future.
>
>> 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)?
>
> Not that I'm aware of.  That would indeed be a pretty huge change.
>
>> 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?
>
> So, there are two dangers: an attacker could use replayed messages to
> fake a client to the server, or an attacker could use replayed messages
> to fake a server to the client.
>
> As long as you do mutual authentication, faking a server to the client
> should be impossible if you use AP_OPTS_USE_SUBKEY in the client.
> Setting that option causes the client to generate a fresh subkey for the
> auth context each time it performs an authentication, so no previous
> KRB-AP-REP packet will be accepted.
>
> Likewise, if you set KRB5_AUTH_CONTEXT_USE_SUBKEY in the auth context on
> the server, the server will generate a (second) fresh subkey in the
> reply message.  This means if the client replays a KRB-AP-REQ, the
> server will (without a replay cache) believe it to be a valid
> authenticator, but the attacker won't be able to send any valid KRB-SAFE
> or KRB-PRIV messages because it won't know the subkey for the auth
> context.
>
>
>