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

[Greg Hudson]

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.