On Sat, 2011-08-06 at 05:38 -0400, Chris Hecker wrote:
> Everywhere a subkey is generated or read in
> these functions (that I could find), they stomp both send_subkey and
> recv_subkey with the same key.
Right. RFC 4120 gives application protocols a fair amount of latitude
on what key to use f
> AP_OPTS_USE_SUBKEY on client
> KRB5_AUTH_CONTEXT_USE_SUBKEY on the server
I'm getting around to testing this, and I think I'm misunderstanding the
subkey thing, and specifically, how the send_subkey and recv_subkey are
used in the auth_context. I expected, when I implemented the above
flags
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 A
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 thr
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.
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:
