Ticket forwarding and IP addresses

Srinivas Cheruku csri at sonata-software.com
Sat Feb 16 00:00:50 EST 2002


Cesar,

FYI - Did you know that CyberSafe are still supporting this product
and also MIT code - see http://www.cybersafe.ltd.uk
<http://www.cybersafe.ltd.uk> "

Now, I dont think you'll be getting pity or sympathy.

Srini

-----Original Message-----
From: Cesar Garcia [mailto:Cesar.Garcia at morganstanley.com]
Sent: Friday, February 08, 2002 10:48 PM
To: Ken Hornstein
Cc: Cesar Garcia; kerberos at mit.edu
Subject: Re: Ticket forwarding and IP addresses 


>>>>> "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
_______________________________________________
Kerberos mailing list
Kerberos at mit.edu
http://mailman.mit.edu/mailman/listinfo/kerberos
*********************************************************************
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you may
not copy or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*********************************************************************



More information about the Kerberos mailing list