Problems parsing old krbPrincipalKey attributes from LDAP backend

[Frank Steinberg]

[Subsequent messages containing key data have not been sent to the mailinglist.]

Hi Greg,

thank you very much. Now, I have a better understanding of the problem.
I started to analyze the key data with an ASN.1 decoder and could identify
the differences in the optional salt sequence. Patching the KDC would be
possible, however I think I will try the approach to recode the affected
key data. If I will come up with a solution (or if I give up :-)) I will
let you know...

--- /root/key-old 2014-05-24 11:56:38.143692128 +0200
+++ /root/key-new 2014-05-24 11:56:37.231688930 +0200
@@ -1,179 +1,207 @@
  SEQUENCE {
    [0] {
      INTEGER 1
      }
    [1] {
      INTEGER 1
      }
    [2] {
-     INTEGER 1
+     INTEGER 2
      }
    [3] {
-     INTEGER 0
+     INTEGER 1
      }
    [4] {
      SEQUENCE {
        SEQUENCE {
+         [0] {
+           SEQUENCE {
+             [0] {
+               INTEGER 0
+               }
+             }
+           }
          [1] {


Am 24.05.2014 um 06:35 schrieb Greg Hudson <ghudson at MIT.EDU>:

> Thanks for this information.  I was able to figure out what
> unintentionally changed; the upshot is that most LDAP key data encoded
> with version 1.6 cannot be decoded with version 1.11 or 1.12.  The
> details are complicated; if you care, they are at:
> 
>    http://krbdev.mit.edu/rt/Ticket/Display.html?id=7918
>    http://krbdev.mit.edu/rt/Ticket/Display.html?id=7919
> 
> Are you in a position to patch your 1.12 KDC once I develop a fix for
> this?  If not, it's theoretically possible to re-encode the key data
> in the affected DB entries, but it wouldn't be all that straightforward.
> 
> On 05/23/2014 08:14 AM, Frank Steinberg wrote:
>> Hi Greg!
>> 
>> thank you for the very prompt response! I'm sorry, that it took
>> three days to get back on this issue.
>> 
>> Am 20.05.2014 um 17:01 schrieb Greg Hudson <ghudson at MIT.EDU>:
>> 
>>> On 05/20/2014 09:56 AM, Frank Steinberg wrote:
>>>> Did this krbPrincipalKey type change?
>>> 
>>> Not intentionally. [...]
>>> 
>>> * You could send me a hex dump of a key sequence which decodes in
>>> 1.10 but not in 1.12.
>> 
>> This is the (former) LDIF attribute of our principal [...]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20140524/c2371407/attachment.bin