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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
