Thanks for the detailed response! > 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.
Yeah, I have another channel of information flowing to both parties from the lobby server, so I can actually send them both a mk_priv message from the lobby with the addresses to stuff in the client<->client auth_context, which will also help a bit. Reflection isn't a problem in my protocol anyway, I think. > the do-sequence auth context flag addresses both concerns, if you're > using a sequential transport such as TCP. This brings up the question of what to do in unordered/unreliable situations? I have a UDP stream between clients that's a mix of ordered/reliable "pseudo-tcp" messages and unordered/unreliable messages. My original plan was to use the pseudo-tcp messages to negotiate the u2u auth_contexts, but I also want to be able to mk_safe/mk_priv on the unreliable messages. Do I need two auth_contexts in that case, one without do-sequence set? Chris On 2011/08/03 08:48, Greg Hudson wrote: > 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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos