[1258] in Kerberos_V5_Development
Re: security flaw in get_in_tkt: address verification
daemon@ATHENA.MIT.EDU (E. Jay Berkenbilt)
Sat Jun 1 10:34:00 1996
Date: Sat, 1 Jun 1996 10:32:53 -0400
From: "E. Jay Berkenbilt" <qjb@netrail.net>
To: marc@MIT.EDU
Cc: hartmans@MIT.EDU, epeisach@MIT.EDU, krbdev@MIT.EDU, bjaspan@MIT.EDU
In-Reply-To: <9606010222.AA03800@portnoy.MIT.EDU> (message from Marc Horowitz
on Fri, 31 May 1996 22:22:55 EDT)
X-POP3-Rcpt: qjb@netrail
Cc: epeisach@MIT.EDU, krbdev@MIT.EDU, "Barry Jaspan" <bjaspan@MIT.EDU>
Date: Fri, 31 May 1996 22:22:55 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> Are you sure that there aren't situations involving proxies
>> through a firewall where the kdc, or agent between the kdc and client
>> might not reasonably add addresses to the tgt request? Do we want to
>> allow such usage?
In such a situation, I'd rather the proxy talk to the client, and have
the client forward the tickets to the new address, than have the proxy
changing the ticket in transit.
Marc
I think I'll break my silence to respond to this. :-) As a person who
has administered btoh firewalls and kerberos realms (though not any
5.0 yet and never both at the same time), I have some idea of what I
would like to be able to do. I have only been skimming recent
traffic, so I most likely don't have the subtleties down of what this
dicsussion is addressing.
In a typical proxy-based firewall, the user authenticates to the proxy
by way of a password, single-use keys, etc. Once authenticated to the
proxy, the user must then authenticate to the internal network. If
you take TIS's firewall toolkit as an example, you telnet to the
firewall, respond to the challenge, and receive a prompt from which
you can issue another telnet. Several problems arise in thinking
about how to kerberize this. The client and the firewall both have to
access to the same kerberos server. If your realm's server is on the
inside of the firewall, there is a chicken and egg problem. I suppose
it's probably okay to run a kerberos server on the firewall if we
really believe that there are no vulnerabilities. In this case, the
user outside could get forwardable tickets (it's been a while, so bear
with me if I mangle how K5 deals with forwarding tickets). However, I
think most firewall administrators would be reluctant to put a
kerberos server on a firewall. In this case, you really do need a
simple kdc proxy server that can simply pass requests through the
firewall in a safe manner. Ideally, the client would provide the
firewall's address as that of the kerberos server and be able to
obtain credentials that would allow authentication to the firewall and
subsequent authentication to the inside network. I'm far enough away
from the protocol and the issues not to be able to immediately deduce
from this discussion what implications this has for the current
discussion, but I hope the input will be useful. Sorry if I'm
babbling due to thinking too much like a K4 user.
--
E. Jay Berkenbilt (qjb@netrail.net) | Member, League for Programming Freedom
| lpf@uunet.uu.net, http://www.lpf.org
