Date: | Mon, 20 Mar 2006 11:37:29 -0500 |
From: | "Mohan K" <mohan.anon@gmail.com> |
To: | krb5-bugs@mit.edu |
Subject: | PADATA_ETYPE_INFO2 and ETYPE_INFO usage? |
Greetings
I am trying to study the MIT implementation of the protocol. I have noticed a problem when i try to
get a initial ticket with the pre auth list as
{ ETYPE_INFO2, ENC_TIMESTAMP}
( I have removed the prefix.)
so when i pass this to krb5_get_init_... _password, I get a memory fault. I have traced it to preauth2.c
where in switch for ETYPE_INFO2 , I get a error return code from decode_krb5_etype_info2, and
when subsequent free is called (ignoring the return code) it crashes.
if (ret) {
ret = 0; /*Ignore error and etype_info element*/
krb5_free_etype_info( context, etype_info); <== crash
etype_info = NULL;
continue;
}
My question is how is etype_info2 preauth suppposed to be used? The reason I want to do this,
so that I don't have to specify the encryption types for pre-auth (as the current implementation
seems to pick the first key which is aes...).
I don't know whether it is bug or not, but wanted to confirm this. This is based on 1.4.1 release
(although I have checked the 1.4.3 release and the affected files do not seem to have changed).
Thanks
Raj
I am trying to study the MIT implementation of the protocol. I have noticed a problem when i try to
get a initial ticket with the pre auth list as
{ ETYPE_INFO2, ENC_TIMESTAMP}
( I have removed the prefix.)
so when i pass this to krb5_get_init_... _password, I get a memory fault. I have traced it to preauth2.c
where in switch for ETYPE_INFO2 , I get a error return code from decode_krb5_etype_info2, and
when subsequent free is called (ignoring the return code) it crashes.
if (ret) {
ret = 0; /*Ignore error and etype_info element*/
krb5_free_etype_info( context, etype_info); <== crash
etype_info = NULL;
continue;
}
My question is how is etype_info2 preauth suppposed to be used? The reason I want to do this,
so that I don't have to specify the encryption types for pre-auth (as the current implementation
seems to pick the first key which is aes...).
I don't know whether it is bug or not, but wanted to confirm this. This is based on 1.4.1 release
(although I have checked the 1.4.3 release and the affected files do not seem to have changed).
Thanks
Raj