[OpenAFS-devel] What is this Packet Anyway?

[Marcus Watts]

"Henry B. Hotz" <hotz@jpl.nasa.gov> claims:
> Contrary to popular rumor it appears that the Windows AFS client  
> (Transarc 3.6 2.48 anyway, not talking about 1.3.x) does *not* use  
> standard Kerberos 4 (though it does use port 750) for its  
> authentication exchanges.  Neither does it use RX.
> 
> The authentication request I captured is the following (and is  
> identical for two different versions of Windows).  The Ethernet, IP,  
> and UDP headers are stripped, leaving the following:
> 
> > 0000  63 03 62 87 f8 b9 73 c2 a7 01 68 6f 74 7a 00 00    
> > c.b...s...hotz..
> > 0010  4a 50 4c 2e 4e 41 53 41 2e 47 4f 56 00 44 3f 47    
> > JPL.NASA.GOV.D?G
> > 0020  41 bf 61 66 73 00 00                              A.afs..
> 
> There is no RX header.  It doesn't start off with the "04 02" or "04  
> 03" that a Kerberos 4 request would.  What is this thing?  It fails all  
> the Heimdal code checks for what it might be and winds up not causing  
> any action whatever.
> 
> I will note that if you strip off the first 10 bytes the remainder is  
> the same as what you get if you strip off the first 2 bytes of a normal  
> Kerberos 4 authentication request.
> 
> If no one knows what this is, can they at least give me some pointers  
> to where the kaserver code would handle the request?  I get lost in all  
> the RX stuff (that shouldn't even be relevant since this isn't an RX  
> packet).

kaserver is prepared to handle requests on up to 3 ports:
	7004	rx
	750, 88	udp
udp stuff is all handled in 1 file --
	src/kauth/krb_udp.c
It's very straight-forward.  I've never seen a version of kaserver that
was prepared to deal with anything but standard K4 stuff on port 750
(and 88).

The version of 3.6 source I have has windows specific code in
kauth/user_nt.c that contains a "k4" version of ka_UserAuthenticateGeneral .
That looks to be doing absolutely standard k4 stuff as well, no hanky-panky.

It's a real shame that you only included one fragment of one packet --
I can't tell if that's from the client or the server, and it would be
handy to know whether it's from or to port 88, 750, or 7004.  Is that
actually the whole packet too? (I ask since tcpdump defaults to silently
trimming packets at 82 bytes unless you say "-s 1500"...)  Have you
tried running this client against kaserver or fakeka?  It would be
interesting to see the entire packet exchange for a "successful" run
before drawing too many conclusions about what's happening.

I suppose it's conceivable transarc might have wanted to do something
besides straight k4 on their windows machines - if so, they're likely
trying to do some sort of pre-authentication like they do with RX.
But I suppose it's also possible this is some sort of bad library clash.
Is there any particular reason you want to use this particular afs client
on windows rather than a recent openafs version?

					-Marcus