[OpenAFS] some simple openafs questions

[Jeffrey Hutzelman]

On Saturday, July 26, 2003 20:44:02 -0400 Rodney M Dyer <rmdyer@uncc.edu> 
wrote:

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

That sounds like your KDC is not configured to answer V4 requests.

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

No, there is no difference.  The kaserver fully interoperates with krb4 
clients, and the Windows klog interoperates with a variety of krb4 KDC 
implementations, including both MIT krb5 and Heimdal.  This really does 
sound like a configuration problem on your KDC.

> 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, there is an issue in the Kerberos V4 protocol which under certain 
circumstances allows an attacker to construct his own tickets.  This is not 
an implementation issue; it's a problem in the way the encrypted part of a 
Kerberos 4 ticket is constructed, and affects all implementations equally. 
It also does affect "traditional" AFS tokens such as the kaserver provides, 
since the encrypted part of the token is the same.

Provided you disable Kerberos v4 cross-realm authentication and don't allow 
anyone to create large numbers of local principals with names they can 
select arbitrarily, you should be safe from this attack -- whatever 
implementation or protocol variants you use.

The changes which appeared recently in the MIT krb5 distribution relate to 
turning off Kerberos 4 cross-realm authentication by default, and to 
disabling 3DES support in krb4 due to a different but related problem. 
Note that krb4 3DES support was always an MIT-specific extension, and has 
never been supported by AFS.

> 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 don't believe that the MIT kinit sends V4 AS_REQ's at all -- so far as I 
know, it sends only V5 requests.  In any case, the MIT KDC responds to krb4 
and krb5 requests based on the message format, without regard to what port 
the request came in on.  So no, sending the requests to a different port 
will not 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?

"back"?  Well, the windows client has never used the kaserver protocols. 
It's not entirely clear why, but the most likely-seeming choices are either 
that the developers didn't want to mess with Rx in more than one process, 
or that they didn't want to deal with the relatively complex kaserver RPC 
protocol.  I suppose it could be changed, if someone were willing to do the 
work to design, implement, and test the changes, and submit a patch...


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

Yes and no, respectively.  OpenAFS 1.2.9 will accept Kerberos 5 tickets, 
provided that the ticket is encrypted using a single-DES enctype.  It also 
accepts "rxkad 2b" tickets, which are a special truncated form of Kerberos 
5 ticket designed to fit the size constraints of older cache managers. 
Both of these ticket forms are decrypted using the same AFS service key 
that is used for Kerberos 4 tickets.  Note that this is not the same as 
full krb5 support -- we support Kerberos 5 tickets with a limited range of 
enctypes, and continue to use the same encryption methods we have always 
used.


Doug Engert likes to talk about gssklog, which he created to solve a 
particular problem he has -- obtaining AFS tokens using a non-krb5 GSSAPI 
mechanism.  If you are using krb5, you don't need gssklog -- a krb5-aware 
aklog/afslog is sufficient.  What gssklog does is establish a connection to 
a special server, authenticated using whatever GSSAPI mechanism it was 
compiled against (the relevant one is GSI, used in some grid 
installations).  The server then gives it something that looks like a 
traditional AFS token (that is, a krb4 ticket), encrypted in a single-DES 
AFS service key.  It solves a particular problem that comes up at sites 
which want to use GSI with AFS, but it's not really the right long-term 
solution, and there's absolutely no benefit to be gained from using gssklog 
with gss-krb5 over using a krb5-aware aklog.


There is ongoing work to provide real GSSAPI support in rxkad and OpenAFS. 
Once complete, this work will allow AFS to be directly authenticated using 
Kerberos 5, GSI, or whatever other GSSAPI mechanism you like.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA