[OpenAFS] some simple openafs questions

Derrick J Brashear shadow@dementia.org
Sat, 26 Jul 2003 20:55:59 -0400 (EDT)


On Sat, 26 Jul 2003, Rodney M Dyer wrote:

> I just re-ran the test and got the following from the MIT kdc v5 logs...
>
> krb5kdc: Invalid message type - while dispatching
>
> ...about 10 lines in all before "klog" quit.
>
> I'm not sure what to make of this error.  Sound's like the kdc got the
> request and didn't understand the message right?  So maybe there is a

Yup.

> difference between the true K4 protocol and Transarc's kaserver K4?  On
> Friday Mike believed he compiled and setup the kdc for K4 and K5, but I
> guess I'll get him to check it Monday again to make sure.

Or maybe your KDC isn't actually dealing with krb4 requests. A kinit which
speaks only krb4 and nothing else, thus making it unable to be "helpful"
is the best way to test.

> Let's say for the sake of argument we get this to work.  Is this going to
> be secure?  I mean...didn't MIT K5 get modified to take care of a problem
> with the security of the K4 protocol a while back?

Yes, it was modified to disable crossrealm krb4.

> Another oddity...  We noticed that the MIT krb5 "kinit" sends requests for
> K4 tickets over port 88, the K5 port.  Hmm... :\ , (scratches head).  So
> maybe in theory if we modified OpenAFS to send it's K4 requests, not to
> port 750, but to port 88, it might work?  Or, is that where the K5 protocol
> change is...between using 750 and 88???

I thought MIT krb5 kinit got a krb5 ticket and used 524 to translate it
anyway. Maybe not. But I really doubt talking to port 88 will help you.

> Lastly, what sparked this thread to begin with was simply that the Windows
> AFS client does K4 not Rx.  But, the Rx libs are "in" the OpenAFS client
> anyway, so why not use the same authentication algorithm that UNIX clients
> use?  That way we can just go ahead and use fakeka?  How tough would it be
> to switch the code back to Rx?

Given that I don't know why it ever used krb4 I can't really guess if
there's some subtle thing involved precluding it.

> According to the things I've been reading here (Ken Hornstein, etc),
> apparently OpenAFS 1.2.9 is ready to use K5 afs principle keys.  As long as
> your AFS file servers are using the K5 keytab you are ok...right?  But, I'm
> also getting the impression that this is some kind of hack, that it isn't
> somehow pure.  So which is it?  Where are we?

No, your AFS file servers use their AFS keyfile, just like before. They
just have to be new enough, and the key in the keyfile must match the afs
key your kdcs will hand out. It's both. We're here. It doesn't get you
multiple encryption types, and it doesn't address the problem of
constraining to krb4 service/principal name lengths (and some other
things). Some of that requires cache manager changes. The goal of this was
not to.

> If we pull the authentication part out of "klog"
> (ka_UserAuthenticateGeneral) and just set OpenAFS up so that it just
> requests AFS K5 service keys through some generalized/standardized library
> (like Doug Engert suggests GSSKlog) then we'd be at our ideal.

I'll be the anti-Doug and suggest krb524 works just fine. krb5 kinit,
krb524 (which gets you a stripped krb5 ticket, not a krb4 ticket, if set
up correctly), cram it into the cache manager, get back to whatever other
problems.