Review of Kerberos AEAP API

[Sam Hartman]

>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:

    Jeffrey> Sam Hartman wrote:
    >> 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.
    >> 
    >> --Sam

    Jeffrey> Sam:

    Jeffrey> It is indeed unfortunate that krb5_data does not use
    Jeffrey> size_t and is not 64-bit ready.  However, like with the
    Jeffrey> 64-bit time_t vs 32-bit krb5_timestamp, at some point the
    Jeffrey> MIT Kerberos API is going to have to be fixed.

I actually disagree with this.  I agree that MIT Kerberos will
eventually need to change its timestamp size (or stop being used).
However I don't know that you'll ever need to have RFC 3961 messages
longer than 2G.  I understand you could do so; I just don't think it
will ever become a practical problem worth fixing.  I do agree that if
the major version of the ABI changes, we should use size_t in
krb5_data.
I just don't know that it will ever be worth fixing.

    Jeffrey> I believe it is appropriate to design the API for what we
    Jeffrey> would want it to be when things are fixed instead of
    Jeffrey> tying it to what the existing internal implementation is.

I am more interested in designing an API that is usable by its
consumers than I am  in  one this is what we eventually want ore one that is convenient for today's implementation.

To clarify, the problems Luke and I ran into were with using the API and the target being a krb5_data, not with implementing the API.

The big problem is not with ETOOBIG.  The big problem is that if you
have a 64-bit size_t and you use krb5_data.length for the output
length,then you overwrite 32 bits past the length.  You won't detect
it on a 32-bit platform, but it will break badly on a 64-bit platform.