Skip Menu |
 

Download (untitled) / with headers
text/plain 3.4KiB
From jik@kamens.brookline.ma.us Wed Jun 26 07:28:23 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id HAA16193
for <bugs@RT-11.mit.edu>; Wed, 26 Jun 2002 07:28:22 -0400 (EDT)
Received: from jik.kamens.brookline.ma.us (jik.kamens.brookline.ma.us [66.92.77.120])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id HAA28554
for <krb5-bugs@mit.edu>; Wed, 26 Jun 2002 07:28:21 -0400 (EDT)
Received: (from jik@localhost)
by jik.kamens.brookline.ma.us (8.12.2/8.12.2) id g5QBSKHS026416;
Wed, 26 Jun 2002 07:28:20 -0400
Message-Id: <200206261128.g5QBSKHS026416@jik.kamens.brookline.ma.us>
Date: Wed, 26 Jun 2002 07:28:20 -0400
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
To: krb5-bugs@mit.edu
Subject: rb5_rd_priv can never never work through NAT

Show quoted text
>Number: 1123
>Category: pending
>Synopsis: rb5_rd_priv can never never work through NAT
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Jun 26 07:29:01 EDT 2002
>Last-Modified: Wed Jun 26 17:05:01 EDT 2002
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:

From: Sam Hartman <hartmans@MIT.EDU>
To: Jonathan Kamens <jik@kamens.brookline.ma.us>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pending/1123: rb5_rd_priv can never never work through NAT
Date: Wed, 26 Jun 2002 17:03:28 -0400

Hi. You are correct that krb_mk_priv and krb_rd_priv do not work with
NAT.

The address check is required by RFC 1510.

Previous attempts to revise RFC 1510 made the address check optional.
However doing so introduces a reflection attack because the address is
the only thing that prevents me from reflecting a message generated at
the source back to that source in cases where sequence numbers are not
used.

The current clarifications draft in the Kerberos working group of the
IETF does propose a directional address type to work around this
issue. We will eventually implement that feature, but until we do,
priv and safe messages will not work with NAT.


Show quoted text
>Unformatted:
In Kerberos 1.2.5 and previous versions:

If I'm on a machine which accesses the Internet through a NAT
firewall, such that when my requests get to their destinations their
source address has been modified, and I attempt to use an application
which uses krb5_{mk,rd}_priv to authenticate to a machine outside the
firewall, it can't possibly work because of this code in
krb5_rd_priv_basic() in lib/krb5/krb/rd_priv.c:

if (!krb5_address_compare(context,remote_addr,privmsg_enc_part->s_address)){
retval = KRB5KRB_AP_ERR_BADADDR;
goto cleanup_data;
}

There needs to be a way for the caller to tell krb5_rd_priv(), and
hence krb5_rd_priv_basic(), that it doesn't want it to check the
remote address. It would make sense to do this in
krb5_rd_priv_basic() simply by not executing the code above if
remote_addr is null, and then the caller could obtain this behavior
simply by not setting the remote address in the authentication context
before calling krb5_rd_priv().

I realize that there are security implications in not checking the
remote address, but it's sometimes an unavoidable situation. Besides,
if you're using a NAT firewall, you've probably got other security
precautions in place to offset the loss of this one :-).

jik
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
Date: Sat, 2 Sep 2006 23:30:05 -0400
To: krb5-bugs@mit.edu
Subject: Re: pending/1123: rb5_rd_priv can never never work through NAT
Any progress on this issue in the last four years? :-)

jik

Reference:

Sam Hartman writes:
Show quoted text
> Hi. You are correct that krb_mk_priv and krb_rd_priv do not work with
> NAT.
>
> The address check is required by RFC 1510.
>
> Previous attempts to revise RFC 1510 made the address check optional.
> However doing so introduces a reflection attack because the address is
> the only thing that prevents me from reflecting a message generated at
> the source back to that source in cases where sequence numbers are not
> used.
>
> The current clarifications draft in the Kerberos working group of the
> IETF does propose a directional address type to work around this
> issue. We will eventually implement that feature, but until we do,
> priv and safe messages will not work with NAT.

--
Help stop the genocide in Darfur!
http://www.genocideintervention.net/
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #4235] Re: pending/1123: rb5_rd_priv can never never work through NAT
Date: Wed, 06 Sep 2006 02:02:37 -0400
RT-Send-Cc:
Show quoted text
>>>>> "jik@kamens" == jik@kamens brookline ma us via RT <rt-comment@krbdev.mit.edu> writes:

jik@kamens> Any progress on this issue in the last four years? :-)
jik@kamens> jik

Sort of, but not useful to you. Ken Hornstein produced a patch that
implemented directional addresses, but never cleaned the patch up or
gave it to us.