Requesting use of addresses in forwardable tickets

[Cesar Garcia]

So the two requirements here are:

1 - make it possible is issue forwarded tickets that do not include IP
addresses.

2 - make it possible to issue forwarded tickets that include the
targets full set of addresses (despite the origin's inability to
identify all of the target's interfaces.

The first requirement could be implemented on the client side
alone. We did this by cloning/renaming krb5_fwd_tgt_creds and exposing
an argument for the caller to specify the which addresses (or no
addresses) should be included in the forwarded ticket.

The second requirement cannot always be satisfied by using proper
naming. We use VCS for clustering where interfaces/hostnames are
defined that are associated with a VCS cluster and have no association
with the actual hostname. (Incidentially we are still using NIS, so
bad naming practices have hurt us well).

CyberSafe (sigh) solved this problem by having the target host compare
IP addresses in the forwarded tickets with it's local interfaces. If
there was a mismatch, it would use TGS to acquire a new ticket that
included a full set of tickets. Presumably, the socket used for this
request was bound, as in bind(), to one of addresses available in the
originally forwarded ticket. I believe they did this only if there was
at one or more addresses in the forwarded ticket, so as to allow for
meeting requirement 1. Perhaps this approach is worth considering.

>>>>> "Matt" == Matt Crawford <crawdad at fnal.gov> writes:

>> Are there (or can there) be any plans to allow a client to
>> not request addresses in the forwardable tickets? You can already do
>> this in kinit for the initial ticket. 

Matt> I don't know about plans, but many of my users have been running onto
Matt> the rocks in this way for years.  The forward their ticket to a
Matt> multihomed host, but the host has separate DNS names associated with
Matt> each address.  (I've told the admins this was trouble since we before
Matt> we started using Kerberos, but they never listened.)


Matt> _______________________________________________
Matt> krbdev mailing list             krbdev at mit.edu
Matt> http://mailman.mit.edu/mailman/listinfo/krbdev