Ticket forwarding and IP addresses

[Cesar Garcia]

OK. I may have figured the error.

Although the the key version number for my afs principal is 1,
the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.

I determined this on the client side, I'll have to walk through the
server code to see why the cred is returned with a kvno of 0.

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:

Cesar> This is not exactly a Kerberos specific issue, but perhaps
Cesar> the folks on this mailing list might have some insight.

Cesar> I decided for now to go with Ken's suggestion that I simply
Cesar> remove the IP addresses from my V5 tickets, and do ticket
Cesar> forwarding sans IP addresses.

Cesar> It appears that the one dependency we have on IP addresses
Cesar> is k524. Our client code is modern and works fine. It's an
Cesar> old krb524d which we currently run on a CyberSafe KDC that
Cesar> requires IP addresses in the requesting ticket.

Cesar> So thanks to Doug Engert, we have a -k option that allows
Cesar> one to run the MIT krb524d with a keytab, which handles
Cesar> null IP addresses just fine - and I don't immediately, or
Cesar> perhaps ever, have to solve the problem of writing the glue
Cesar> to get it to work the CyberSafe KDB. Simply extracting all
Cesar> the necessary keys to a keytab file suffices.

Cesar> I then add the following keys to a keytab file:
Cesar> 1 - krbtgt/k5realm at k5realm
Cesar> 2 - afs at k5realm (*)

Cesar> (*) An aside - this predates me, so I'm not sure what all
Cesar> the reasons were) Since all of our AFS cells use the same
Cesar> server principal, we don't have afs/afscellname at k5realm
Cesar> for each of our cells, just one principal afs at k5realm
Cesar> (one k5realm) for all cells. Not sure how/if this is
Cesar> relevant, but it is different.

Cesar> The basic algorithm for obtaining tokens for all cells follows:
Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for afs at k5realm
Cesar>     (this ticket get's cached)
Cesar> 2 - using k524 and V5 ticket for afs at k5realm, obtain a V4 ticket
Cesar>     for afs at k5realm
Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred
Cesar>     obtained in step 2.

Cesar> This code is implemented in a lib/app we call ak5log and works
Cesar> with the cybersafe based krb524d, with either the cybersafe
Cesar> based k524 client or the MIT based k524 client.

Cesar> When we try to run either the cybersafe or MIT based client
Cesar> against the MIT krb524d (using -k), the ak5log code completes,
Cesar> but I get the following messages in syslog:
Cesar> ----
Cesar> Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408)
Cesar> ----
Cesar> with a similar error going to my console.

Cesar> krb524init itself seems to work fine against the same MIT
Cesar> krb524d with the keytab. That is the I can V4 tgt and run
Cesar> my v4 apps with no problem.

Cesar> The error apparently corresponds to "Unknown key". I've verified
Cesar> the key and kvno for afs at k5realm that was extracted to the
Cesar> keytab file, and it appears to be correct. I assume I would
Cesar> have failed earlier had that not been the case.

Cesar> When I list my tokens, the listing looks normal.t The
Cesar> tokens themselves, however, are worthless.

Cesar> We're running various versions of transarc afs (3.5, 3.6)
Cesar> on our solaris machines, openafs 1.2.2 on our linux boxes.
Cesar> AFS servers are solaris.

Cesar> Before I go digging into this problem some more, I was wondering
Cesar> if anyone might have some insight on this one.

Cesar> Thanks in advance.

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:

Cesar> I've been working with 1.2.2 for a some months now, and only
Cesar> recently have attempted to get the rcmds working, mainly in
Cesar> an effort to better understand how ticket forwarding works,
Cesar> since we have a need to do this in a homegrown application.

Cesar> The behavior that I see is that when I invoke ticket
Cesar> forwarding, the "forwarded" tickets contain only a single
Cesar> IP address.

Cesar> After walking through some of the code, it appears that
Cesar> the client, via krb5_fwd_tgt_creds, determines the target's
Cesar> IP address via a host lookup using gethostbyname(), as
Cesar> implemented in krb5_os_hostaddr().

Cesar> Since we use NIS as the primary source for hostname
Cesar> resolution, all host lookups render a single IP address,
Cesar> even for multihomed machines. Moving to DNS is not an
Cesar> option at the moment. Additionally, we use Veritas VCS
Cesar> and other similar clustering facilities. These hosts
Cesar> will have additional IP addresses that are not associated
Cesar> with the real hostname, but with service names for a
Cesar> particular cluster/application. So even if were to switch
Cesar> to DNS, the client would not be able to determine all the
Cesar> IP addresses for a given target host via the hostname
Cesar> lookup that it uses today.

Cesar> That said (barring hacks to application protocols that
Cesar> would allow target hosts to send IP addresses back to
Cesar> the source host, then having the client embed the full set
Cesar> of tickets), the way to address this would be to have
Cesar> the target host obtain new tickets will a full set of
Cesar> IP addresses.

Cesar> 1 - is this possible?
Cesar> 2 - is it within the limits of the specification?

Cesar> If so, has anyone has implemented this for 1.2.2 or any
Cesar> releases of MIT krb5.
Cesar> _______________________________________________
Cesar> Kerberos mailing list
Cesar> Kerberos at mit.edu
Cesar> http://mailman.mit.edu/mailman/listinfo/kerberos