pending/1123: rb5_rd_priv can never never work through NAT
Jonathan Kamens
jik at kamens.brookline.ma.us
Wed Jun 26 07:28:20 EDT 2002
>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:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>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
More information about the krb5-bugs
mailing list