[2356] in Kerberos_V5_Development
Re: kerberos through the firewall
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Apr 19 15:21:03 1997
To: krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 19 Apr 1997 15:20:42 -0400
In-Reply-To: Jeffrey Hutzelman's message of Sat, 19 Apr 1997 13:24:55 -0400 (EDT)
Jeffrey Hutzelman <jhutz+@cmu.edu> writes:
> > Example: for one vendor we are collaborating with, it would take 2-3
> > months to have such a change approved and executed (yes, it's true!).
>
> You have a vendor that's that paranoid, but lets HTTP connections
> through? That _is_ a little hard to believe...
That's not necessarily paranoia, could just be incompetence.
I agree that any site that lets http through really ought to have no
problem opening up a port for Kerberos. But if a proxy of some sort
is needed, it's needed...
Is there any information that needs to be provided that isn't in the
clear in the krb5 protocol? I don't have the protocol spec in front
of me. Could you set up a proxy inside the firewall, have normal krb5
messages go to it, and let it worry about how to get outside the
firewall (whether by http or by some other means) and what host or
hosts to send to on the outside? I think that'd be a much simpler
solution from the krb5 library side of it, if it works. Then the
library has no need for the http wrapper or base64 encoding stuff;
only one pair of applications does.
> OK; that last one's just my personal opinion. Even so, organizations
> that use firewalls are making a conscious choice to severely restrict
> the abilities of their users to communicate with the outside world,
> in exchange for a perceived increase in security. Your proposal is
> essentially to tunnel Kerberos inside HTTP (which was never designed
> for that purpose) in order to circumvent that...
If they're going to do it, they're going to do it... it could be done
with an abuse of other protocols as well (e.g., finger). Anything
that gets through the firewall and allows arbitrary data in both
directions during some phase of the exchange. Given the, ah, typical
level of security in browsers these days, I expect there would
probably be several services more likely to be available than http.
