[1197] in Kerberos_V5_Development
Re: Question about KRB5_KDB_SUPPORT_DESMD5
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu May 16 13:47:29 1996
Date: Thu, 16 May 1996 13:47:24 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Barry Jaspan's message of Thu, 16 May 96 13:23:34 -0400,
<9605161723.AA15723@beeblebrox.MIT.EDU>
Date: Thu, 16 May 96 13:23:34 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Please define the purpose of the KRB5_KDC_SUPPORT_DESMD5 attribute. I
couldn't quite figure it out; here's what I wrote in kdb.tex:
>> \item[KRB5_KDB_SUPPORT_DESMD5] An AS_REQ for a principal with this bit
>> set and an encrytion type of ENCTYPE_DES_CBC_CRC causes the encryption
>> type ENCTYPE_DES_CBC_MD5 to be used instead. XXX Why set this bit
>> instead of just changing the service principal's enctype?
An AS_REQ is sent to the KDC with a list of encryption types:
3DES_SHA, DES_CBC, DES_MD5, etc.
The KDC picks the first one which (a) it supports and (b) which the
application server supports. The bit ENCTYPE_DES_CBC_MD5 indicates that
in fact the application server actually supports DES_MD5, since older
clients won't support it.
The abstraction layers (and I know I'm using the word loosely here;
I know they're not very well defined at all) in libkdb allows a DES key
of any of the DES enctypes to be retrieved if you need a DES key. We
could have overloaded the fact of whether or not the client supports a
particular encryption mechanism by changing enctype field, but this gets
really hairy. Especially when you consider that a kdb entry will have
multiple keys attached to it, and how hard it is to iterate through the
keys at all.
- Ted
