On 11/21/2013 11:39 AM, Jeffrey Hutzelman wrote: >> The other thing that Kim needs to test given the age of the clients is >> whether or not any of them suffer from an old bug that would result in >> an out of bounds array access if the service enctype has a value that is >> not recognized by the client. If so, it may not be possible to deploy >> AES256-SHA1 enctypes. > > Uh, I'm not aware of any such bug. Can you provide a reference? > There _is_ a bug which could result in an out-of-bounds array access if > the returned token is too large, which could happen for some enctypes. > However, this is relatively unlikely if your client principal names > aren't too big. We designed rxkad-2b such that everything would fit > within the smaller limit even with maximal-size client principal names, > but that was using DES, and the block size for the AES enctypes is > larger.
Early MIT Kerberos and CyberSafe had this bug. Oracle's Kerberos that forked form MIT Krb5 1.0 Alpha inherited this bug. I don't know when it was fixed but the fix was probably around the time that Windows 2000 showed up because of their negative enctype values. Java had this bug until 1.4. It is only worth mentioning in this context because I know how old the systems involved are. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
