On Wed, Mar 7, 2012 at 10:33 AM, Tom Yu <[email protected]> wrote: > Nico Williams <[email protected]> writes: > >> But there's no integrity protection for most of the KDB, so there's no >> way to know if the problem is corruption. That said, I agree with >> you: removing the required key == removing that part of the password >> history keyed with that key. > > The keys that the KDC uses to encrypt long-term keys (and key > histories) in the KDB typically provide integrity protection. What > sort of corruption were you thinking of?
Only things encrypted with the master key and such are integrity protected. Things like principal names, attributes, kvnos, ... -> not integrity protected. Bit rot occurs. I was explaining why a developer might think that in this case it's better to fail the operation (password change), but in practice -and if we ignore corruption- users would really prefer to have the code ignore the affected history entry. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
