524 and NAT

[John Hascall]

I think that I'm leaning toward something like putting
the option in krb5.conf like this:

>> At one point I hacked localaddr.c to add a proxy_gateway field to
>> krb5.conf ala NCSA's patch for their Kerberos distro.  With a cable
>> modem it's easy enough to manually alter krb5.conf on the relatively
>> rare occasions that the IP changes.

but having the krb524d treat a special value (like 255.255.255.255)
as use the address this came in on (i.e. the public NAT address).

John

> Has anyone ever worked on getting krb524 working with NAT?  I've been
> fooling with it for a while, but figured I should actually see if I'm
> replicating someone else's work.
> 
> For the unaware, if one calls krb524_convert_creds_kdc from behind NAT,
> one will get an incorrect network address error (I think
> KRB5KRB_AP_ERR_BADVERSION).  If one attempts to use address tickets, one
> gets an invalid address field error (KRB524_BADADDR).
> 
> The easy fix is to alter increds.addresses to add the "real address"
> (the address exposed to the KDC) when calling krb5_get_credentials. 
> Thus, the ticket will come back with the write address info and krb524
> will happily convert it.
> 
> However, it is hard to attain this address on the client side.  I've
> implemented some tomfoolery involving a traceroute and record-route
> pinging, but it fails on the many NAT servers which simply strip all IP
> header options.
> 
> What I'd like to know is: Does anyone know of a good way to get the
> address of a machine's NAT server (or more concisely put the address
> that the KDC actually sees)?  It seems that there might be some obscure
> way to get an address out of the KDC.  Alternately, is there a better
> way to get around this problem that I'm not seeing?
> 
> 
> Other things I've considered doing:
> -Put a "your_IP_is.cgi" on some web server (cons: another service to
> support and fix when it breaks, not everyone's got a web server with a
> cgi-bin laying about)
> -Adding a simple "your ip is:" reply to krb5kdc (cons: modifying the kdc
> is probably left to the more experienced, applying and migrating a patch
> with every update will get annoying - this is not to say I would mind
> MIT doing it for me!)
> -Hacking krb524d to ignore and/or fix the address inconsistency (cons:
> weakens the security - if a v5 sgt is cracked, it can be used from
> anywhere if the service will also accept v4 sgts)
> 
> 
> Incidentally, some v4 services (definitely AFS, I think Cyrus) seem to
> ignore the address field completely.
> 
> 
> Ben Creech
> NCSU ITECS
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
>