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:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 10:48 PM To: Ken Hornstein Cc: Cesar Garcia; [EMAIL PROTECTED] Subject: Re: Ticket forwarding and IP addresses >>>>> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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. ********************************************************************* _______________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
