On Wed, 2011-08-03 at 03:11 -0400, Chris Hecker wrote: > I'm still in the process of getting my app and server up and running > with kerberos, so I can't test this yet, but the code for > mk_priv/rd_priv and mk_safe/rd_safe seems to want addresses set on the > auth_context, and all the samples show various permutations of this.
There are basically two concerns with these messages: replays and reflections. Checking sender addresses helps very minimally against replays (in that an attacker might need to forge the sender IP address when replaying the packet) and prevents reflections. I believe setting the do-sequence auth context flag addresses both concerns, if you're using a sequential transport such as TCP. Because of NAT issues, we are probably going to make a change in 1.10 so that acceptors aren't required to set the remote address (in which case it won't be checked). It would then become the responsibility of the caller to prevent reflection attacks, either by setting the do-sequence flag or just using an app protocol where messages from the initiator can't be confused for messages from the acceptor and vice versa. By the time GSSAPI-krb5 rolled around, it was agreed that a wrap token format should not include addresses, but should instead distinguish initiator messages from acceptor messages to prevent reflections. So, GSSAPI-krb5 tokens look that way. There is also text in RFC 4120 for "directional addresses" in krb-safe and krb-priv messages, but that isn't implemented in MIT krb5 or Heimdal. >From your point of view, you have a couple of options: 1. Set fake sender and receiver addresses. You might consider using different fake addresses for the initiator and the receiver, effectively converting the IP addresses into directional addresses. 2. Hack the krb5 code to do what we're likely to do in 1.10, skip address verification, and deal with reflection attacks in your application protocol. Jeff Altman wrote: > Is there a reason you are using mk|rd_priv|safe instead of gss? See http://mailman.mit.edu/pipermail/kerberos/2011-July/017444.html and following. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
