[OpenAFS-devel] What is this Packet Anyway?

[Henry B. Hotz]

Thanks to Kevin.  Keeps me from going crazy!

To answer the other questions:

On Sep 16, 2004, at 9:01 AM, openafs-devel-request@openafs.org wrote:

> To: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] What is this Packet Anyway?
> Date: Wed, 15 Sep 2004 23:22:01 -0400
> From: Marcus Watts <mdw@umich.edu>
>
> "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).

I did *eventually* find that, but thanks.  (The code's a little scary  
in that if you have an /etc/services which defines "kerberos" as 88  
(normal) but doesn't define "kerberos-iv" it will do the "wrong thing"  
(TM).  Suppose it's not worth fixing though.)

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

Have to look at this.

> 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 had lots of packets, but they were all the same.  What I posted was  
the auth request, minus the Ethernet, IP, and UDP headers.  In other  
words what a server program would have gotten from its recv() call.

At the time I had no reply packets to post or look at.  Since then I  
have done some snoops on our operational cell and the reply is a  
bog-standard K4 packet.  Nothing funny at all.

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

The usual.  Existing installed base.  We expect to switch to OpenAFS  
sometime next FY (which starts October), but we want to ditch the  
kaserver sooner than that!

> 					-Marcus
>
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu