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