[3361] in Kerberos-V5-bugs
pending/1123: rb5_rd_priv can never never work through NAT
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Wed Jun 26 07:30:17 2002
Resent-From: gnats@rt-11.mit.edu (GNATS Management)
Resent-To: gnats-admin@rt-11.mit.edu
Resent-Reply-To: krb5-bugs@mit.edu,
Jonathan Kamens <jik@kamens.brookline.ma.us>
Message-Id: <200206261128.g5QBSKHS026416@jik.kamens.brookline.ma.us>
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
To: krb5-bugs@mit.edu
Errors-To: krb5-bugs-admin@mit.edu
Date: Wed, 26 Jun 2002 07:28:20 -0400
>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
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs
