Review of Kerberos AEAP API
hartmans at MIT.EDU
Thu Dec 4 08:52:49 EST 2008
>>>>> "Love" == Love Hörnquist Åstrand <lha at kth.se> writes:
Love> 2 dec 2008 kl. 09.46 skrev Love Hörnquist Åstrand:
>> Hello here is my comments from the initial pass over the
>> Limiting to only on DATA buffer is overly restrictive.
>> On decryption, the HEADER/TRAILER data should be define to be
>> read only as well as the ivec content, ie it should be possible
>> to setup an recv'er ivec array and keep reusing it over and
>> over again w/o re-init the data.
>> There should be an option to have a readonly DATA buffer, but I
>> can live w/o that for now.
Love, Luke started out with this approach. Unfortunately, as you are
probably aware, the length field in krb5_data is not size_t. He found
that you always ended up having to use a temporary, and the API was
not useful because you almost always were filling in a krb5_data.
This is particularly problematic because it makes it easy to write
code on a 32-bit system that will not work on a 64-bit system.
So, the API is more useful for MIT Kerberos if the return from krb5_c_crypto_length uses the same size as the length field in krb5_data.
When you add Heimdal to the mix, it gets kind of ugly. It's my
understanding that Heimdal does use size_t in krb5_data.
We could say that for both APIs, the length coming out of
krb5_c_crypt_length will be correct size to be used in krb5_data.
I think that's reasonably clean.
More information about the krbdev