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

[Greg Hudson]

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.