[OpenAFS] Kerberos 5, AFS, and no krb524d

[Marcus Watts]

Ken Hornstein <kenh@cmf.nrl.navy.mil> sent:
> >Well, it should be as long as it matches the AFS key on your AFS servers
> >(kvno and key). But "not needing krb524" is currently the same as
> >otherwise: only if you transmogrify the ticket somehow, namely, stripping
> >all but the encrypted part.
> 
> I know we had the "apple versus papya" discussion about this earlier,
> but I think we're talking past each other.  There really _is_ no
> transmogrification w.r.t getting the encrypted part of the V5
> ticket, because the encrypted part of the V5 ticket really is the
> only thing you can _call_ a ticket.  A small distinction, yes, but
> it's not like you're performing open-heart surgery; it's more akin
> to picking a carrot and cutting off the end.  I don't think it's really
> a huge deal, but I guess we'll have to agree to disagree on this one.

I think this is just nit-picking, but I'd have say it's not quite that
simple and it gets a bit confused because K4 and K5 terminology is just
slightly different.  In K4, you have a "ticket file" which contains on
a per-service basis, the service name, session key, other housekeeping
information, and an encrypted blob.  The encrypted blob by itself is
often called "the ticket".  In K5, you have a "credentials cache" which
contains, on a per-service basis, the service name, session key, other
housekeeping information, and something called a ticket which is an
ASN.1 encoded blob which contains some housekeeping information and an
encrypted blob.  The encrypted part is not normally separated from its
ASN.1 wrapper, except deep in the bowels of the K5 libraries.

For both K4 and K5 you have to ship over housekeeping data and the
encrypted blob.  In K4 the housekeeping data went over separate from
the ticket.  In K5, there's slightly more data (such as the encryption
key type) and it goes over as part of the ASN.1 blob.

When piggy-backing K5 on top of K4 (as for AFS), since K4 version
numbers are 1 byte and K5 version numbers could be larger (and also
because there's no place for the encryption type, &etc&etc), it's
convenient to use the K4 version number slot as a place to say do K5,
and pull the real key version number and encryption type out of the
ASN.1 wrapper which the naive "K4" code can think is a binary blob
that is probably encrypted.  It's a good thing most K4 code doesn't
check to see if "tickets" are 0 mod 8 in length.

I don't think this *really* matters to any but the tgt and service.
That is, as long as 8 byte single des session keys are acceptable.

				-Marcus Watts
				UM ITCS Umich Systems Group