Skip Menu |
 

From: Sam Hartman <hartmans@MIT.EDU>
To: krb5-bugs@MIT.EDU
Subject: trunk a86e885 does not deal with default salt
Date: Wed, 07 Mar 2012 16:38:44 -0500
CC: kevin.wasserman@painless-security.com

I have a 1.10 KDC and a principal configured as follows:

Key: vno 3, aes256-cts-hmac-sha1-96, no salt
Key: vno 3, des3-cbc-sha1, no salt
Key: vno 3, des-cbc-crc, no salt
Key: vno 3, des-cbc-md5, Version 4
Key: vno 3, des-cbc-md5, Version 5 - No Realm
Key: vno 3, des-cbc-md5, Version 5 - Realm Only
Key: vno 3, des-cbc-md5, AFS version 3



We get a decrypt integrity check failure because the salt is empty
(data 0 length 0) rather than being the default salt.

My guess is that the new ASN.1 decoder fails to distinguish an absent
salt sequence in etype_info2 from a v4 style present but empty octet
string sequence.

I'm not at all sure why regression tests don't catch this.
However setting an onlyrealm salt does seem to fix this.
I see the bug. I'm cleaning up the ASN.1 tests a little bit and adding a
unit test case with the fix.

Regression tests don't catch this because the trunk KDC always sends an
explicit salt (r25410).
From: ghudson@mit.edu
Subject: SVN Commit

Properly decode etype-info2 with no salt

The data-driven decoder for etype-info2 was neglecting to call
init_no_salt() when no salt is present in the encoding. Add in the
missing call. Also add decode test cases for etype-info2, which would
have caught this if they weren't missing.

https://github.com/krb5/krb5/commit/9220e0c6eaac565f9241e09e0809f206b121eb2c
Commit By: ghudson
Revision: 25744
Changed Files:
U trunk/src/lib/krb5/asn.1/asn1_k_encode.c
U trunk/src/tests/asn.1/krb5_decode_test.c