Interesting problem with Kerberos IPv6 support

[Ken Hornstein]

>If host B has any IPv4 addresses that host A wasn't aware of, they
>also will not be listed in the forwarded tickets.

Sure, run into that problem many times ... but we've generally been able
to deal with that one without having to upgrade the client.

>(1) Get tickets without any addresses specified.

We actually do that in the general case (the case for people who aren't
on-site, and thus we don't manage their machines).  But the old Kerberos
client code has the unfortunate property that even when you get addressless
tickets, they're always addressful when you forward them (I guess that
got fixed in the 1.3 timeframe).

>(2) Send forwardable tickets to host B, and have host B forward them
>    to itself (with all local addresses, or without any addresses) if
>    they're missing any local addresses.

This seems promising, and might not even be too hard to do.

>(3) If the tickets do list addresses, then when contacting the KDC,
>    bind specifically to listed addreses.  That just moves the
>    problem to cases where you contact IPv6-capable services.

That's a bunch of layers to drill through, but that solves other problems,
actually.

>(4) Hack the KDC to always ignore addresses in its checks.  But the
>    issued tickets should keep the same address list, so the problem
>    persists when you contact IPv6-capable services.
>(5) Hack the KDC to always issue address-less tickets.

I might be able to get away with (4), if I just do it for IPv6 (if the
request comes in on an IPv6 address on the KDC, then ignore the address).
Sigh, there's no good solution, unfortunately.  Forcing a client upgrade
just because you add an IPv6 interface to a machine sucks.

--Ken