Review of Kerberos AEAP API
hartmans at MIT.EDU
Thu Dec 4 11:32:14 EST 2008
>>>>> "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
>> 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
>> 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.
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
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.
More information about the krbdev