Proxy for Kerberos?

[Roland Dowdeswell]

On 1153768298 seconds since the Beginning of the UNIX epoch
Jiva DeVoe wrote:
>

>Tell me if this is inherently wrong-thinking...
>
>I want to access a kerberos server that is behind a firewall without  
>exposing the kerberos port to the internet.  So I want to proxy it  
>through a tunnel.  I am guessing that Kerberos may have some sort of  
>built-in preventative measures within itself to prevent spoofing or  
>something like that which would cause this not to work.  Is this  
>true?   If not, is there any reason this wouldn't work?

With Heimdal, you can use HTTP encapsulation to talk the a KDC.  This
will work via any HTTP proxy.  I've used this upon occasion to talk
from odd internet setups to my external realms.

You may run into issues with addresses in tickets.  You will have to
turn them off at the very least if you want proxying to work.

Then there's the question of what you hope to achieve with a proxy.
There is little value with providing an application layer proxy
unless the data that it passes is somehow inspected and sanitised.
Given that much of the data in Kerberos requests is encrypted---you
can't actually do this.  If you are looking to mitigate the risk
of, e.g. a buffer overflow in the ASN.1 code (the most obvious
example, probably), then you would need to analyse all of the ASN.1
in the packet---and being able to do this would mean that you would
have access to any key in the KDCs DB.  So, in effect to sanitise
the ASN.1 data completely you would necessarily have to be a KDC.

You could OTOH provide limited sanitisation functionality---of the
unencrypted data.  If this is of sufficient value, then it might
be a good idea.  There are various pieces of external -> internal
informtion that might be interesting to modify or disallow.  E.g.
if an internal client sends an AS_REQ and the external KDC states
the single DES pre-auth is required then it might be an idea to
either disallow that or substitute a stronger enctype as an interloper
could be telling your client to basically send a very weak pre-auth
packet which could be used to gather information about your password.
It would take a bit of analysis to determine what cleartext bits
of the packet you'd like to restrict, though.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/