[OpenAFS] kerberos ticket length and IP addresses

[Cesar Garcia]

[this is largely a kerberos question, but I am cross posting in case
anyone on the openafs mailing list may have had a similar experience]

We are having two problems with larger krb5 afs/service tickets.

Specifically when krb5_creds.ticket.length exceeds order of about 350
bytes we run into these two problems (the length tolerence differs
slightly between the two issues):

1 - we are still running openafs 1.2.13 fileservers which don't seem
  to like the larger tickets, they treat requests as if the request
  came from:

  #define ANONYMOUSID     32766

  so in effect, the tokens are useless

2 - on machines running older versions of the openafs client,
  ktc_SetToken fails as follows:

  nptest05:/u/cesarg$ aklog
  aklog: unable to obtain tokens for cell b.ny.ms.com (status: 11862789).

  nptest05:/u/cesarg# translate_et 11862789
  11862789 (ktc).5 = AFS kernel pioctl doesn't exist

Upgrading openafs servers is well under way, but realistically another
6 months before completion. Upgrading openafs clients is unfortunately
much more difficult for us to do - largely due to [let's call it]
political factors, that upgrade schedule is much much longer.

We see these problems on client machines that have many (>7 or 8)
interfaces, as the TGTs we obtain are addressful - removing IP
addresses (e.g., kinit -A) works, but unfortunately is not a short
term option for us as this causes problems for legacy/interal apps
built with *very* old krb5 libs - and unfortunately my team doesn't
own those apps.

As a workaround, we attempted to obtain afs service tickets via
krb5_get_cred_via_tkt(), specifying an empty set of addresses (arg 4),
but this doesn't seem to have any impact on the length of the
resulting afs service ticket (cred.ticket.length).

In fact if we request 0, 50, or 100 IPs via arg 4, it still doesn't
seem to influence the length of the afs service ticket. The afs ticket
length seems to be tied to the length of the tgt in all cases.

Is this expected? I've yet to go deep enough into the relevent tgs req
code to understand why this happens.

Is there something else we could do that will result in smaller
tickets. I realize our real problem is political, a short term answer
for us unfortunately cannot require that we strip IPs from our TGTs,
or require openafs client and server upgrades - these contraints are
horrible - believe me, none of us are happy about it ... not looking
for sympathy :-)

Are there any additional details we can provide that would help. I
suppose it is possible our code/workaround is simply coded
incorrectly. I'd be willing to send out code if someone thinks that is
the case.

Any help in understanding this is greatly appreciated.

Thanks.