(mk|rd)_(priv|safe) and NAT

Chris Hecker checker at d6.com
Wed Aug 3 16:56:26 EDT 2011


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



More information about the Kerberos mailing list