[OpenAFS] kerberos ticket length and IP addresses

[Jeffrey Altman]

Cesar Garcia wrote:
> [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

Correct.  You must use OpenAFS 1.4 servers in order to support tickets
larger than 344 bytes.  (Actually 1.3.65 or above.)

Here is the diff.  It can be applied to 1.2 servers provided you
can recompile.

http://www.openafs.org/cgi-bin/cvsweb.cgi/openafs/src/rxkad/rxkad.p.h.diff?r1=1.10&r2=1.8

> 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

Similar problem.   The pioctl buffer isn't large enough to hold the
input.  Rebuilding is required if you want to support the larger ticket
sizes.

> 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).

The address list comes from the TGT.

> 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.

Exactly.

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

Yes.

> 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.

Hacking the KDC to strip addresses for the AFS service principal or
using the krb524d (Kerberos v4 tickets will only support a single
address and will always be small enough.)

Jeffrey Altman
Secure Endpoints Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080207/3fdfaa31/attachment.bin