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

[Chris Hecker]

> 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 as you mention below, when the mutual authentication was complete 
(mk_req->rd_req->mk_rep->rd_rep) for there to be one subkey in the 
send_subkey on the client and the recv_subkey on the server, and another 
on the send_subkey of the server and the recv_subkey on the client. 
This is not what happens.  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.  Namely:

    - mk_req_ext.c - generate_and_save_subkey stomps both send and recv
    - rd_req_dec.c - sets both send and recv with krb5_k_create_key
    - mk_rep.c - generate_and_save_subkey again
    - rd_rep.c - sets both to the enc->subkey

So, a couple questions:

1.  I assume this is correct, and I'm simply misunderstanding?  I'm 
trying to parse your last sentence below...the 
KRB5_AUTH_CONTEXT_USE_SUBKEY on the mk_rep makes a new subkey for the 
entire session, so assuming I always do mutual authn, then if I get a 
replayed AP-REQ which has a subkey in it, I stomp it with the new one 
during AP-REP, and to get the new subkeys the client would have to be 
able to decode the reply, which they can't since they're just replaying. 
  I think.

2.  Why have send_subkey and recv_subkey if they're always equal?

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.
>
>
>