Ticket forwarding and IP addresses

Cesar Garcia Cesar.Garcia at morganstanley.com
Fri Feb 8 12:17:57 EST 2002


>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>> Since we use NIS as the primary source for hostname
>> resolution, all host lookups render a single IP address,
>> even for multihomed machines. Moving to DNS is not an
>> option at the moment.

Ken> I have to ask ... you're STILL using NIS for hostname resolution?
Ouch.

Thanks for the sympathy. Unfortunately, in our case, migrating
to DNS is not a trivial effort, but let's not go there.

>> That said (barring hacks to application protocols that
>> would allow target hosts to send IP addresses back to
>> the source host, then having the client embed the full set
>> of tickets), the way to address this would be to have
>> the target host obtain new tickets will a full set of
>> IP addresses.
>> 
>> 1 - is this possible?

Ken> The trick here is that one of the IP addresses in the target ticket
Ken> _must_ be the IP address used to talk to the KDC; otherwise, you're
Ken> outta luck.

>> 2 - is it within the limits of the specification?

Ken> Yes.

Ken> It occurs to me that you could save yourself some pain and simply get
Ken> a completely addressless ticket.  There is a school of thought in the
Ken> Kerberos world that suggests IP addresses in tickets are not that
useful.

OK. let's reset a bit.

What I neglected to mention was that we are a former CyberSafe
customer, with remnants of CyberSafe code still in production.
(Now I'll be getting pity, not sympathy.)

Since the move to MIT has also been driven by the deployment
of platforms not supported by CyberSafe (e.g., linux), we have
focused primarily on application infrastructure. That said,
the core CyberSafe KDCs are still in place, in addition to
a variety of other KDC based services, either homegrown
or adopted to work with a CyberSafe KDB.

Admittedly, I'll have to assess the current dependencies that
we have on IP addresses. The implementation of krb524d that
we currently use requires IP addresses, or it barfs. This may
well be the only dependency that we really have. Client krb524
code has already been migrated to MIT. That said, I'll investigate
if we have any more dependencies on IP addresses in tickets and
start working on porting krb524d to the CyberSafe KDB. Unfortunately,
I can't use it as is for now, until we migrate the all the KDC
services  to MIT krb5 (or perhaps Heimdal, since incremental
propagation is a must have).

Nonetheless, we have all sorts of applications that obtain initial
credentials (various homegrown apps, PAM modules, sitecheck
binaries for irix) which would need to "corrected".

Ticket forwarding was my immediate objective. But I'll submit
I was looking for the lazy way out.

Ken> --Ken



More information about the Kerberos mailing list