Review of Kerberos AEAP API

Sam Hartman hartmans at MIT.EDU
Thu Dec 4 08:52:49 EST 2008

>>>>> "Love" == Love Hörnquist Åstrand <lha at> writes:

    Love> 2 dec 2008 kl. 09.46 skrev Love Hörnquist Åstrand:

    >> Hello here is my comments from the initial pass over the
    >> document.
    >> 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 mailing list