[96] in pc-kerberos
Re: Difficulties with KTEXT_ST
daemon@ATHENA.MIT.EDU (Paul B. Hill )
Wed Jul 12 14:19:09 1995
To: Tom True <TDTRUE%PUCC.bitnet@mitvma.mit.edu>
Cc: pc-kerberos@MIT.EDU
Date: Wed, 12 Jul 95 14:10:59
From: pbh@MIT.EDU (Paul B. Hill )
Reply-To: pc-kerberos@MIT.EDU
In your message of Wed, 12 Jul 95 10:54:22 EDT you said:
To: pbh@MIT.EDU
Subject: Difficulties with KTEXT_ST
Date: Wed, 12 Jul 95 10:54:22 EDT
From: Tom True <TDTRUE%PUCC.bitnet@mitvma.mit.edu>
REPLY TO 07/11/95 16:29 FROM pbh@MIT.EDU: Re: Difficulties with KTEXT_ST
Paul--I've looked at the source on both sides. (We use the Cygnus
release under Unix and I have your release of last september on my PC.)
Two issues puzzle me: in neither krb_mk_req nor krb_rd_req does the
code do anything about the endianess of authent->length. The value
is used with no questions asked. The larger issue is the size of
an int: in the definition of struct ktext, lenght is always defined
as an int, so that if you send a struct ktext from one operating system
to another, there's no guarantee that the two declarations of struct
ktext will map the same bytes.
Is struct ktext really intended for local use? Should I be sending
the n bytes pointed to by authent->dat along with the value of n
over the network as I see fit, and then write them into a native
struct ktext? (I hope this is clear ..._)
...(rest deleted by pbh)
------- End of Forwarded Message
They key point is mentioned in the description of krb_mk_req within the
source code. Notice that the least significant bit of AUTH_MSG_APPL_REQUEST
contains the HOST_BYTE_ORDER of the local machine. If you look in the
companion function, krb_rd_req(), this bit is checked and code has
conditional execution based on this. I.e. bytes get swapped get before the
rest of the information is decoded. Look for the code right after the
comment /* byte order */ Both functions are commented to
indicate that if one is changed then the other must be as well.
The DLL has been tested against servers with either byte order. This did
expose one error in a macro in a header file. The error generated when this
patch was not applied was a time skew error. This occured when the server
had the same byte order as a PC, e.g. an RT was the server.
You should be able to send the authent across the net.
If you are getting an error you might want to post a small sample that will
demonstrate the problem.
Paul
