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