[OpenAFS] some simple openafs questions

[Rodney M Dyer]

At 07:41 PM 7/25/2003 -0400, Jeffrey Hutzelman wrote:

>Yes, it does speak real krb4, which really isn't all that complicated a 
>protocol.  It will work with an MIT KDC; we have this running in 
>production right now.  I'd suggest checking your KDC logs to see what is 
>going on.  It may be the case that additional configuration is required 
>before the KDC will response to krb4 requests (note this is independent of 
>what ports it listens on).

Ok, I tested "klog" late Friday with our Solaris systems programmer Mike 
Mosley.  He handles our AFS cell servers and Kerberos kdc's.  We did a 
quick test before we were getting ready to leave, then I mailed you the 
message.  I'm not sure why we jumped to conclusions and didn't think to 
check the logs.  It just seemed odd that the kdc is listening on 750 yet no 
replies.

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

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?

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

The "ka_UserAuthenticateGeneral" call needs to do two transactions 
anyway.  It needs to authenticate you, then request the AFS service 
ticket.  It doesn't keep your tgt credential around.

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?

As an aside, back in June there was a thread titled..."[OpenAFS] Kerberos 
5, AFS, and no krb524d".  In this thread many of us chimed in about why we 
need to use an alternate service to convert keys anyway.  I liked Douglas 
E. Engert's ideas about making AFS more open to almost any authentication 
methods, however...I like using pure 100% unadulterated krb5.  That's were 
we all want to be right?

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?

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.

Ok, I'll shut up now.

Rodney