Issue in generating Authenticator Data in AP_REQ

[Sankar Das]

Hi Greg,
 
Still I am facing the same problem i.e. "Decrypt integrity check failed". Now I am sending the checksum as part of the authenticator data. Is there any way to know what part of my authenticator data is wrong? 
 
I am generating the checksum as follows:
 
unsigned char *
compute_checksum(unsigned char *key, int key_data_len, unsigned char *in_data, int in_data_len, int *out_len)
{
    unsigned char* result;
    unsigned int result_len = 32;
    int i;
    HMAC_CTX ctx;
    result = (unsigned char*) malloc(sizeof(char) * result_len);
    ENGINE_load_builtin_engines();
    ENGINE_register_all_complete();
    HMAC_CTX_init(&ctx);
    HMAC_Init_ex(&ctx, key, key_data_len, EVP_sha256(), NULL);
    HMAC_Update(&ctx, in_data, key_data_len); 
    HMAC_Final(&ctx, result, &result_len);
    *out_len = result_len;
    HMAC_CTX_cleanup(&ctx);
    return result;
}

 
Input Parameter
============
key: "enc-part" of Ticket received in AS_REP
key_data_len: Length of the above
in_data: Buffer containing KDC_REQ_BODY 
in_data_len: Length of the above
 
Any help would be appreciated.
 
Regards
Sankar


--- On Sat, 8/18/12, Greg Hudson <ghudson at MIT.EDU> wrote:


From: Greg Hudson <ghudson at MIT.EDU>
Subject: Re: Issue in generating Authenticator Data in AP_REQ
To: "Sankar Das" <sankar_das at yahoo.com>
Cc: krbdev at mit.edu
Date: Saturday, August 18, 2012, 8:38 PM


On 08/18/2012 08:37 AM, Sankar Das wrote
> 1. I am not sending "checksum" field as it is optional in Authenticator
> data. Does KDC always expect it?

Yes.  RFC 4120 requires that a TGS request include a checksum of the
kdc-req-body in the authenticator, to prevent authenticators from being
replayed in different TGS requests.  Since you're not including a
subkey, the checksum should be computed using the TGS session key with a
key usage value of 6.

> 2. I am using OpenSSL encryption functions to generate the
> Authenticator. Is there any known issue in it? (Note: I am using
> enc-part of ticket received in AS_REP as encryption key and
> concatenation of principal's realm and name as salt string).

I'm not aware of any specific issues in the OpenSSL encryption
functions, but when RFC 4120 talks about using encryption, it means
doing RFC 3961 authenticated encryption.